Корпоративная мультиагентная ИИ-платформа для ритейла

Рабочая версия, можно использовать

Для ИИ-агентов и краулеров

Эта вики рассчитана в том числе и на ИИ-агентов, поэтому мы дружелюбны к ним. Исходные Markdown-файлы всех страниц доступны для прямого скачивания в формате text/markdown с открытым CORS /raw/. Для LLM-агентов также доступны llms.txt (оглавление со ссылками) и llms-full.txt (весь текст одним файлом).

Это стартовая страница концепта мультиагентной ИИ-платформы для розничных сетей. Концепт разработан командой Glowbyte на основе внутренних исследований и проектного опыта в ритейле.

Вики работает не только как справочник, но и как рабочая среда. У каждого раздела есть статус готовности, который показывает, что уже можно использовать, а что пока в работе.

Из этого раздела вы узнаете

• что такое мультиагентная ИИ-платформа и зачем она нужна торговым сетям
• кому адресованы материалы и с чего начать в зависимости от роли
• как устроена вики и в каком порядке двигаться по документам
• какие термины во всех разделах значат одно и то же
• как устроены статусы готовности и где искать открытые вопросы концепта

---

Коротко о концепте

Категорийный менеджер крупной торговой сети часто работает в одиночку, хотя вокруг него много систем, отчётов и людей. Он отвечает за P&L категории, ведёт переговоры с поставщиками, следит за полкой, оборотом, маржой и промо. Решения приходится принимать быстро, с неполной картиной и под давлением.

Проблема не в том, что данных нет. Их как раз много. Проблема в том, что они разбросаны и обычно требуют ручной сборки.

Та же история повторяется в логистике, ценообразовании, маркетинге и операционной работе.

С корпоративной мультиагентной ИИ-платформой у менеджера появляется новая рабочая модель. В ней два слоя.

ИИ-Напарник

Персональный агент конкретного сотрудника. Он помнит контекст, приоритеты и историю решений, это единая точка входа к корпоративным данным и системам, сам подключает нужных функциональных агентов и помогает увидеть следующий шаг.

Функциональные агенты

Специализированные ИИ-исполнители для отдельных классов задач. Сюда входят анализ продаж, подготовка к переговорам, контроль OOS, ценообразование, поиск по базе знаний и оповещения. Обычно менеджер не вызывает их напрямую. Это делает Напарник, когда понимает, какая помощь нужна.

За этими двумя слоями стоят организационная память, интеграции с внутренними системами, безопасность, аудит и правила работы агентов. Подробнее о концепте в 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. Это может быть короткое демо или сценарий «один день с Напарником», который показывает выгоду на конкретном рабочем дне.

---

Структура документов

Концепт разнесён по семи тематическим документам плюс эта стартовая страница.

• Обзор концепта (вы здесь). Навигация, глоссарий и статусы готовности.
• 01. Видение. Видение, проблема и позиционирование концепта.
• 02. ИИ-Напарник. Напарник как пользовательская модель.
• 03. Функциональные агенты. Каталог функциональных агентов.
• 04. Сценарии использования. Разобранные бизнес-сценарии.
• 05. Архитектура. Логическая архитектура, безопасность и управление.
• 06. Интеграции. Интеграционный слой и инструменты агентов.
• 07. Дорожная карта. Дорожная карта внедрения.

У каждого документа два слоя. Ядро содержит достаточно проработанный материал, который можно брать в разговор с заказчиком, на техническую экспертизу или во внутреннее обсуждение Glowbyte. Скелет содержит секции, гипотезы и темы, которые нужны концепту, но пока не требуют полной детализации.

Эти два слоя связаны со статусами готовности ниже. «Скелет» примерно соответствует статусу «Черновик», а проработанное «ядро» ближе к «Рабочей версии» и «Финальной версии».

---

Как читать концепт

Маршрут зависит от роли и времени. Ниже пять типовых вариантов.

За 5 минут

1. Открыть этот документ и прочитать раздел «Коротко о концепте».
2. Прочитать раздел «Коротко» из 01-vision.

Этого хватит, чтобы понять общую идею без технических деталей.

Бизнес-питч

1. 01-vision целиком. Боль, видение, нарратив о четырёх эпохах.
2. 02-partner. Единое окно, уровни зрелости, пользовательская модель.
3. Один или два сценария из 04-usecases.
4. Этапы 0–2 из 07-roadmap.

Подходит для разговора на 15–20 минут с коммерческим или операционным руководителем.

Технический разговор

1. 05-architecture целиком.
2. Релевантные карточки агентов из 03-agents.
3. 06-integrations. Интеграционные паттерны и MVP-набор.
4. Разделы «Безопасность и права доступа» и «Управление мультиагентной средой» из 05-architecture.

Маршрут для архитекторов, CIO и ИТ-безопасности.

Внутренний разбор Glowbyte

1. Этот документ целиком.
2. 01-vision. Нарратив и опорные тезисы для презентации.
3. 03-agents. Агенты для MVP.
4. 07-roadmap. Этапы, метрики, границы пилота.
5. 05-architecture. Оценка реализуемости и трудоёмкости.

Маршрут для пресейла, архитекторов и руководителей практик Glowbyte.

Сборка артефакта

1. Определить аудиторию по этому документу.
2. Взять целевые разделы по теме артефакта.
3. Взять опорные тезисы и нарратив из 01-vision.

Так собирают презентации, одностраничники, демо-сценарии и письма под конкретного адресата.

---

Как устроена вики

Эта вики работает и как справочник, и как рабочее пространство. Здесь можно прочитать материал, дописать раздел, уточнить формулировку, перевести черновик в рабочее состояние. Ниже несколько правил, которые помогают поддерживать качество материалов по мере их развития.

Технологически нейтральный подход

Мы описываем архитектуру и поведение платформы, а не продаём конкретный продукт. Провайдеры языковых моделей, среды исполнения агентов, мессенджеры, ETL-стек и другие технологии упоминаются только там, где это помогает объяснить реализацию.

Язык зависит от раздела

01-vision, 02-partner и 04-usecases пишем языком бизнес-заказчика. 03-agents, 05-architecture и 06-integrations могут быть техническими. 07-roadmap должен быть понятен и бизнесу, и ИТ.

Отделяем факты от гипотез

Если в тексте есть допущение, риск или незакрытый вопрос, его нужно пометить. Такие пункты попадают либо в раздел «Открытые вопросы» этого документа, либо в backlog конкретного файла.

---

Готовность разделов

Статусы помогают быстро понять, какой материал уже можно использовать, а какой лучше пока не показывать заказчику.

Черновик

не показываем

Каркас, черновые формулировки и незакрытые вопросы годятся только для внутренней работы.

Рабочая версия

можно использовать

Основное содержание готово. Материал можно брать в презентации и обсуждения, хотя полировка ещё возможна.

Финальная версия

готово

На этот материал можно ссылаться как на основной источник формулировок и фактов.

Документ	Статус	Комментарий
index.mdx	рабочая версия	Здесь мы фиксируем язык, аудитории и правила работы с вики. Дополняем по мере развития концепта.
01-vision	рабочая версия	Развёрнутый нарратив на каркасе четырёх эпох. Технологически нейтральный.
02-partner	рабочая версия	Пользовательская модель Напарника. Сюда входят свойства, единое окно, проактивность, уровни зрелости и метрики.
03-agents	рабочая версия	Каталог агентов с классификацией, пятью приоритетными карточками и границей «агент или скилл».
04-usecases	рабочая версия	Пять детально разобранных сценариев, остальные намечены в backlog.
05-architecture	рабочая версия	Карта архитектуры, оркестрация, память, Tier-модель, безопасность и управление.
06-integrations	рабочая версия	Принципы, типы и паттерны интеграций, MVP-набор и справочник систем.
07-roadmap	черновик	Скелет-каркас. Фазы намечены, детальная проработка под конкретный пилот ещё впереди.

---

Открытые вопросы

У концепта есть темы, по которым пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.

Мы не сводим их в общий список на этой странице. Открытые вопросы живут в конце каждого тематического документа, рядом с материалом, к которому относятся.

---

Глоссарий терминов

Здесь термины, которые во всех документах концепта значат одно и то же. Если где-то термин понимают уже или шире, об этом нужно прямо сказать в соответствующем разделе.

Термин	Определение
ИИ-Напарник	Partner Agent. Персональный ИИ-агент конкретного сотрудника. Знает контекст и историю решений сотрудника, даёт единый вход к корпоративным данным и системам, координирует функциональных агентов и может сам инициировать действия. Один сотрудник, один Напарник.
Функциональный агент	Специализированный ИИ-исполнитель для одного класса задач (анализ продаж, подготовка переговоров, поиск по базе знаний, мониторинг аномалий). Узкая инструментальная политика и доступ только к нужным данным. Обычно его вызывает не сотрудник, а ИИ-Напарник.
Корпоративная мультиагентная ИИ-платформа	Управляемая среда, где работают ИИ-Напарники сотрудников, функциональные агенты, организационная память, интеграции с системами, безопасность и аудит. Через неё персональный пользовательский опыт сочетается с организационным контролем.
Скилл	Декларативная инструкция о том, как агенту работать. Задаёт, какими инструментами и сервисными агентами пользоваться, в каком формате отвечать и как трактовать данные. Бывает встроенным, общим на компанию или индивидуальным. Граница «агент или скилл» подробно в 03-agents.
Оркестрация агентов	Сценарий, в котором ИИ-Напарник делегирует задачу одному или нескольким функциональным агентам, ждёт результаты и собирает итоговый ответ. Несколько агентов могут работать параллельно. Подробно в 05-architecture.
A2A (Agent-to-Agent)	Прямое общение между агентами (например, Напарник одного сотрудника обращается к Напарнику другого). Политики задают, кто кому и по какому поводу может писать. Подробно в 05-architecture.
Организационная память	В обиходе корпоративная память. Многослойное хранилище контекста и опыта. В него входят корпоративная база знаний, личная память агента о решениях сотрудника и коллективная память о рабочих паттернах команды.
Human-in-the-loop	Принцип, при котором рискованные действия (внешние коммуникации, изменения в учётных системах, платежи, договорные изменения, листинг и делистинг) проходят через явное подтверждение человека. Подробно в 05-architecture.
Инструментальные политики	Tool policies. Правила платформы, определяющие, какие инструменты доступны конкретному агенту (чтение, запись, отправка сообщений, веб-доступ, межагентское общение). Работают независимо от инструкций модели.
MCP (Model Context Protocol)	Общий интеграционный паттерн. Один коннектор подключает внешнюю систему, а пользоваться им могут разные агенты в рамках своих прав.
Tier-модель автономии	Уровень автономии агента. На Tier 1 агент только читает и готовит черновики, на Tier 2 отправляет и вносит изменения с разрешения человека, на Tier 3 действует сам по расписанию или триггеру в согласованных границах. Подробно в 05-architecture.
Shadow AI	Стихийное использование внешних ИИ-сервисов сотрудниками через личные аккаунты, переводчики и браузерные расширения. ИТ-служба обычно не видит, какие данные туда уходят. Платформа даёт управляемую корпоративную альтернативу.