Категорийный менеджер в среднем ритейлере оперирует данными из 5–7 разрозненных систем: ERP, BI-дашборды, Excel-отчеты поставщиков, внутренние файлы с промо-календарями, почтовые рассылки. Перед встречей с поставщиком он тратит от 40 минут до полутора часов на сбор и сверку цифр. Мультиагентная платформа GlowByte решает эту задачу архитектурно: персональный ИИ-напарник принимает запрос на естественном языке, декомпозирует его на подзадачи, параллельно запускает пять функциональных агентов и через 15–30 секунд возвращает структурированный брифинг с графиками, выводами и прогнозом последствий.
Ключевое отличие от классических BI-систем - не визуализация статичных метрик, а скоординированная работа специализированных агентов, каждый из которых решает узкий класс задач. Text2SQL-агент превращает вопрос «Какие SKU бренда X просели в Южном федеральном округе за последние две недели?» в SQL-запрос, агент мониторинга продаж отдает фактические цифры, агент анализа промо поднимает историю акций по этим позициям, а агент расчета последствий моделирует три сценария: что будет с маржинальностью, если поставщик поднимет закупочную цену на 7%. Результат агрегирует ИИ-напарник - дирижер верхнего слоя, который хранит контекст диалога и отвечает менеджеру связным текстом.
Разберем архитектуру, механизмы безопасности, протокол обмена данными между агентами и два рабочих сценария - подготовку к переговорам и автоматический утренний брифинг.
Почему ритейлу нужны мультиагентные системы: от информационного хаоса к управляемым решениям
Ритейл генерирует терабайты данных ежедневно: чеки, остатки, трафик, промо-механики, цены конкурентов, логистические цепочки. По данным консалтинговых отчетов за 2025 год, объем структурированных и неструктурированных данных в розничной сети из 200+ магазинов удваивается каждые 14–18 месяцев. Категорийный менеджер физически не успевает обработать этот поток. BI-дашборды показывают агрегированные метрики, но не отвечают на вопрос «почему» и не предлагают сценариев действий. Чат-боты на базе одного LLM дают ответы без доступа к реальной аналитике, галлюцинируют цифры и не различают контексты разных категорий.
Одиночный AI-агент, заточенный на одну функцию - например, только Text2SQL или только генерацию отчетов, - не решает проблему комплексно. Он не связывает историю промо с текущими продажами, не учитывает условия прошлых контрактов и не моделирует последствия решений. Мультиагентный подход распределяет нагрузку: каждый агент отвечает за свою зону, а дирижер координирует их работу и собирает целостную картину. Это повышает точность - агенты не пересекаются в зонах ответственности и не конфликтуют за ресурсы, - и сокращает время от запроса до готового аналитического документа.
Платформа GlowByte реализует этот подход в виде двухслойной архитектуры, где верхний слой - персональный ИИ-напарник - работает как единый интерфейс для менеджера, а нижний слой - пять функциональных агентов - выполняют вычисления параллельно. Такой дизайн напоминает архитектуру «коллективного разума», описанную в системах управления знаниями для AI-команд, где общая память и четкое разделение ролей дают прирост производительности до 50%.
Двухслойная архитектура: как ИИ-напарник дирижирует функциональными агентами
Система построена по принципу разделения интерфейса и вычислительного ядра. Верхний слой - персональный ИИ-напарник - принимает запросы на естественном языке, хранит историю взаимодействия, уточняет неоднозначности и возвращает готовый ответ. Нижний слой - пять функциональных агентов - работают асинхронно, каждый в своем контуре данных. Напарник не выполняет аналитику сам: он маршрутизирует подзадачи, ждет результаты от агентов и агрегирует их в связный документ.
Этот подход устраняет главную проблему одиночных LLM-агентов - галлюцинации в цифрах. Функциональные агенты оперируют фактами из базы данных, внутренних документов и промо-календарей, а не генерируют ответ из параметров модели. Напарник получает от них структурированные JSON-пакеты с верифицированными данными и только форматирует вывод.
Персональный ИИ-напарник: интерфейс и оркестрация
Напарник - это NLP-слой с контекстной памятью и планировщиком задач. Когда менеджер пишет «Подготовь данные по поставщику X для переговоров в четверг», напарник выполняет три действия. Первое: извлекает сущности - поставщик X, тип запроса «подготовка к переговорам», временной горизонт. Второе: определяет, какие агенты нужны. Для этого запроса потребуются агент мониторинга продаж (динамика за квартал), агент анализа промо (история акций с этим поставщиком), агент поиска по корпоративной памяти (условия прошлых контрактов) и агент расчета последствий (прогноз при изменении закупочной цены на 5, 10 и 15%). Третье: параллельно отправляет подзадачи этим агентам, собирает ответы и формирует брифинг.
Напарник хранит диалог в течение сессии и может уточнять детали: «По какому федеральному округу смотрим?», «Интересуют все SKU или только топ-20 по обороту?». Контекст не теряется при переключении между задачами - система держит историю взаимодействия и использует ее для сокращения повторных уточнений. Это принципиально отличается от одноразовых запросов к BI, где каждый вопрос требует новой настройки фильтров.
Функциональные агенты: специализация и зоны ответственности
Пять агентов покрывают основные потребности категорийного менеджера. Каждый работает в изолированном контуре с доступом только к тем данным, которые соответствуют его функции и уровню допуска пользователя.
Text2SQL-агент преобразует вопросы на естественном языке в SQL-запросы к корпоративному хранилищу данных. На вход получает текст запроса и схему базы, на выходе - структурированную таблицу с цифрами. Пример: запрос «Покажи продажи молочных продуктов в Северо-Западном округе за июль» превращается в JOIN трех таблиц с фильтрацией по категории, региону и дате. Агент проверяет синтаксис перед выполнением и не пропускает деструктивные операции - INSERT, UPDATE, DELETE блокируются на уровне конфигурации.
Агент расчета последствий моделирует эффект от управленческих решений: изменение цены, вывод SKU из ассортимента, сдвиг промо-периода. На вход получает текущие метрики (оборот, маржинальность, эластичность спроса) и сценарий, на выходе - три варианта прогноза: оптимистичный, базовый, пессимистичный. Модель учитывает сезонность и каннибализацию - если скидка на товар А снижает продажи товара Б, агент это покажет.
Агент поиска по корпоративной памяти работает с неструктурированными данными: PDF-отчетами, протоколами встреч, условиями прошлых контрактов, внутренними регламентами. Документы проиндексированы в векторном хранилище, агент ищет релевантные фрагменты по семантической близости. Пример выдачи: «В контракте от 12.03.2025 зафиксирована ретробонусная ставка 4,2% при выполнении квартального плана на 95%+. Фактическое выполнение за Q2 2026 - 97,3%».
Агент анализа промо оценивает эффективность акций: сравнивает периоды с промо и без, считает incremental lift, ROI акции, каннибализацию смежных SKU. На вход получает промо-календарь и данные продаж, на выходе - сводка с выводами. Пример: «Акция “2 по цене 1” на сыр X в июне дала рост продаж на 34%, но обвалила продажи сыра Y того же бренда на 12%. Совокупный эффект по бренду - плюс 8,7% к обороту».
Агент мониторинга продаж отслеживает метрики в реальном времени: дневной оборот, средний чек, маржинальность, отклонения от плана, out-of-stock по ключевым позициям. При выходе показателя за пределы допустимого коридора агент генерирует алерт с описанием аномалии. Эти алерты попадают в автоматический брифинг, который напарник формирует по расписанию.
Разделение на пять агентов - не архитектурная прихоть, а способ изолировать зоны ответственности и упростить отладку. Если агент анализа промо выдает некорректный ROI, проблема локализована в его контуре и не затрагивает работу мониторинга продаж или Text2SQL. Это соответствует практике production-развертывания многоагентных систем, где каждый агент тестируется и дебажится независимо, как описано в разборе архитектуры самописного AI-агента.
Безопасность и разграничение доступа: Tier-модель в действии
Tier-модель - это трехуровневая система прав, которая определяет, какие данные и функции доступны пользователю. Уровни не пересекаются: повышение Tier расширяет доступ, но не отменяет ограничения нижних уровней.
- Tier 1 - категорийный менеджер. Видит данные только по своей категории и региону. Может запрашивать брифинги, запускать сценарии подготовки к переговорам, получать автоматические отчеты. Не имеет доступа к данным других категорий и к настройкам агентов.
- Tier 2 - руководитель отдела. Видит агрегированные данные по всем категориям своего направления. Может сравнивать метрики разных категорий, настраивать пороги алертов для агента мониторинга продаж, утверждать промо-календари.
- Tier 3 - администратор. Имеет доступ к конфигурации агентов, логам, системе разграничения доступа. Может добавлять новых пользователей, менять Tier-уровни, настраивать источники данных для агентов.
Проверка прав происходит на двух этапах. Первый - при маршрутизации запроса: напарник определяет Tier пользователя и решает, какие агенты доступны. Менеджер Tier 1 не может вызвать агента расчета последствий для категории, к которой не привязан. Второй - на уровне данных: каждый агент перед выполнением задачи проверяет Tier и фильтрует результаты. Если менеджер по бакалее случайно отправит запрос, затрагивающий данные отдела электроники, агент вернет пустой ответ с пометкой «данные недоступны для вашего уровня доступа».
Все действия логируются: кто, когда, какой запрос отправил, какие агенты были задействованы, какие данные получены. Лог-файлы доступны администратору Tier 3 и используются для аудита. Это закрывает риск, подробно разобранный в анализе безопасности ИИ-агентов в продакшене: агент с доступом к данным превращается в потенциального инсайдера, если нет политики разграничения и аудита.
Память и обмен данными: как агенты общаются через A2A
A2A (Agent-to-Agent) - это внутренний протокол асинхронного обмена сообщениями между функциональными агентами и напарником. Агенты не вызывают друг друга напрямую: каждый публикует результат в общую шину данных, откуда напарник забирает пакеты по мере готовности. Это исключает жесткие зависимости и позволяет агентам работать параллельно.
Схема обмена: напарник отправляет подзадачу в формате JSON с полями agent_type, query, user_tier, session_id. Агент обрабатывает запрос и возвращает JSON-пакет с полями status, data, error. Напарник ждет ответы от всех задействованных агентов, проверяет статусы и агрегирует данные. Если агент вернул ошибку - например, Text2SQL не смог распарсить запрос из-за неоднозначности, - напарник переформулирует подзадачу и отправляет повторно или запрашивает уточнение у пользователя.
Корпоративная память реализована как векторное хранилище с индексацией по документам и метаданным. Все внутренние отчеты, контракты, промо-календари и протоколы встреч проходят через пайплайн: извлечение текста, чанкование, эмбеддинг, запись в индекс. Агент поиска по памяти получает запрос, векторизует его и возвращает топ-K релевантных фрагментов с указанием источника и даты. Индексация запускается по расписанию и при добавлении новых документов, поэтому агент всегда работает с актуальной версией данных.
Пример межагентного взаимодействия: агент анализа промо запрашивает у корпоративной памяти исторические данные о прошлых акциях с этим же товаром, чтобы сравнить текущий incremental lift с предыдущими периодами. Он не идет напрямую в векторное хранилище - он отправляет A2A-запрос агенту поиска, получает структурированный ответ и использует его в своих расчетах. Такая цепочка сохраняет изоляцию: агент анализа промо не зависит от формата хранения документов и не дублирует логику поиска.
Сценарии использования: от подготовки к переговорам до автоматического брифинга
Два сценария закрывают основные потребности категорийного менеджера: ad-hoc подготовка к конкретному событию и регулярный мониторинг без ручного запуска.
Подготовка к переговорам: пошаговый разбор
Менеджер вводит запрос: «Подготовь брифинг по поставщику “Молпром” для переговоров 5 августа». Напарник выполняет цепочку:
- Декомпозиция. Извлекает сущности: поставщик «Молпром», дата 5 августа, тип «переговоры». Определяет список агентов: мониторинг продаж, анализ промо, поиск по памяти, расчет последствий.
- Параллельный запуск. Отправляет четыре A2A-запроса. Агент мониторинга продаж собирает динамику оборота, маржинальности и out-of-stock по всем SKU поставщика за последние 6 месяцев. Агент анализа промо поднимает историю акций: какие механики применялись, какой incremental lift дали, какие условия согласовывались. Агент поиска по памяти извлекает условия последнего контракта, протоколы прошлых встреч, зафиксированные договоренности. Агент расчета последствий моделирует эффект от изменения закупочной цены на ±5% и изменения отсрочки платежа.
- Агрегация. Напарник получает четыре JSON-пакета, проверяет статусы, собирает сводный документ. В брифинг попадают: график динамики продаж, таблица с эффективностью прошлых промо, выдержки из контракта с выделенными точками для обсуждения, три сценария с прогнозом маржинальности.
- Выдача. Менеджер получает структурированный документ с оглавлением, графиками и выводами. Время от запроса до готового брифинга - 15–30 секунд.
Автоматический брифинг: экономия времени и проактивный мониторинг
Система настраивается на ежедневную генерацию утреннего отчета. Менеджер задает расписание - например, 8:30 по будням, - и список метрик: оборот за предыдущий день, отклонение от плана, маржинальность по категории, топ-5 растущих и падающих SKU, out-of-stock по ключевым позициям.
Агент мониторинга продаж запускается по расписанию, собирает метрики и сравнивает их с пороговыми значениями. Если отклонение превышает заданный коридор - например, дневной оборот упал более чем на 20% относительно среднего за месяц, - агент помечает это как аномалию и добавляет в брифинг с описанием: «Падение оборота на 23% относительно среднего за июль. Основной фактор: out-of-stock по SKU 45612 (молоко 3,2%, 1л) в 12 магазинах Южного округа. Рекомендуется проверить цепочку поставок».
Брифинг рассылается менеджерам в мессенджер или на почту. Система не принимает решений - только подсвечивает аномалии и предлагает направления для проверки. Ответственность за интерпретацию и действия остается на менеджере.
Ограничения и зоны ответственности: что остается за человеком
Мультиагентная платформа - это инструмент поддержки принятия решений, а не замена категорийного менеджера. Система не делает три вещи.
Не принимает окончательных решений. Агент расчета последствий выдает три сценария, но не говорит, какой выбрать. Выбор зависит от бизнес-контекста, который система не учитывает: отношений с поставщиком, стратегических приоритетов, неформальных договоренностей. Менеджер интерпретирует цифры и принимает решение.
Не гарантирует 100% точность прогнозов. Модель расчета последствий опирается на исторические данные и эластичность спроса, но не учитывает форс-мажоры: резкое изменение курса валюты, уход конкурента с рынка, аномальную погоду. Прогноз - это ориентир с доверительным интервалом, а не точное предсказание.
Требует качественных данных. Если в ERP-системе некорректно заведены SKU, не обновлены цены или отсутствуют данные по промо, агенты выдадут ошибочные результаты. Внедрение платформы начинается с аудита данных, и без этого этапа система не даст ценности. Это подтверждает кейс внедрения ИИ-агента в финтехе: без качественной контекстной инфраструктуры агент не выполняет боевые задачи, но становится полезным инструментом для аналитиков.
Ответственность за решения, принятые на основе данных платформы, лежит на менеджере. Система логирует все выданные рекомендации и использованные данные, но не несет ответственности за бизнес-результат. Это принципиальное архитектурное решение: агенты советуют, человек решает.
Как начать внедрение: первые шаги для ритейлера
Внедрение мультиагентной платформы - это не установка коробочного софта, а последовательный процесс из четырех этапов.
Аудит данных. Проверьте, в каком состоянии находятся источники: ERP, BI-витрины, файлы с промо-календарями, внутренние документы. Оцените полноту, актуальность и согласованность данных. Если справочник SKU дублируется в трех системах с разными названиями, агенты не смогут связать записи. Результат аудита - карта источников с оценкой качества и список проблем, которые нужно закрыть до запуска.
Пилотный проект. Выберите один отдел или категорию для пилота. Идеальный кандидат - категория с понятными метриками, активным промо-календарем и менеджером, который готов тестировать новый инструмент. На пилоте обкатываются сценарии: подготовка к переговорам, автоматический брифинг, ad-hoc запросы. Срок пилота - 4–6 недель, за это время собирается обратная связь и метрики: время на подготовку брифинга, количество ошибок в данных, удовлетворенность менеджера.
Интеграция с существующими системами. Настройте коннекторы к источникам данных, определите частоту обновления индексов корпоративной памяти, пропишите Tier-политики. На этом этапе важно не пытаться подключить все источники сразу - начните с 2–3 критичных и расширяйте по мере стабилизации.
Обучение менеджеров. Проведите две-три сессии с командой: как формулировать запросы, как интерпретировать выдачи агентов, как проверять данные. Менеджеры должны понимать границы системы и не воспринимать ее как «черный ящик», который выдает истину в последней инстанции.
Решение GlowByte - один из примеров реализации мультиагентной архитектуры для ритейла. При оценке вендора смотрите на три параметра: зрелость протокола A2A (насколько гибко агенты обмениваются данными), глубина Tier-модели (сколько уровней доступа и как они настраиваются), качество агента расчета последствий (какие факторы учитывает модель). Без этих компонентов платформа рискует остаться дорогой демонстрацией, которая не масштабируется в продукт.