Это стартовая страница концепта мультиагентной ИИ-платформы для розничных сетей. Концепт разработан командой Glowbyte на основе внутренних исследований и проектного опыта в ритейле.
У каждого раздела есть статус готовности, который показывает, что уже можно использовать, а что пока в работе (см. «Готовность разделов»).
Категорийный менеджер крупной торговой сети часто работает в одиночку, хотя вокруг него много систем, отчётов и людей. Он отвечает за P&L категории, ведёт переговоры с поставщиками, следит за полкой, оборотом, маржой и промо. Решения ему приходится принимать быстро и под давлением, не видя полной картины.
Данных много, но они разбросаны по системам и обычно требуют ручной сборки.
Та же история повторяется в логистике, ценообразовании, маркетинге и операционной работе.
С корпоративной мультиагентной ИИ-платформой у менеджера появляется новая рабочая модель. В ней два слоя.
ИИ-Напарник
Персональный агент конкретного сотрудника. Он помнит контекст, приоритеты и историю решений, а ещё работает единой точкой входа к корпоративным данным и системам. Напарник сам подключает нужных функциональных агентов и помогает увидеть следующий шаг. Начинает как агент общего назначения и обрастает скиллами на реальных задачах сотрудника.
Функциональные агенты
Специализированные ИИ-исполнители для отдельных классов задач. Сюда входят разбор промо, мониторинг аномалий, расчёт финансового эффекта, запросы к хранилищу данных, поиск по базе знаний и регламентам, контроль OOS. Обычно менеджер не вызывает их напрямую. Это делает Напарник, когда понимает, какая помощь нужна.
Каталог агентов не проектируют целиком заранее. Стартовый набор из пяти агентов задуман как гипотеза, которую проверяет пилот. Сотрудник работает с Напарником с первого дня. Удачный сценарий становится его личным скиллом, похожие личные скиллы разных сотрудников сводятся в общий скилл роли, а когда задаче нужны свои инструменты или доступ к данным, из скилла вырастает функциональный агент. Подробнее в 02-partner и 03-agents.
Работа, которая длится дольше одного разговора, живёт на досках. У каждой карточки один исполнитель, и это может быть человек, его Напарник или функциональный агент. На доске всегда видно, что открыто и чего ждут.
За всем этим стоят память платформы, интеграции с внутренними системами, безопасность, аудит и правила работы агентов. Подробнее о концепте в 01-vision.
Концепт не привязан к конкретному вендору и остаётся технологически нейтральным (подробнее ниже, в разделе «Как устроена вики»). Конкретные платформы и инструменты упоминаются в документах только как пример реализации и только там, где это помогает объяснить модель. Обязательного выбора здесь нет.
У каждой группы читателей свои вопросы и свой порог терпимости к техническому языку. У каждого артефакта своя аудитория, поэтому собирайте его под конкретную группу читателей.
Бизнес-заказчики ритейла
Сюда попадают коммерческий директор, директор по категорийному менеджменту и операционный директор торговой сети.
Им нужно быстро понять боль, бизнес-эффект, границы пилота и то, почему это не очередная «магия с ИИ».
Начать с 01-vision, 02-partner и 04-usecases. Фазы и границы пилота из 07-roadmap пока рассказываем устно, потому что документ в статусе черновика.
Технические лиды заказчика
К этой группе относятся архитекторы, CIO и CDO, специалисты по ИТ-безопасности и комплаенсу.
Их интересуют реализуемость, интеграция в текущий ИТ-контур, права доступа, аудит, безопасность данных и отсутствие привязки к одному вендору.
Начать с 05-architecture, 06-integrations, разделов про безопасность и управление.
Внутренние коллеги Glowbyte
Это пресейл, архитекторы, аналитики и руководители практик.
Им нужно понимать позиционирование Glowbyte, состав MVP, переиспользуемые блоки, зоны риска и то, что ещё надо дописать перед встречей с заказчиком.
Можно открывать весь концепт. Особенно полезны 01-vision, 03-agents, 07-roadmap.
Конечные пользователи
К ним относятся категорийные менеджеры, логисты, прайс-менеджеры и другие сотрудники, которые будут работать с платформой каждый день.
Их волнуют простые вещи. Как это поможет лично мне, не будет ли система контролировать каждый шаг, не заменит ли она меня, можно ли ей доверять.
Для них лучше готовить отдельные артефакты на базе 02-partner и 04-usecases. Это может быть короткое демо или сценарий «один день с Напарником», который показывает выгоду на конкретном рабочем дне.
Концепт разнесён по семи тематическим документам. Кроме них есть эта стартовая страница и журнал изменений.
У каждого документа два слоя. Ядро содержит достаточно проработанный материал, который можно брать в разговор с заказчиком, на техническую экспертизу или во внутреннее обсуждение Glowbyte. Скелет содержит секции, гипотезы и темы, которые нужны концепту, но пока не требуют полной детализации.
Эти два слоя связаны со статусами готовности ниже. «Скелет» примерно соответствует статусу «Черновик», а проработанное «ядро» ближе к «Рабочей версии» и «Финальной версии».
Маршрут зависит от роли и времени. Ниже пять типовых вариантов.
Этого хватит, чтобы понять общую идею без технических деталей.
Подходит для разговора на 15–20 минут с коммерческим или операционным руководителем.
Маршрут для архитекторов, CIO и ИТ-безопасности.
Маршрут для пресейла, архитекторов и руководителей практик Glowbyte.
Так собирают презентации, одностраничники, демо-сценарии и письма под конкретного адресата.
Эта вики работает и как справочник, и как рабочее пространство. Здесь можно прочитать материал, дописать раздел, уточнить формулировку, перевести черновик в рабочее состояние. Ниже несколько правил, которые помогают поддерживать качество материалов по мере их развития.
Статусы помогают быстро понять, какой материал уже можно использовать, а какой лучше пока не показывать заказчику.
Черновик
Каркас, черновые формулировки и незакрытые вопросы годятся только для внутренней работы.
Рабочая версия
Основное содержание готово. Материал можно брать в презентации и обсуждения, хотя полировка ещё возможна.
Финальная версия
На этот материал можно ссылаться как на основной источник формулировок и фактов.
| Документ | Статус | Комментарий |
|---|---|---|
| Обзор концепта | рабочая версия | Здесь мы фиксируем язык, аудитории и правила работы с вики. Дополняем по мере развития концепта. |
| 01-vision | рабочая версия | Развёрнутый нарратив на каркасе четырёх эпох. Технологически нейтральный. |
| 02-partner | рабочая версия | Пользовательская модель Напарника. Сюда входят свойства, единое окно, проактивность, скиллы, доски, коллективная память, уровни зрелости и метрики. |
| 03-agents | рабочая версия | Каталог агентов. Он объясняет, откуда берутся агенты, и включает классификацию, границу «агент или скилл», пять карточек стартового набора и три карточки ближайшего контура. |
| 04-usecases | рабочая версия | Пять детально разобранных сценариев работы развёрнутой платформы, остальные намечены в backlog. Очерёдность подключения сценариев задаёт 07-roadmap. |
| 05-architecture | рабочая версия | Здесь разобраны карта архитектуры, оркестрация, реестр задач и доски, приёмка, скиллы, память платформы, Tier-модель, безопасность и управление. |
| 06-integrations | рабочая версия | В документе собраны принципы, типы и паттерны интеграций, личные и общие подключения, интеграции по фазам и справочник систем. |
| 07-roadmap | черновик | Документ описывает фазы 0–3 с границами пилота, приоритетные сценарии и интеграции, метрики и организационные условия. Сроки, бюджет и состав команды фиксируются под конкретного заказчика. |
У концепта есть темы, по которым пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
Мы не сводим их в общий список на этой странице. Открытые вопросы живут в конце каждого тематического документа, рядом с материалом, к которому относятся.
Здесь термины, которые во всех документах концепта значат одно и то же. Если где-то термин понимают уже или шире, об этом нужно прямо сказать в соответствующем разделе.
| Термин | Определение |
|---|---|
| Корпоративная мультиагентная ИИ-платформа | Управляемая среда, в которой работают ИИ-Напарники сотрудников и функциональные агенты со скиллами, памятью платформы и досками, а также интеграции с корпоративными системами, безопасность и аудит. Через неё персональный пользовательский опыт сочетается с организационным контролем. Подробно в 01-vision. |
| ИИ-Напарник | Partner Agent. Персональный ИИ-агент конкретного сотрудника. Знает контекст и историю решений сотрудника, даёт единый вход к корпоративным данным и системам, координирует функциональных агентов и может сам инициировать действия. Начинает как агент общего назначения и обрастает скиллами на задачах сотрудника. У каждого сотрудника ровно один Напарник. Подробно в 02-partner. |
| Уровни зрелости ИИ-Напарника | Четыре уровня, по которым Напарник растёт вместе с сотрудником. Это операционный помощник, аналитический помощник, коммуникационный помощник и мультиагентный координатор. Не путать с эпохами из 01-vision и фазами внедрения из 07-roadmap. Подробно в 02-partner. |
| Функциональный агент | Специализированный ИИ-исполнитель для одного класса задач (разбор промо, мониторинг аномалий, запросы к хранилищу, поиск по базе знаний). У него узкая инструментальная политика и доступ только к нужным данным. Обычно его вызывает не сотрудник, а ИИ-Напарник. Бывает бизнес-функциональным или сервисным. В статьях о концепте встречается название «агент-специалист». Подробно в 03-agents. |
| Бизнес-функциональный агент | Функциональный агент, который сам закрывает бизнес-сценарий, и его эффект виден в P&L. Например, агент промо или агент мониторинга и аномалий. Подробно в 03-agents. |
| Сервисный агент | Функциональный агент, которого Напарник или другой агент вызывает как инструмент. Сюда относятся Text2SQL, агент финансового эффекта и агент базы знаний и регламентов. Бизнес-сценарий целиком он обычно не закрывает. Подробно в 03-agents. |
| Text2SQL | Сервисный агент, который переводит вопрос на естественном языке в SQL-запрос к корпоративному хранилищу и возвращает срез данных. Для Напарника и других агентов это базовый источник цифр. Подробно в 03-agents. |
| Субагент | Технический способ запустить функционального агента в одноразовой изолированной сессии под одно задание. Это механизм исполнения, а не отдельный класс агентов. Постоянный агент, в отличие от субагента, живёт долго, хранит рабочее состояние и может быть исполнителем карточки на доске. Подробно в 05-architecture. |
| Стартовый набор (MVP) | Пять функциональных агентов, несколько скиллов Напарника и пять приоритетных интеграций, с которых начинается пилот. Из агентов в набор входят агент промо, агент мониторинга и аномалий, агент финансового эффекта, агент базы знаний и регламентов и Text2SQL. Состав агентов остаётся гипотезой, которую проверяет пилот. Дальше каталог растёт в основном снизу, из скиллов сотрудников. Подробно в 03-agents, интеграции в 06-integrations. |
| Оркестрация агентов | В деловых текстах её называют координацией. Механизм, при котором ИИ-Напарник ставит задачи одному или нескольким функциональным агентам, принимает их результаты и собирает итоговый ответ. Несколько агентов могут работать параллельно. Подробно в 05-architecture. |
| A2A (Agent-to-Agent) | Межнапарниковая коммуникация, то есть прямое общение Напарников разных сотрудников. Например, Напарник одного менеджера запрашивает статус промо у Напарника коллеги. По умолчанию выключено, включается белым списком пар или ролевыми правилами. Функциональные агенты в A2A не участвуют, а задачи они получают через делегирование или от планировщика. Подробно в 05-architecture. |
| Каналы | Сотрудник работает с Напарником в двух каналах. В корпоративном мессенджере задают быстрые вопросы, получают уведомления и подтверждают действия кнопкой. На веб-портале платформы есть тот же чат, доски, список «Требует моего внимания», результаты, личные и общие скиллы и каталог агентов. Напарник в обоих каналах один. Подробно в 05-architecture. |
| Четыре эпохи | Рамка из 01-vision, которая показывает, как менялась работа менеджера с корпоративной средой, от инструментов через автоматизацию и функциональных ИИ-агентов к ИИ-Напарнику и мультиагентной среде. Помогает понять, где сейчас находится заказчик. Это не модель зрелости. Подробно в 01-vision. |
| Термин | Определение |
|---|---|
| Скилл (навык) | Инструкция обычным языком, которую платформа подключает к работе агента, когда она нужна. В скилле описано, когда его применять, порядок работы, источники и формат результата. К нему прикладывают шаблоны документов, примеры удачных результатов и расчётные скрипты. Скилл бывает встроенным (поставляется с платформой), личным (сотрудник создаёт его со своим Напарником, обычно из удачного диалога) и общим. Подробно в 05-architecture, граница «агент или скилл» в 03-agents. |
| Общий скилл | Скилл для роли, отдела или всей компании. Обычно его сводят из похожих личных скиллов сотрудников, а перед публикацией его проверяет куратор коллективной памяти. У общего скилла есть владелец, версия и происхождение. Он работает по подписке у всех сотрудников, для которых опубликован, и новые версии приходят к ним сами. Вместо подписки можно взять копию, она становится личным скиллом. Подробно в 05-architecture. |
| Пакет роли | Набор общих скиллов, команд, агентов и регулярных поручений одной функции, например пакет категорийного менеджера. Отделу его подключают одним действием. Пакет фиксирует то, что уже прижилось у сотрудников. Стартовые пакеты для ритейла готовит команда внедрения, дальше их пополняет опыт сотрудников заказчика. Подробно в 05-architecture. |
| Команда | Вызов через /. Служебные команды (/статус, /пауза) платформа выполняет сама, без модели и без расхода токенов. Сохранённое поручение (/брифинг, /переговоры Saverio) это заготовка запроса с параметрами, которую Напарник выполняет как обычное поручение. Команду сотрудник вызывает сам, а скилл Напарник подключает сам. Подробно в 05-architecture. |
| Регулярное поручение | Работа по расписанию, которую сотрудник поручает Напарнику обычным языком, например «каждый понедельник в 9:00 собирай панель по промо». У поручения есть расписание, срок действия и статус (активно, на паузе, завершено). На доске оно видно регулярной карточкой. Поручение, которое только читает данные и готовит результат для самого сотрудника, остаётся на Tier 1. Подробно в 05-architecture. |
| Workflow | Многошаговый процесс, заданный как детерминированная последовательность шагов с контрольными точками, на которых агент ждёт подтверждения сотрудника. Нужен там, где сценарий должен идти одинаково у всех. Этапы доски не исполняют шаги, а показывают, где работа находится в процессе команды. Подробно в 05-architecture. |
| Термин | Определение |
|---|---|
| Задача | Единица работы в реестре платформы. Задачу заводят под работу, которая длится дольше одного ответа агента или переходит от агента к агенту и к людям. Сотрудник видит её карточкой на доске, а реестр задач складывается из карточек всех досок. У задачи ровно один исполнитель, постановка с критериями приёмки, статус и ссылки на результаты. Зависимостей между задачами нет, за порядок работ отвечает Напарник. Не путать с поручением человеку во внешнем таск-трекере. Такое поручение Напарник ставит от имени сотрудника с его подтверждением (см. 06-integrations). Подробно в 05-architecture. |
| Доска | Общее место людей и агентов для работы, которая не укладывается в один разговор. Показывает, что открыто, кто этим занимается и чего ждут. Доска бывает личной, проектной и доской агента. Агенты не создают, не открывают другим и не удаляют доски. Подробно в 02-partner и 05-architecture. |
| Карточка | Запись на доске. Это может быть задача, напоминание «проверить позже» или передача работы от агента агенту или человеку. У карточки ровно один исполнитель. Им может быть сотрудник, его Напарник или функциональный агент. Назначение карточки на агента запускает его работу. Не путать с карточкой агента, то есть описанием агента по шаблону. |
| Статус и этап | Статус отвечает, кто должен действовать сейчас. Бывают статусы «открыта» (действует исполнитель), «ждёт человека» (с указанием, кого именно), «сделана» и «отменена». Этап показывает, где работа находится в процессе команды, например «На проверке», и задаётся шаблоном доски. Статус и этап меняются независимо, а конечный этап («Готово», «Отменена») закрывает карточку. Подробно в 05-architecture. |
| Шаблон доски | Настройка доски под процесс команды. В шаблон входят поля карточек, этапы с условиями перехода, номера и представления. Шаблоны готовит команда внедрения, конструктора процессов на портале нет. Пример в 02-partner. |
| «Требует моего внимания» | Список на портале, который собирает со всех доступных сотруднику досок карточки, ждущие его ответа, и открытые карточки, назначенные ему. Просроченные помечены. Сюда же попадают запросы на подтверждение действий Tier 2. Подробно в 05-architecture. |
| Приёмка результата | Проверка Напарником результата функционального агента по критериям из постановки до того, как его увидит сотрудник. Непринятый результат возвращается исполнителю с конкретным замечанием. Так Напарник работает в полном режиме, который действует по умолчанию. В лёгком режиме работу, которую сотрудник поручил агенту напрямую, Напарник проверяет выборочно. Подробно в 05-architecture. |
| Результат | То, что агент сдаёт по задаче, например разбор, досье, таблица, презентация или черновик письма. Регистрируется в реестре с версией и источниками. Не путать с «артефактом» в смысле материала, собранного из вики под аудиторию. Подробно в 05-architecture. |
| Событие | Сигнал платформы, по которому агент начинает работу. Сюда относятся сообщение сотрудника, назначение карточки, завершение запущенных агентов, ответ человека, которого ждёт карточка, наступление назначенного времени, нажатие кнопки «Разбудить», решение по подтверждению Tier 2, срабатывание расписания, сигнал о зависшей задаче. Без событий агенты не работают и не расходуют токены. Внешние события из корпоративных систем (сорванная поставка, письмо поставщика) агента напрямую не будят. Интеграция превращает их в карточки, и работу запускает назначение карточки (06-integrations). Подробно в 05-architecture. |
| Термин | Определение |
|---|---|
| Память платформы | Три слоя памяти с разными правилами доступа. Сюда входят корпоративная база знаний, личная память Напарника и коллективная память. В ранних версиях концепта называлась «организационной памятью». Подробно в 05-architecture. |
| Корпоративная база знаний | Курируемое людьми хранилище формализованного знания, где лежат регламенты, стандарты, переговорные прецеденты и аналитические отчёты. Агенты его читают. Новые прецеденты агент базы знаний и регламентов готовит черновиками, а публикует ответственный сотрудник. Подробно в 05-architecture. |
| Личная память Напарника | Устойчивый контекст конкретного сотрудника. Сюда входят история решений, профили контрагентов и коллег и предпочтения по коммуникации. Изолирована от других сотрудников. Подробно в 05-architecture. |
| Коллективная память | Проверенный опыт команды, которым пользуются Напарники всех сотрудников роли. Хранит паттерны (подходы, сильные аргументы, разборы кейсов, уроки) и общие скиллы. Общие скиллы и коммерчески значимые паттерны попадают сюда только после проверки куратором коллективной памяти, низкорисковые операционные паттерны платформа может выносить автоматически. Регламенты и формальные документы живут в корпоративной базе знаний. Подробно в 05-architecture. |
| Куратор коллективной памяти | Роль в организации, обычно руководитель направления или эксперт по методологии. Проверяет коммерчески значимые паттерны и общие скиллы перед публикацией и пересматривает общие скиллы с падающими оценками. Не путать с агентом-куратором коллективной памяти. Агент готовит кандидатов, а решение принимает человек. Подробно в 05-architecture. |
| Термин | Определение |
|---|---|
| Human-in-the-loop | Принцип, при котором рискованные действия (сообщения от имени сотрудника, запись во внешние и учётные системы, расход денег, договорные изменения, листинг и делистинг, подключение агентов и расширение их прав) проходят через явное подтверждение человека. Агент не может подтвердить собственное предложение. Подробно в 05-architecture. |
| Tier-модель автономии | Уровень автономии агента определяется действием, а не способом запуска. На Tier 1 агент читает данные и готовит черновики и результаты внутри платформы. На Tier 2 действие с внешним эффектом (письмо, запись в учётную систему, задача коллеге) выполняется только после подтверждения ответственного человека. На Tier 3 агент сам выполняет стандартные операции с внешним эффектом в согласованных с комплаенсом границах. Подробно в 05-architecture. |
| Инструментальные политики | Tool policies. Правила платформы, определяющие, какие инструменты доступны конкретному агенту (чтение, запись, отправка сообщений, веб-доступ, обращение к другим агентам). Настраиваются на нескольких уровнях, и каждый следующий уровень может только сузить права. Работают независимо от инструкций модели. Подробно в 05-architecture. |
| Команда платформы | Те, кто развивает платформу после запуска. Они сводят похожие личные скиллы в общие, собирают новых агентов из скиллов и ведут каталог. На пилоте это обычно команда внедрения, позже к ней присоединяются специалисты заказчика. Не путать с командой внедрения, которая разворачивает платформу, подключает интеграции и готовит шаблоны досок и стартовые пакеты ролей. Подробно в 05-architecture. |
| Стоп-кран | Пауза одним действием. Сотрудник ставит на паузу своего Напарника, руководитель или администратор останавливает отдел или всю платформу. Это первая мера при инциденте и при неожиданном росте расходов. Подробно в 05-architecture. |
| Коннектор | Подключение корпоративной системы к платформе. Коннектор пишут один раз, а пользуются им разные агенты в пределах своих инструментальных политик. Личное подключение работает под учётной записью сотрудника (почта, календарь, файлы), и Напарник видит ровно то, что видит сотрудник. Общее подключение работает под сервисной учётной записью, его настраивает администратор платформы, например хранилище для Text2SQL. Каждое действие коннектора разрешено, идёт с подтверждением или выключено. Подробно в 06-integrations. |
| MCP (Model Context Protocol) | Открытый протокол подключения корпоративных систем и инструментов к агентам. Для платформы важен паттерн MCP-подобного коннектора, при котором систему подключают один раз, а пользуются ею разные агенты в пределах своих инструментальных политик. Подробно в 06-integrations. |
| Shadow AI | Стихийное использование внешних ИИ-сервисов сотрудниками через личные аккаунты, переводчики и браузерные расширения. ИТ-служба обычно не видит, какие данные туда уходят. Платформа даёт управляемую корпоративную альтернативу. Подробно в 01-vision. |
📄 Скачать эту страницу в Markdown (файл .mdx удобно передать ИИ-агенту или читать офлайн)