# Корпоративная мультиагентная ИИ-платформа для ритейла
> Концепт мультиагентной ИИ-платформы для крупных торговых сетей. ИИ-Напарник, функциональные агенты, организационная память, интеграции и безопасное внедрение.
Полный текст всех страниц концепт-вики, собранный для ИИ-агентов. Источники по разделам: https://ai-partner-ru.chvanov.com/raw/
---
# Корпоративная мультиагентная ИИ-платформа для ритейла
> Концепт мультиагентной ИИ-платформы для крупных торговых сетей. ИИ-Напарник, функциональные агенты, организационная память, интеграции и безопасное внедрение.
Источник: https://ai-partner-ru.chvanov.com/raw/index.mdx
:::tip[Для ИИ-агентов и краулеров]
Эта вики рассчитана в том числе и на ИИ-агентов, поэтому мы дружелюбны к ним.
Исходные Markdown-файлы всех страниц доступны для прямого скачивания в формате `text/markdown` с открытым CORS [`/raw/`](https://ai-partner-ru.chvanov.com/raw/).
Для LLM-агентов также доступны [llms.txt](https://ai-partner-ru.chvanov.com/llms.txt) (оглавление со ссылками) и [llms-full.txt](https://ai-partner-ru.chvanov.com/llms-full.txt) (весь текст одним файлом).
:::
Это стартовая страница концепта мультиагентной ИИ-платформы для розничных сетей. Концепт разработан командой Glowbyte на основе внутренних исследований и проектного опыта в ритейле.
Вики работает не только как справочник, но и как рабочая среда. У каждого раздела есть статус готовности, который показывает, что уже можно использовать, а что пока в работе.
## Из этого раздела вы узнаете
- что такое мультиагентная ИИ-платформа и зачем она нужна торговым сетям
- кому адресованы материалы и с чего начать в зависимости от роли
- как устроена вики и в каком порядке двигаться по документам
- какие термины во всех разделах значат одно и то же
- как устроены статусы готовности и где искать открытые вопросы концепта
---
## Коротко о концепте
Категорийный менеджер крупной торговой сети часто работает в одиночку, хотя вокруг него много систем, отчётов и людей. Он отвечает за P&L категории, ведёт переговоры с поставщиками, следит за полкой, оборотом, маржой и промо. Решения приходится принимать быстро, с неполной картиной и под давлением.
Проблема не в том, что данных нет. Их как раз много. Проблема в том, что они разбросаны и обычно требуют ручной сборки.
Та же история повторяется в логистике, ценообразовании, маркетинге и операционной работе.
С корпоративной мультиагентной ИИ-платформой у менеджера появляется новая рабочая модель. В ней два слоя.
Персональный агент конкретного сотрудника. Он помнит контекст, приоритеты и историю решений, это единая точка входа к корпоративным данным и системам, сам подключает нужных функциональных агентов и помогает увидеть следующий шаг.
Специализированные ИИ-исполнители для отдельных классов задач. Сюда входят анализ продаж, подготовка к переговорам, контроль OOS, ценообразование, поиск по базе знаний и оповещения. Обычно менеджер не вызывает их напрямую. Это делает Напарник, когда понимает, какая помощь нужна.
За этими двумя слоями стоят [организационная память](/05-architecture/#память-и-контекст), интеграции с внутренними системами, безопасность, аудит и правила работы агентов.
Подробнее о концепте в [01-vision](/01-vision).
Концепт не привязан к конкретному вендору и остаётся технологически нейтральным (подробнее ниже, в разделе [«Как устроена вики»](/#как-устроена-вики)). Конкретные платформы и инструменты упоминаются в документах только как пример реализации и только там, где это помогает объяснить модель. Обязательного выбора здесь нет.
---
## Для кого написаны материалы
У каждой группы читателей свои вопросы и свой порог терпимости к техническому языку. У каждого артефакта своя аудитория, поэтому собирайте его под конкретную группу читателей.
Сюда попадают коммерческий директор, директор по категорийному менеджменту и операционный директор торговой сети.
Им нужно быстро понять боль, бизнес-эффект, границы пилота и то, почему это не очередная «магия с ИИ».
Начать с [01-vision](/01-vision), [02-partner](/02-partner), [04-usecases](/04-usecases), [07-roadmap](/07-roadmap).
К этой группе относятся архитекторы, CIO и CDO, специалисты по ИТ-безопасности и комплаенсу.
Их интересуют реализуемость, интеграция в текущий ИТ-контур, права доступа, аудит, безопасность данных и отсутствие привязки к одному вендору.
Начать с [05-architecture](/05-architecture), [06-integrations](/06-integrations), разделов про безопасность и управление.
Это пресейл, архитекторы, аналитики и руководители практик.
Им нужно понимать позиционирование Glowbyte, состав MVP, переиспользуемые блоки, зоны риска и то, что ещё надо дописать перед встречей с заказчиком.
Можно открывать весь концепт. Особенно полезны [01-vision](/01-vision), [03-agents](/03-agents), [07-roadmap](/07-roadmap).
К ним относятся категорийные менеджеры, логисты, прайс-менеджеры и другие сотрудники, которые будут работать с платформой каждый день.
Их волнуют простые вещи. Как это поможет лично мне, не будет ли система контролировать каждый шаг, не заменит ли она меня, можно ли ей доверять.
Для них лучше готовить отдельные артефакты на базе [02-partner](/02-partner) и [04-usecases](/04-usecases). Это может быть короткое демо или сценарий «один день с Напарником», который показывает выгоду на конкретном рабочем дне.
---
## Структура документов
Концепт разнесён по семи тематическим документам плюс эта стартовая страница.
- [Обзор концепта](/) (вы здесь). Навигация, глоссарий и статусы готовности.
- [01. Видение](/01-vision). Видение, проблема и позиционирование концепта.
- [02. ИИ-Напарник](/02-partner). Напарник как пользовательская модель.
- [03. Функциональные агенты](/03-agents). Каталог функциональных агентов.
- [04. Сценарии использования](/04-usecases). Разобранные бизнес-сценарии.
- [05. Архитектура](/05-architecture). Логическая архитектура, безопасность и управление.
- [06. Интеграции](/06-integrations). Интеграционный слой и инструменты агентов.
- [07. Дорожная карта](/07-roadmap). Дорожная карта внедрения.
У каждого документа два слоя. Ядро содержит достаточно проработанный материал, который можно брать в разговор с заказчиком, на техническую экспертизу или во внутреннее обсуждение Glowbyte. Скелет содержит секции, гипотезы и темы, которые нужны концепту, но пока не требуют полной детализации.
Эти два слоя связаны со статусами готовности ниже. «Скелет» примерно соответствует статусу «Черновик», а проработанное «ядро» ближе к «Рабочей версии» и «Финальной версии».
---
## Как читать концепт
Маршрут зависит от роли и времени. Ниже пять типовых вариантов.
1. Открыть этот документ и прочитать раздел «Коротко о концепте».
2. Прочитать раздел «Коротко» из [01-vision](/01-vision).
Этого хватит, чтобы понять общую идею без технических деталей.
1. [01-vision](/01-vision) целиком. Боль, видение, нарратив о четырёх эпохах.
2. [02-partner](/02-partner). Единое окно, уровни зрелости, пользовательская модель.
3. Один или два сценария из [04-usecases](/04-usecases).
4. Этапы 0–2 из [07-roadmap](/07-roadmap).
Подходит для разговора на 15–20 минут с коммерческим или операционным руководителем.
1. [05-architecture](/05-architecture) целиком.
2. Релевантные карточки агентов из [03-agents](/03-agents).
3. [06-integrations](/06-integrations). Интеграционные паттерны и MVP-набор.
4. Разделы [«Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа) и [«Управление мультиагентной средой»](/05-architecture/#управление-мультиагентной-средой) из 05-architecture.
Маршрут для архитекторов, CIO и ИТ-безопасности.
1. Этот документ целиком.
2. [01-vision](/01-vision). Нарратив и опорные тезисы для презентации.
3. [03-agents](/03-agents). Агенты для MVP.
4. [07-roadmap](/07-roadmap). Этапы, метрики, границы пилота.
5. [05-architecture](/05-architecture). Оценка реализуемости и трудоёмкости.
Маршрут для пресейла, архитекторов и руководителей практик Glowbyte.
1. Определить аудиторию по этому документу.
2. Взять целевые разделы по теме артефакта.
3. Взять опорные тезисы и нарратив из [01-vision](/01-vision).
Так собирают презентации, одностраничники, демо-сценарии и письма под конкретного адресата.
---
## Как устроена вики
Эта вики работает и как справочник, и как рабочее пространство. Здесь можно прочитать материал, дописать раздел, уточнить формулировку, перевести черновик в рабочее состояние. Ниже несколько правил, которые помогают поддерживать качество материалов по мере их развития.
:::tip[Технологически нейтральный подход]
Мы описываем архитектуру и поведение платформы, а не продаём конкретный продукт. Провайдеры языковых моделей, среды исполнения агентов, мессенджеры, ETL-стек и другие технологии упоминаются только там, где это помогает объяснить реализацию.
:::
:::tip[Язык зависит от раздела]
[01-vision](/01-vision), [02-partner](/02-partner) и [04-usecases](/04-usecases) пишем языком бизнес-заказчика. [03-agents](/03-agents), [05-architecture](/05-architecture) и [06-integrations](/06-integrations) могут быть техническими. [07-roadmap](/07-roadmap) должен быть понятен и бизнесу, и ИТ.
:::
:::tip[Отделяем факты от гипотез]
Если в тексте есть допущение, риск или незакрытый вопрос, его нужно пометить. Такие пункты попадают либо в раздел «Открытые вопросы» этого документа, либо в backlog конкретного файла.
:::
---
## Готовность разделов
Статусы помогают быстро понять, какой материал уже можно использовать, а какой лучше пока не показывать заказчику.
Каркас, черновые формулировки и незакрытые вопросы годятся только для внутренней работы.
Основное содержание готово. Материал можно брать в презентации и обсуждения, хотя полировка ещё возможна.
На этот материал можно ссылаться как на основной источник формулировок и фактов.
| Документ | Статус | Комментарий |
|---|---|---|
| index.mdx | | Здесь мы фиксируем язык, аудитории и правила работы с вики. Дополняем по мере развития концепта. |
| 01-vision | | Развёрнутый нарратив на каркасе четырёх эпох. Технологически нейтральный. |
| 02-partner | | Пользовательская модель Напарника. Сюда входят свойства, единое окно, проактивность, уровни зрелости и метрики. |
| 03-agents | | Каталог агентов с классификацией, пятью приоритетными карточками и границей «агент или скилл». |
| 04-usecases | | Пять детально разобранных сценариев, остальные намечены в backlog. |
| 05-architecture | | Карта архитектуры, оркестрация, память, Tier-модель, безопасность и управление. |
| 06-integrations | | Принципы, типы и паттерны интеграций, MVP-набор и справочник систем. |
| 07-roadmap | | Скелет-каркас. Фазы намечены, детальная проработка под конкретный пилот ещё впереди. |
---
## Открытые вопросы
У концепта есть темы, по которым пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
Мы не сводим их в общий список на этой странице. Открытые вопросы живут в конце каждого тематического документа, рядом с материалом, к которому относятся.
---
## Глоссарий терминов
Здесь термины, которые во всех документах концепта значат одно и то же. Если где-то термин понимают уже или шире, об этом нужно прямо сказать в соответствующем разделе.
| Термин | Определение |
|---|---|
| | Partner Agent. Персональный ИИ-агент конкретного сотрудника. Знает контекст и историю решений сотрудника, даёт единый вход к корпоративным данным и системам, координирует функциональных агентов и может сам инициировать действия. Один сотрудник, один Напарник. |
| | Специализированный ИИ-исполнитель для одного класса задач (анализ продаж, подготовка переговоров, поиск по базе знаний, мониторинг аномалий). Узкая инструментальная политика и доступ только к нужным данным. Обычно его вызывает не сотрудник, а ИИ-Напарник. |
| | Управляемая среда, где работают ИИ-Напарники сотрудников, функциональные агенты, организационная память, интеграции с системами, безопасность и аудит. Через неё персональный пользовательский опыт сочетается с организационным контролем. |
| | Декларативная инструкция о том, как агенту работать. Задаёт, какими инструментами и сервисными агентами пользоваться, в каком формате отвечать и как трактовать данные. Бывает встроенным, общим на компанию или индивидуальным. Граница «агент или скилл» подробно в [03-agents](/03-agents/#когда-агент-а-когда-скилл-напарника). |
| | Сценарий, в котором ИИ-Напарник делегирует задачу одному или нескольким функциональным агентам, ждёт результаты и собирает итоговый ответ. Несколько агентов могут работать параллельно. Подробно в [05-architecture](/05-architecture/#оркестрация-задач). |
| | Прямое общение между агентами (например, Напарник одного сотрудника обращается к Напарнику другого). Политики задают, кто кому и по какому поводу может писать. Подробно в [05-architecture](/05-architecture/#межнапарниковая-коммуникация-a2a). |
| | В обиходе корпоративная память. Многослойное хранилище контекста и опыта. В него входят корпоративная база знаний, личная память агента о решениях сотрудника и коллективная память о рабочих паттернах команды. |
| | Принцип, при котором рискованные действия (внешние коммуникации, изменения в учётных системах, платежи, договорные изменения, листинг и делистинг) проходят через явное подтверждение человека. Подробно в [05-architecture](/05-architecture/#human-in-the-loop). |
| | Tool policies. Правила платформы, определяющие, какие инструменты доступны конкретному агенту (чтение, запись, отправка сообщений, веб-доступ, межагентское общение). Работают независимо от инструкций модели. |
| | Общий интеграционный паттерн. Один коннектор подключает внешнюю систему, а пользоваться им могут разные агенты в рамках своих прав. |
| | Уровень автономии агента. На Tier 1 агент только читает и готовит черновики, на Tier 2 отправляет и вносит изменения с разрешения человека, на Tier 3 действует сам по расписанию или триггеру в согласованных границах. Подробно в [05-architecture](/05-architecture/#tier-модель-автономии). |
| | Стихийное использование внешних ИИ-сервисов сотрудниками через личные аккаунты, переводчики и браузерные расширения. ИТ-служба обычно не видит, какие данные туда уходят. Платформа даёт управляемую корпоративную альтернативу. |
---
# Видение, проблема, позиционирование
> Зачем нужна корпоративная мультиагентная ИИ-платформа в крупной торговой сети, какую проблему она решает и почему её появление сейчас закономерный шаг.
Источник: https://ai-partner-ru.chvanov.com/raw/01-vision.mdx
Документ верхнего уровня концепта. Он объясняет, зачем нужна корпоративная мультиагентная ИИ-платформа в крупной торговой сети, какую проблему она решает и почему сейчас технологическая среда позволяет это сделать.
## Из этого раздела вы узнаете
- в чём структурное одиночество менеджера торговой сети и почему его не решают дополнительные инструменты
- как устроена модель четырёх эпох и где сейчас находятся компании-лидеры
- чем мультиагентная платформа отличается от BI, RPA, чат-ботов и точечных copilot'ов
- какие бизнес-эффекты платформа даёт и для каких ролей она актуальна
- какие базовые допущения приняты за стартовую линию концепта
---
## Коротко
Категорийный менеджер крупной торговой сети сегодня структурно одинок. Он несёт персональную ответственность за P&L своей категории, ведёт переговоры с поставщиками, отвечает за полку, оборот и маржу. Принимает десятки решений в день под давлением, с неполной информацией и без собеседника, который был бы в его контексте и без собственной повестки. То же самое происходит в логистике, ценообразовании, маркетинге, операционном блоке и в любом месте, где сотрудник «ставит шкуру на кон» в рамках своей зоны ответственности.
Большинство торговых сетей закрыли [первые две эпохи](#четыре-эпохи-где-мы-сейчас-и-куда-идём) технологизации работы менеджера, то есть оцифровали процессы и накопили данные. Часть из них уже подходит к [третьей](#эпоха-3-функциональные-ии-агенты), к точечной агентной автоматизации. Но даже у лидеров рынка сохраняется главный разрыв. [Данных и инструментов достаточно, не хватает компетентного партнёра](#данных-достаточно).
:::tip[Главный тезис документа]
Корпоративная мультиагентная ИИ-платформа задаёт новую операционную модель работы менеджера, в которой рядом с ним постоянно есть [**ИИ-Напарник**](/02-partner). Это персональный агент, который знает контекст менеджера и координирует специализированных функциональных агентов. Вместе с ответом он предлагает следующий шаг.
:::
---
## Боль и контекст рынка
### Менеджер, который отвечает за P&L, и устройство его одиночества
Категорийный менеджер в крупной сети работает как мини-предприниматель внутри корпорации. Он отвечает за весь жизненный цикл товарной категории, ассортиментную матрицу, ценообразование, промо, переговоры с поставщиками, оборачиваемость, списания, маржу. По всем этим показателям с него спрашивают, и спрашивают ежемесячно.
Давление на него приходит со всех сторон одновременно. Коммерческий директор хочет маржу и выполнение плана, операционный блок требует оборачиваемости и качества. Поставщик пытается завести в матрицу новые SKU и выторговать себе выгодные условия и временные акции. Конкуренты тоже не дремлют, отвечают ценой и новыми промо. Потребитель голосует рублём, и этот сигнал нужно успеть увидеть и интерпретировать раньше, чем он превратится в проседание категории.
При всём этом менеджер структурно одинок. Вниз по вертикали его команда не несёт того же уровня ответственности и риска, потому что исполнители выполняют, но не разделяют ответственность. Вверх руководитель смотрит на портфель в целом, не погружаясь в нюансы конкретной категории, и приходит со своим набором ожиданий, а не со временем на детальный разбор. Горизонтально смежные подразделения (ценообразование, логистика, маркетинг, аналитика) живут тоже в собственных KPI и собственной картине мира, и их помощь нужно специально запрашивать, согласовывать и ждать.
В результате менеджер принимает решения ***под давлением, с неполной информацией и без постоянного собеседника***, который был бы в его контексте, помнил его прошлые ходы, понимал текущие приоритеты и при этом не имел собственной повестки внутри компании. Такой собеседник нужен, но в действующей операционной модели его место пусто.
### Это касается не только категорийного менеджера
Аналогичное одиночество и аналогичная конфигурация давления воспроизводятся практически во всех ролях, где у сотрудника есть собственная зона риска и P&L-эффект.
Конкретный набор болей у каждого свой, но структура одинакова. У всех высокая персональная ответственность, перегрузка данными и системами, постоянная нехватка контекста смежных функций, и отсутствие компетентного и нейтрального партнёра рядом. Поэтому концепт сознательно платформенный. То есть это среда, в которой каждый сотрудник получает своего ИИ-Напарника, а сами Напарники могут договариваться между собой от имени своих сотрудников.
В дальнейшем основной нарратив концепта строится вокруг категорийного менеджера как самой наглядной и понятной роли. Все механики, описанные на его примере, переносимы на остальные роли с минимальными адаптациями.
### Данных достаточно
У менеджера как правило сейчас уже есть BI-витрины, корпоративные хранилища, ERP, WMS, системы ценообразования и промо-планирования, документооборот, корпоративный мессенджер и портал. У большинства сетей-лидеров на рынке их даже избыточно много, настолько, что один из реальных видов перегрузки менеджера состоит в переключении между десятками систем и сведении их в голове.
Что отсутствует, так это **компетентный партнёр**, который умеет всем этим набором инструментов одновременно пользоваться от имени конкретного менеджера, в его контексте и в его темпе. Поэтому вопрос «не хватает ли нам ещё одной аналитической системы или ещё одного дашборда» в большинстве случаев имеет один ответ. Систем хватает. Не хватает такого партнёра.
---
## Четыре эпохи. Где мы сейчас и куда идём
Взаимодействие менеджера торговой сети с корпоративной средой раскладывается на четыре эпохи. Это не строгая историческая периодизация, а скорее рамка для понимания этого документа. Она помогает быстро локализовать заказчика, отделить уже сделанное от ещё не сделанного и показать, чем мультиагентная платформа отличается от того, что уже привычно.
Менеджер работает телефоном, почтой, таблицами и общими папками, собирая данные вручную, и большую часть времени тратит именно на эту сборку информации.
BI-дашборды, ЭДО, интеграции, RPA. Часть процессов автоматизирована. Ограничение в том, что автоматизация работает только в заранее заданных рамках. Нестандартные ситуации всё ещё требуют ручной работы.
Специализированные [агенты по функциям](/03-agents). Ограничение в том, что агентов становится слишком много и координационная нагрузка ложится на человека.
Персональный [агент-Напарник](/02-partner) с контекстом. Единая точка входа, использует функциональных агентов, действует проактивно. Агенты разных сотрудников взаимодействуют друг с другом.
### Эпоха 1. Инструменты
К базовым средствам производства менеджера относятся телефон, электронная почта, табличный редактор, общие папки, бумажные регламенты. Обмен информацией происходит вручную, отчёты собирают «руками», аналитика возможна, но дорогая и медленная. Эта эпоха в крупных сетях формально завершена много лет назад, но её следы (например, ручная сборка отчётов в Excel или отправка важных решений по почте без следа в учётных системах) встречаются и сейчас.
Главное ограничение эпохи в том, что каждое действие стоит человеческого времени. Менеджер большую часть рабочего дня тратит не на принятие решений, а на сборку и передачу информации.
### Эпоха 2. Автоматизация
Это эпоха, в которой сейчас уверенно живёт большинство крупных торговых сетей. Внедрены и работают BI-дашборды, ЭДО, корпоративные порталы, интеграции почты и календаря, RPA-сценарии для рутинных операций, корпоративный поиск, базы знаний, системы документооборота. Данные, прежде разрозненные, собраны в хранилище. Часть стандартизированных процессов автоматизирована.
В эту эпоху процессы уже перестали зависеть от наличия конкретного человека в нужный момент. Например, нужный отчёт чаще всего собирается сам, а согласование документа идёт по маршруту ЭДО. Время менеджера освободилось от части механической работы.
Но главное ограничение эпохи в том, что автоматизация работает в рамках заранее заданных процессов и заранее заданных вопросов. Как только менеджеру нужно что-то нестандартное (нестандартный срез данных, нетривиальный сценарий, ситуация без готового регламента), он возвращается к ручной работе, постановке задач смежникам и долгим циклам ожидания.
### Эпоха 3. Функциональные ИИ-агенты
Это эпоха, в которую сейчас входят технологические лидеры рынка. Появляются специализированные ИИ-агенты, каждый из которых берёт на себя один класс задач.
Вот несколько примеров таких [функциональных агентов](/03-agents).
- [Агент факторного анализа](/03-agents/#11-агент-факторного-анализа) диагностирует причины отклонений в продажах. Раскладывает план/факт по факторам (каннибализация промо, OOS, демпинг конкурента, проблема с планограммой, недовоз с РЦ, ценовой эффект, сезонность) и строит структурированную диагностическую карточку с главным выводом, доказательной базой и отвергнутыми гипотезами.
- С [Text2SQL-агентом](/03-agents/#5-text2sql) (его ещё называют GenBI) менеджер запрашивает данные у корпоративного хранилища на естественном языке, без участия дата-инженеров.
- [Агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов) ищет ответы по регламентам, кейсам, прецедентам, стандартам переговоров.
- [Агент переговоров](/03-agents/#6-агент-переговоров-и-поставщика) готовит досье поставщика и аргументацию для встречи.
- [Агент аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) в фоновом режиме отслеживает отклонения и эскалирует значимые из них.
Каждый такой агент сокращает время на свой класс задач и снимает часть нагрузки с менеджера. Но у этой эпохи есть фундаментальное ограничение, которое менеджер обнаруживает примерно на пятом-шестом подключённом агенте.
:::caution[Главное ограничение Эпохи 3]
Менеджер чаще всего работает не с отдельными задачами, а с ситуациями. Например, когда поставщик просит повысить закупочную цену. Она требует одновременно анализа продаж этого поставщика, индекса цен на сырьё, истории переговоров, прецедентов уступок, оценки доли SKU в категории, понимания календаря сезонности, и всё это нужно увязать в один аргументационный пакет к условной завтрашней встрече. С функциональными агентами менеджер должен сам знать, к какому из них идти с какой частью ситуации (и где вообще найти ссылку на доступ к нужному агенту), сам последовательно их вызывать, сам синтезировать результаты, сам помнить, что ещё забыто. То есть координационная нагрузка возвращается на человека.
:::
Чем больше функциональных агентов в компании, тем выше эта координационная нагрузка, и на определённом их количестве отдача от каждого нового начинает убывать. Добавлять агентов всё ещё можно, а вот пользоваться ими становится сложнее, и линейное расширение каталога перестаёт давать пропорциональный эффект.
### Эпоха 4. ИИ-Напарник и мультиагентная среда
Четвёртая эпоха снимает ограничение третьей за счёт смены модели взаимодействия менеджера с корпоративной средой.
В её центре находится [ИИ-Напарник](/02-partner) (персональный агент, закреплённый за конкретным сотрудником). Напарник работает как единая точка входа ко всей корпоративной среде, включая данные, системы, документы, коллег и других агентов. Сотрудник не выбирает, к какому из агентов обратиться. Он формулирует задачу или ситуацию своим обычным языком, и Напарник сам определяет, кого из [функциональных агентов](/03-agents) задействовать и в каком порядке их вызвать. Напарник же возвращает синтезированный результат. И дальше он сам видит следующий шаг, который из этого результата следует, а значит может действовать проактивно: например, дать рекомендации или подготовить письмо.
Под Напарником сохраняется и продолжает развиваться слой [функциональных агентов](/03-agents). Те же специализированные исполнители третьей эпохи, но теперь они работают не напрямую с менеджером, а под координацией его Напарника. Количество функциональных агентов можно расширять без увеличения когнитивной нагрузки на менеджера, потому что добавление нового агента означает только то, что Напарник теперь будет уметь делать ещё что-то.
И, наконец, четвёртая эпоха предполагает, что Напарники разных сотрудников могут **разговаривать между собой**, от имени и в интересах своих людей, под [управляемой политикой межагентского взаимодействия](/05-architecture/#межнапарниковая-коммуникация-a2a). Это превращает корпоративную среду из набора связанных систем в настоящую агентную среду, в которой задачи и информация перемещаются между подразделениями быстрее, чем это умеют люди, и при этом любой такой обмен фиксируется, аудируется и при необходимости подтверждается человеком.
:::tip[Где мы сейчас]
Большинство компаний сегодня находятся на переходе от Эпохи 2 к Эпохе 3. Этот документ описывает Эпоху 4 и показывает, что вход в неё сегодня уже стал задачей инженерной, а не исследовательской.
:::
---
## Ограничения текущих подходов
Мультиагентная платформа закрывает иную часть пространства задач, чем классы решений, к которым у заказчика уже есть рабочее отношение. Цель здесь не обесценить их, а показать, что они закрывают, а что нет, и почему для незакрытой части нужна отдельная архитектура.
| Класс решений | Что закрывает | Что не закрывает |
|---|---|---|
| **BI и аналитические витрины** | Надёжный, верифицированный взгляд на данные. Заранее сформулированные вопросы. | Нестандартный вопрос, возникший прямо сейчас. *Почему* цифра упала. *Что* с этим делать. Связь аналитики с почтой, календарём, переговорами. |
| **RPA и автоматизация** | Задачи с жёсткой структурой и предсказуемым ходом. | Неопределённость, ситуации, которые отличаются друг от друга. |
| **Чат-боты и поисковые помощники** | Простые вопросы по документам. Улучшенный поиск. | Персональный контекст. Инициатива. Оркестрация в нескольких системах. Сквозная память. |
| **Copilot'ы внутри приложений** | Усиление конкретного продукта (формулировки, операции, интерфейс). | Соседние системы. Действия поверх корпоративной среды как целого. |
| **Функциональные ИИ-агенты Эпохи 3** | Решают целые классы задач, недоступные предыдущим решениям: диагностика причин отклонений, запросы к данным на естественном языке, подготовка досье поставщика, поиск по регламентам и прецедентам. | Координационная нагрузка возвращается на человека. См. предыдущий раздел. |
:::tip[Платформа четвёртой эпохи не отменяет ничего из перечисленного]
Мультиагентная платформа использует тот же BI как источник данных, опирается на RPA в точках стандартизированной автоматизации, не конкурирует с встроенными copilot'ами в их собственных нишах и потребляет результаты ML-моделей как сигналы. Добавленная стоимость платформы состоит в появлении нового слоя над ними. Этот слой даёт менеджеру персонального партнёра и управляемую среду его взаимодействия со всей корпоративной средой.
:::
---
## Видение новой модели работы
В целевой модели работа менеджера выглядит существенно иначе.
1. День менеджера начинается не с обхода десятка систем, а с короткого брифинга от Напарника. Что произошло за ночь, какие аномалии замечены, какие критические письма пришли, какие встречи в календаре требуют подготовки, что из вчерашних договорённостей просрочено и кому уже отправлено напоминание. Напарник фильтрует входящий поток через приоритеты этого менеджера, поэтому в брифинг попадает только значимое для него.
2. В течение дня менеджер обращается к Напарнику в том же мессенджере, где он общается с коллегами и поставщиками. Запросы менеджер формулирует обычным языком, например, *«почему упала молочка в Сибири»*, *«подготовь к завтрашней встрече с поставщиком X»*, *«собери статусы по промо у коллег»* или *«верни мне рекомендацию по новой матрице к четвергу»*. Напарник либо отвечает сам, либо делегирует функциональному агенту, либо запускает несколько параллельно и возвращает синтезированный ответ. В ответе есть результат и следующий шаг, например *«вот аргументация по поставщику, рекомендую начать с SLA, там сильная позиция. Готовлю слайды?»*.
3. Часть полезной работы Напарник делает без запроса. Замеченную Напарником аномалию в категории менеджер с утра получает уже разобранной в брифинге. Письмо о срыве поставки сразу уходит логистам как эскалация, а антикризисный звонок к этому моменту уже стоит в календаре. А по прошлой договорённости с коллегами, где просрочен дедлайн, исполнителю само уходит напоминание, и менеджеру не приходится быть контролёром.
:::caution[Граница автономии]
Критические действия (внешние коммуникации, изменения в учётных системах, запуски платежей, листинг и делистинг) Напарник никогда не делает сам. Он готовит и формулирует рекомендацию, а подтверждает её менеджер явным кликом. Эта граница (Human-in-the-loop) вшита в архитектуру платформы, её задаёт [Tier-модель автономии](/05-architecture/#tier-модель-автономии). Чем выше потенциальный эффект действия и чем выше его необратимость, тем строже требования к подтверждению.
:::
Параллельно меняется горизонтальная коммуникация между подразделениями. Когда менеджеру нужны данные у коллеги из логистики, его Напарник обращается к Напарнику этого коллеги, тот собирает ответ, коллега валидирует, и Напарник возвращает его обратно. Люди теперь не ругаются из-за задержек. Между ними появляется аудируемый поток запросов, который кстати бонусом превращается в данные о том, как работает организация.
И, наконец, опыт перестаёт исчезать с уходом сильных сотрудников. Теперь в [**организационной памяти**](/05-architecture/#память-и-контекст) остаются удачные решения, сильные аргументы из переговоров и нестандартные диагностики. Преемник сильного менеджера получает доступ к прошлым кейсам с первого дня, вместо того чтобы собирать их заново по обрывкам файлов и устным рассказам.
:::tip[Это и есть видение Эпохи 4]
Постоянный компетентный партнёр рядом с менеджером, обладающий полным доступом к корпоративной среде, действующий по правилам, договорённым с организацией, и оставляющий за человеком ровно те решения, которые человек должен оставлять за собой.
:::
---
## Что такое корпоративная мультиагентная ИИ-платформа
Корпоративная мультиагентная ИИ-платформа это управляемая среда, в которой одновременно сосуществуют несколько типов сущностей и где их взаимодействие остаётся безопасным и предсказуемым.
В платформе есть пять опорных слоёв.
На каждого сотрудника приходится один персональный агент. Такой Напарник знает контекст менеджера и его приоритеты и помнит историю прошлых решений этого сотрудника. Со временем он подстраивается под привычный сотруднику стиль общения. Также Напарник координирует функциональных агентов. Может работать проактивно по расписанию и триггерам. И общается с Напарниками коллег по явным политикам.
Специализированные ИИ-исполнители работают каждый со своим узким назначением и узкой инструментальной политикой. Их вызывают Напарники. Отвечают за качество исполнения конкретного класса задач. Каталог функциональных агентов расширяется по мере накопления зрелости.
Трёхуровневое хранилище контекста и опыта объединяет корпоративную базу знаний (регламенты, прецеденты, отчёты), агентскую память (история решений конкретного сотрудника) и коллективную память (паттерны успешных решений всей команды).
Коннекторы соединяют платформу с корпоративными системами, среди которых DWH, BI, ERP, WMS, CRM, ценообразование, промо-планирование, мессенджер, почта, календарь, базы знаний и внешние рыночные источники. Коннектор пишут один раз, и им пользуются все агенты.
Этот слой задаёт модель доверия с границами и изоляциями. Инструментальные политики работают на уровне платформы, но не на уровне инструкций модели. Сюда же относятся Tier-модель автономии, обязательный Human-in-the-loop для критичных операций, сквозной аудит и логирование, защита от prompt injection и контролируемое размещение данных и моделей.
---
## Ценность для бизнеса
Бизнес-эффект платформы складывается из пяти направлений. У каждого из них есть наблюдаемые проявления в первые недели пилота и измеримый накопительный эффект на горизонте полугода.
:::note[Важно учесть!]
Максимальный эффект от внедрения платформы достигается, когда в компании уже есть несколько функциональных агентов. Если внедрение платформы предполагает в том числе и создание нескольких базовых функциональных агентов с нуля, срок появления ценности будет несколько дольше.
:::
Время от появления вопроса у менеджера до получения доказательного ответа сокращается на порядок. Запросы, требующие сегодня постановки задачи дата-инженерам и спринта ожидания, выполняются в минутах. Аномалии, которые сегодня всплывают через несколько дней, обнаруживаются в течение часов. Цикл от вопроса до ответа сокращается с дней до минут.
Менеджер перестаёт быть диспетчером между десятком систем и пятью-шестью функциональными агентами. Внимание возвращается к управленческим решениям, туда, где экспертиза создаёт стоимость. Особенно важно для лучших менеджеров. Они страдают от перегрузки острее всех.
За каждым решением стоит подготовленная доказательная база, прозрачная логика и явные отвергнутые гипотезы. За каждым значимым внешним взаимодействием стоит персонализированное досье. На переговорной марже это даёт прямой P&L-эффект, на масштабе крупной сети десятки миллионов рублей.
Лучшие практики и нестандартные диагностики становятся капиталом организации, а не личным капиталом сотрудников. Преемственность при увольнении сильного менеджера перестаёт быть катастрофой. Онбординг нового сотрудника сокращается в разы.
Сотрудники уже сейчас используют внешние ИИ-сервисы (ChatGPT, переводчики, ИИ-расширения). Это создаёт неуправляемый периметр. Корпоративная платформа даёт сотруднику управляемую альтернативу, которая удобнее личных инструментов и при этом полностью в корпоративном контуре. Shadow AI сокращается, потому что появляется лучший легальный вариант.
Конкретный набор метрик и их пороги фиксируются на пресейле под конкретного заказчика. Как их разносят по уровням и чем измеряют, описано в [02-partner, раздел «Метрики ценности ИИ-Напарника»](/02-partner/#метрики-ценности-ии-напарника).
---
## Для кого в компании в первую очередь будет актуален ИИ-Напарник
Платформа изначально проектируется как многоролевая. На старте пилот разворачивается в одном подразделении на нескольких сотрудниках-добровольцах, как правило, это категорийные менеджеры коммерческой дирекции. Но ценность платформы раскрывается тем сильнее, чем больше ролей в неё вовлечено.
В оставшихся документах концепта подробно раскрывается опыт категорийного менеджера как референсной роли. Распространение модели на остальные роли - отдельный этап дорожной карты, и устроен он типовым образом. Новая роль означает новые шаблоны Напарника, новые функциональные агенты в каталог и новые коннекторы в интеграционный слой. Основная архитектура платформы при этом не меняется.
---
## Базовые допущения концепта
Ниже решения, которые приняты как стартовая линия. При работе с конкретным заказчиком они могут измениться, но внутри концепта мы отталкиваемся от них.
:::note[Канал доступа сотрудника к Напарнику]
На текущем этапе основной канал устроен как корпоративный мессенджер с мобильной и десктопной версиями. Это может быть Telegram, MAX, eXpress, Mattermost или другой инструмент, который принимает ИТ-политика заказчика.
Веб-интерфейс, дашборды и длинные рабочие артефакты можно добавлять после пилота. Голосовой и realtime-каналы (например, ассистент на переговорах) лучше рассматривать как отдельные сценарии в [04-usecases](/04-usecases).
На подготовительном этапе выбор мессенджера напрямую влияет на список работ, поэтому он фиксируется одним из первых.
:::
:::note[Размещение LLM и данных]
Концепт допускает три модели развёртывания.
Гибридная схема оставляет данные on-prem, а языковая модель вызывается через корпоративный шлюз к внешнему провайдеру. Полностью on-premise вариант разворачивает и данные, и модели внутри периметра заказчика. Третий путь использует российские облачные LLM-сервисы.
Универсальной рекомендации здесь нет, выбор делается под конкретного заказчика.
:::
:::note[Роль Glowbyte при внедрении]
Glowbyte ведёт пилот и внедрение, но ИТ-команда заказчика подключается с самого начала. К архитектурным решениям, выбору интеграций и передаче знаний.
К 6–12 месяцу должна появиться модель совместной эксплуатации. Glowbyte остаётся архитектурным партнёром и развивает каталог агентов и сценариев. Заказчик постепенно берёт на себя операционную поддержку. Эта модель раскрывается в [07-roadmap, раздел «Организационные условия успеха»](/07-roadmap/#организационные-условия-успеха).
:::
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Четыре эпохи это рамка, а не модель зрелости]
«Четыре эпохи» задуманы как нарративная рамка для быстрого разговора с заказчиком, но легко считываются как строгая модель зрелости. Это создаёт два риска. Заказчик может неверно локализовать себя (объявить себя в Эпохе 3, имея единичный пилотный агент) и воспринять Эпоху 4 как соседний шаг, до которого «полгода», тогда как разрыв между координируемым каталогом агентов и связностью реальных корпоративных систем гораздо больше. Пока не решено, нужна ли отдельная диагностика готовности, чтобы рамка не превращалась в самооценку.
:::
:::caution[Тезис «данных достаточно, не хватает партнёра» не универсален]
Центральный тезис документа верен для зрелых сетей с устоявшимся хранилищем и понятным семантическим слоем. Но у части заказчиков данные фрагментированы, противоречивы или не описаны, и единого согласованного определения даже базовых метрик (что считать продажами, маржой, OOS) нет. Для них Напарник без предварительной работы над качеством данных и семантикой даст уверенно звучащие, но ненадёжные ответы. Где проходит граница, за которой внедрение партнёра нужно откладывать до наведения порядка в данных, концепт пока не формулирует.
:::
:::caution[Экономика платформенности против узкого старта не доказана]
Тезис «каждому сотруднику свой Напарник» звучит как сильное продуктовое обещание, но экономика и организационная стоимость широкого охвата не подтверждены на практике. Пилот сознательно стартует узко (одно подразделение, несколько добровольцев), и неясно, на каком масштабе межнапарниковая коммуникация начинает давать эффект, оправдывающий стоимость поддержки множества ролевых шаблонов, коннекторов и политик. Возможно, что для значительной части ролей экономически выгоднее остаться на уровне функциональных агентов Эпохи 3.
:::
:::caution[«Вход в Эпоху 4 это задача инженерная, а не исследовательская»]
Это сильное и оспоримое утверждение. Базовая оркестрация и интеграция действительно стали инженерными. Но устойчивость к prompt injection, надёжная оценка качества ответов агентов (eval) и управление политиками межагентского взаимодействия (A2A) отчасти всё ещё остаются исследовательскими задачами без отраслевого стандарта. Скептичный архитектор справедливо возразит, что именно эти нерешённые области и определяют допустимость промышленной эксплуатации.
:::
---
# ИИ-Напарник
> Что такое ИИ-Напарник, как он устроен с точки зрения сотрудника, как становится единым окном к корпоративной среде и где проходит граница его ответственности
Источник: https://ai-partner-ru.chvanov.com/raw/02-partner.mdx
Здесь — ИИ-Напарник глазами сотрудника: что это за сущность, как он выглядит в рабочем дне, какие задачи берёт на себя и где останавливается.
## Из этого раздела вы узнаете
- какие три свойства делают Напарника Напарником, а не чат-ботом или copilot'ом внутри приложения
- как он становится единым окном к корпоративной среде и где проходит граница его проактивности
- что такое персональный контекст сотрудника и как сотрудник настраивает его через скиллы
- как Напарник координирует функциональных агентов и растёт по уровням зрелости
- где проходит граница его ответственности (Tier-модель) и какими метриками измерять его ценность
---
## Коротко
ИИ-Напарник работает как персональный агент конкретного сотрудника. У каждого менеджера свой Напарник, и он живёт в том же мессенджере, где менеджер уже общается с коллегами и поставщиками. Напарник знает приоритеты и историю решений своего человека, имеет доступ к корпоративным данным и системам в рамках его прав, координирует функциональных агентов и видит следующий шаг.
С точки зрения сотрудника всё проще, чем звучит. У него появляется один собеседник, к которому можно прийти со словами *«почему упала молочка в регионе Х»* или *«подготовь к завтрашней встрече по KPI категории»*, и в ответ получить готовый разбор с рекомендацией. Под капотом для этого может задействоваться несколько разных агентов и систем, но менеджеру это знать не обязательно.
:::tip[Главный тезис документа]
Напарник работает как персональный собеседник сотрудника и единое окно к корпоративной среде. Он знает контекст и историю решений своего человека и вместе с ответом предлагает следующий шаг, подключая при необходимости [функциональных агентов](/03-agents); критичные решения остаются за человеком.
:::
---
## Кто такой ИИ-Напарник
ИИ-Напарник работает как персональный ИИ-агент сотрудника. У Напарника есть три свойства, и важны они все вместе. Если убрать любое, остаётся либо чат-бот, либо copilot внутри одного приложения, либо функциональный агент из [третьей эпохи](/01-vision/#эпоха-3-функциональные-ии-агенты).
Напарник закреплён за конкретным сотрудником. Он знает его роль, портфель ответственности, KPI, активные переговоры, стиль коммуникации и историю решений. При этом Напарник менеджера A не имеет доступа к данным менеджера B, кроме случаев явной коммуникации между сотрудниками.
Один интерфейс ко всей корпоративной среде. Сотрудник уже не выбирает, к какой системе или агенту обратиться. Он формулирует задачу обычным языком, а Напарник сам определяет, кого подключить и в каком порядке.
Вместе с ответом Напарник предлагает следующий шаг и критический анализ. У него нет своей повестки внутри компании, поэтому он может прямо сказать *«здесь цифры не сходятся»* или *«в прошлый раз похожее решение просадило маржу»*.
Здесь же видна разница с ассистентами внутри отдельных приложений. Copilot в BI помогает работать с BI, copilot в почте помогает с почтой, а Напарник работает с ситуацией сотрудника целиком и обращается к корпоративным системам как к инструментам под конкретную задачу.
---
## ИИ-Напарник как единое окно
### Один интерфейс вместо десятка
Категорийный менеджер обычно держит в голове карту систем. Ему приходится помнить, где лежат продажи и остатки, где ведутся промо и переговоры, в какой системе хранятся регламенты, а где висят задачи. Часть из этих систем дублирует друг друга, часть конфликтует, часть периодически ломается. Само переключение между ними занимает заметную часть рабочего времени, и менеджер регулярно теряет контекст. Ситуация знакомая. Зашёл в один отчёт за цифрой, отвлёкся на письмо, к цифре уже не вернулся, потому что письмо породило ещё три задачи.
Напарник убирает эту карту из головы сотрудника. Например, менеджер пишет в мессенджер *«дай продажи по молочке за март по регионам»* и тут же получает ответ. За этим ответом могут стоять [Text2SQL-агент](/03-agents/#5-text2sql), обращение к DWH, проверка через агента базы знаний, но всё это происходит на стороне Напарника. Точно так же менеджер спрашивает *«что у нас по поставщику X»*, *«есть ли свободный час с Ивановым на четверг»*, *«найди регламент по делистингу»*. То есть везде остаётся один и тот же канал и обычный язык.
Базовый канал коммуникации устроен как [корпоративный мессенджер](/06-integrations/#корпоративный-мессенджер) с мобильной и десктопной версиями. Веб-интерфейс и дашборды появляются позже, под конкретные сценарии. Голосовой ассистент на переговорах остаётся отдельной историей, она описана в [открытых вопросах 04-usecases](/04-usecases/#открытые-вопросы).
### Проактивность
Часть полезной работы Напарник делает сам, без запроса. Это возможно, потому что у него есть расписание сотрудника, понимание его приоритетов и доступ к потокам данных. Утром он готовит брифинг, перед встречей собирает досье, по сработавшему алерту приносит готовый разбор, а коллеге сам напоминает про обещанный к среде расчёт. Как устроен этот проактивный цикл на уровне платформы, разобрано в [05-architecture, раздел «Проактивный цикл»](/05-architecture/#проактивный-цикл).
Проактивность сотрудник обязательно настраивает под себя. Менеджер задаёт пороги чувствительности (например, *«не дёргай, если отклонение меньше 5%»*) и определяет приоритеты по категориям, поставщикам, SKU. Если этого не сделать, Напарник довольно быстро превращается в источник шума, и им перестают пользоваться.
### Рабочий день, в котором Напарник работает сам
Менеджер делает свою работу как раньше, а Напарник параллельно с ним делает то, что иначе пришлось бы держать в голове или откладывать на потом.
1. До прихода менеджера, к 9:00. Утром в чате уже лежит брифинг с приоритетными задачами дня. По двум критичным поставкам Напарник за ночь сам написал логистам и собрал у них предварительные ответы. Менеджер видит сводку и сразу понимает, чем заниматься первым, без обхода десятка систем.
2. Около 10:30 в одной из категорий случается резкий провал по конкретным SKU. Напарник не пересылает менеджеру голый алерт. Он сам прогоняет первичный разбор, отвергает очевидные гипотезы и приходит с диагностикой и тремя вариантами действий. Менеджер выбирает один, остальное Напарник доводит сам.
3. За час до встречи, к 13:00. В календаре стоят переговоры с поставщиком в 14:00. Никто Напарника не дёргает, но он сам видит встречу и заранее готовит досье. Туда попадают индексы цен, история уступок, статусы SLA и доля SKU в категории. К менеджеру досье приходит до того, как тот успевает его попросить.
4. В течение дня Напарник контролирует договорённости: на прошлой неделе коллега из соседнего отдела обещал расчёт к среде. Сегодня среда. Напарник сам напоминает Напарнику коллеги, получает обновлённый срок и приносит менеджеру результат. Менеджеру не пришлось превращаться в контролёра.
5. После окончания рабочего дня менеджер ушёл, а Напарник продолжает мониторить метрики и события. Если случается срыв доставки или жалоба от партнёра, Напарник классифицирует событие по согласованным правилам. Срочное уведомление уходит менеджеру в мессенджер сразу же. Менее срочное копится в утренний брифинг следующего дня.
Здесь видна проактивная половина работы. Реактивная половина (то есть случаи, когда менеджер сам приходит с вопросом или поручением), описана ниже в разделе «[Как выглядит диалог с Напарником](#как-выглядит-диалог-с-напарником)».
---
## Как выглядит диалог с Напарником
Выше в разделе «Рабочий день» показано, что Напарник делает сам. Дальше четыре коротких диалога. Они показывают вторую половину работы, ту, где менеджер сам приходит к Напарнику с вопросом или поручением. Это не сценарии бизнес-использования, они полностью разворачиваются в [04-usecases](/04-usecases). Здесь интересна форма реплик.
**Менеджер.** *«Почему упала молочка в Сибири за март?»*
**Напарник.** *«Главная причина в росте закупочных цен Danone на 8% и недопоставках трёх SKU из-за SLA 91% при норме 95%. Совокупный эффект на категорию -9,2%. Доказательная база и отвергнутые гипотезы лежат в карточке ниже. Через три дня встреча с Danone, могу подготовить досье»*.
**Менеджер.** *«Подготовь. И добавь в разбор демпинг конкурента, мы это видели в марте»*.
**Напарник.** *«Принял. Учту в следующих похожих разборах»*.
**Менеджер.** *«Saverio просит +5% к закупочной цене, встреча завтра в 14:00»*.
**Напарник.** *«Готовлю досье. Аргументы против повышения такие. Индекс цен на сырьё -3% за квартал, недопоставки 17 млн ₽ из-за SLA 87% при норме 95%, на встрече в сентябре поставщик уступил при угрозе делистинга, доля SKU в категории 34%. Рекомендую начать с SLA, это самая сильная позиция. Слайды нужны?»*
**Менеджер.** *«Собери у маркетинга и логистики статусы по летнему промо»*.
**Напарник.** *«Отправил запросы Напарникам Петровой и Иванова. Жду ответы, обычно собирается за 20–40 минут. Пришлю сводку, как только всё валидируют»*.
*Через 35 минут.*
**Напарник.** *«Сводка готова. По двум промо из четырёх есть отставание от плана с указанием причин. Отдельно отметил, что у Иванова открытый вопрос по бюджету, ждёт твоего решения»*.
**Менеджер.** *«Поставь встречу с Петровой на этой неделе на 30 минут, обсудить промо в кондитерке»*.
**Напарник.** *«Договорился с её Напарником. Свободный слот пришёлся на четверг 11:30. Поставил, повестку добавил. К началу встречи пришлю короткий бриф, в нём будет, что у Петровой по этой категории сейчас и какие открытые вопросы остались с прошлого раза»*.
В реальном разговоре будет больше уточнений, поправок и переключений, здесь это убрано для краткости. Зато хорошо видна форма реплики. Везде всё тот же единый канал из раздела «[ИИ-Напарник как единое окно](#ии-напарник-как-единое-окно)», а в ответ приходит разбор вместе с предложением следующего шага.
---
## Персональный контекст пользователя
Напарник полезен ровно в той мере, в какой он понимает контекст конкретного сотрудника. Подробное устройство памяти и состав каждого слоя описаны в [05-architecture, раздел «Память и контекст»](/05-architecture/#память-и-контекст). Здесь интересно только то, что из этого видит сам сотрудник.
Контекст растёт со временем. Чем дольше Напарник работает с менеджером, тем точнее он попадает в его задачи. Он запоминает, как сотрудник формулирует поручения, какой длины ответы любит, какие аргументы у него обычно срабатывают на переговорах, как он реагировал в похожих ситуациях раньше. За счёт этого «Напарник, которого включили вчера» сильно отличается от «Напарника, который работает с менеджером полгода». Это свойство сотрудник замечает в работе сам.
Напарник также ведёт профили контрагентов и коллег, с которыми работает менеджер. Здесь профиль одного и того же поставщика у разных менеджеров будет разным, потому что они наблюдают его в своих переговорах. Архитектурное устройство профилей и правила обмена ими между Напарниками описаны в [05-architecture, раздел «Профили контрагентов»](/05-architecture/#профили-контрагентов).
### Скиллы как пользовательская настройка
Часть персонализации сотрудник задаёт сам через скиллы. Это короткие декларативные инструкции о том, как Напарник должен работать с этим человеком. Несколько типичных формулировок.
- *«Отчёты собирай в формате с разрезом до и после промо»*.
- *«По поставщикам категории X сразу добавляй долю SKU в категории»*.
- *«При отклонениях меньше 5% не дёргай»*.
- *«При подготовке к комитету сразу добавляй разрез по конкуренту»*.
Скиллы отличаются от того, что Напарник запоминает сам, тем, что в них живут правила, а не накопленная история решений. Сотрудник может добавить, отключить или поправить скилл в любой момент. Платформенный механизм скиллов разобран в [05-architecture, раздел «Скиллы»](/05-architecture/#скиллы).
---
## Координация функциональных агентов
Сам Напарник как правило не делает факторный анализ, не пишет SQL и не ищет по регламентам. Эту работу он делегирует специализированным функциональным агентам. Примеры таких агентов в [03-agents, раздел «Классификация функциональных агентов»](/03-agents/#классификация-функциональных-агентов), а здесь интересно, как Напарник ими управляет.
Типовой цикл выглядит примерно так.
1. Сотрудник формулирует ситуацию обычным языком, например *«почему упала молочка в Сибири»*.
2. Напарник распознаёт класс ситуации и собирает план разбора. В простом случае хватит одного агента, в сложном понадобится два-три, работающих параллельно. План остаётся внутренним, сотрудник его не видит, если сам не попросит показать.
3. Напарник делегирует задачи функциональным агентам. Каждому уходит конкретная задача с параметрами, например период, регион, категория, набор гипотез. Агенты работают либо независимо и параллельно, либо последовательно, в зависимости от поставленного плана.
4. Напарник собирает результаты в единый ответ. Это синтез, с главным выводом, доказательной базой, отвергнутыми гипотезами и предлагаемым следующим шагом, а не простая склейка трёх отчётов через слово «также».
5. Сотрудник получает результат вместе с предложением действия. Если он валидирует вывод или поправляет его, Напарник запоминает поправку и в следующий раз учтёт её в похожей ситуации.
Сложные ситуации обычно требуют нескольких таких циклов. Менеджер может уточнить, Напарник в свою очередь дозапрашивает агентов и возвращает уточнённый разбор. Всё это происходит в одном диалоге в одном чате, без переключения интерфейсов.
Ещё одно важное свойство в том, что добавление нового функционального агента не увеличивает когнитивную нагрузку на сотрудника. Появился агент по эластичности цен, и у Напарника становится на одну возможность больше, а интерфейс остаётся прежним.
---
## Организационная память
Опыт сотрудника не должен исчезать вместе с его уходом из компании. И опыт сильного сотрудника не должен оставаться внутри одной головы, пока коллеги в соседнем отделе изобретают то же самое заново. Для этого нужна организационная память. Это многослойное хранилище контекста и опыта, к которому у Напарника есть доступ. Полное устройство памяти, состав слоёв, правила доступа и политики хранения описаны в [05-architecture, раздел «Память и контекст»](/05-architecture/#память-и-контекст).
С точки зрения сотрудника организационная память даёт два пользовательских эффекта.
Первый эффект состоит в преемственности. Когда сильный менеджер уходит, его личная память не передаётся новому сотруднику автоматически. Это было бы странно и небезопасно. Передаётся то, что уже стало паттерном, а именно проверенные подходы, типовые аргументы, разборы кейсов. Преемник получает их с первого дня и не восстанавливает по обрывкам файлов и устным рассказам. Механизм отбора и валидации паттернов лежит в [05-architecture, раздел «Коллективная память»](/05-architecture/#коллективная-память).
Второй эффект состоит в доступе к чужим удачным решениям внутри своей роли. Если в категории кондитерки кто-то нашёл рабочий аргумент против повышения закупочной цены, после валидации куратором этот аргумент становится доступен Напарникам остальных категорийных менеджеров. Сотруднику не нужно знать, как это технически устроено. Достаточно того, что Напарник учитывает удачные практики коллег при подготовке его собственных решений.
---
## Уровни зрелости ИИ-Напарника
Напарник не вводится одним релизом. Он растёт по уровням, и каждый следующий уровень опирается на зрелость предыдущего, на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности. Эту лестницу удобно использовать на пресейле, чтобы договориться с заказчиком об ожиданиях от пилота и обозначить, куда внедрение движется дальше.
| Уровень | Что Напарник делает | Что становится возможно |
|---|---|---|
| [1. Операционный помощник](#уровень-1-операционный-помощник) | Рутина по почте, календарю, голосу, транскриптам, поиску по корпоративным источникам. | Освобождается до 30–40% рабочего времени сотрудника от механической работы. |
| [2. Аналитический помощник](#уровень-2-аналитический-помощник) | Доступ к данным и BI, факторный анализ отклонений, нестандартные срезы через [Text2SQL](/03-agents/#5-text2sql), подготовка разборов и презентаций, проактивный мониторинг аномалий. | Время от вопроса до обоснованного ответа сжимается на порядок, а часть проблем ловится ещё до того, как менеджер открыл отчёт. |
| [3. Коммуникационный помощник](#уровень-3-коммуникационный-помощник) | Профили контактов, симулятор коммуникаций, подсказки на встречах в реальном времени (тот самый голосовой ассистент, [04-usecases](/04-usecases)), второе мнение перед решением. | P&L-эффект на переговорах и заметный рост качества внутренних коммуникаций. |
| [4. Мультиагентный координатор](#уровень-4-мультиагентный-координатор) | Общение Напарников между собой, горизонтальный обмен паттернами, вертикальная агрегация. | Корпоративная среда работает как сеть взаимодействующих агентов. Преемственность экспертизы. |
### Уровень 1. Операционный помощник
Базовый слой. Напарник снимает рутину, которая в крупной сети съедает значительную часть дня. Агент умеет сортировать входящую почту по срочности и теме, эскалировать критичные сигналы от поставщиков, подбирать время для встреч с учётом календарей и предпочтений сотрудника. Напарник расшифровывает голосовые сообщения менеджера в текст и превращает их в действия — письмо, задачу, поиск. Из транскриптов совещаний Напарник вытаскивает договорённости и дедлайны, а на вопросы вида *«где найти регламент Y»* или *«по какому шаблону подавать заявку X»* отвечает по корпоративным источникам.
Видимый эффект на этом уровне обычно появляется раньше всего, поэтому он хорошо подходит на первые недели пилота. Метрики тоже простые. Замеряем время на типовую операцию до и после, количество писем, обработанных без участия сотрудника, и долю встреч с автоматически сформированной повесткой.
### Уровень 2. Аналитический помощник
Напарник получает доступ к данным и начинает отвечать на содержательные вопросы по категории. Сотрудник спрашивает обычным языком, почему упала молочка в регионе, а в ответ приходит факторный разбор с главным выводом, доказательной базой и отвергнутыми гипотезами. Под капотом работают функциональные агенты, которые ходят в хранилище и BI, делают нестандартные срезы через Text2SQL, считают эффект промо и готовят черновики разборов и презентаций. Часть этой работы Напарник делает без запроса, потому что в фоновом режиме ловит аномалию раньше, чем она доходит до планёрки.
Эффект на этом уровне виден на скорости и качестве решений. Время от вопроса до обоснованного ответа падает с дней до минут, а у менеджера на руках сразу расширенная картина, а не та, до которой он успел докопаться руками. Здесь смотрят на время до первичного разбора, долю разборов, к которым менеджер вернулся за уточнениями, и оценку точности диагностик по 5-балльной шкале.
### Уровень 3. Коммуникационный помощник
Напарник начинает работать с людьми вокруг сотрудника. Он ведёт профили контактов в личной памяти, и в этих профилях лежат поставщики, коллеги из смежных подразделений и руководители. В профиле фиксируется стиль аргументации, чувствительные темы, прецеденты успеха и неудач, типичные триггеры уступок. Перед значимой коммуникацией Напарник работает как симулятор и предупреждает, например, что коммерческий директор спросит про каннибализацию, у тебя нет этого раздела.
Эффект на этом уровне уже прямой, P&L-метрики начинают двигаться. Лучше подготовленные переговоры дают доли процента бэк-маржи, и на масштабе крупной сети это десятки миллионов рублей в год. Здесь смотрят на долю встреч с подготовленным досье, эффект на маржу категорий и количество итераций при согласовании внутренних документов.
### Уровень 4. Мультиагентный координатор
Напарники разных сотрудников начинают разговаривать между собой по [управляемой политике межагентского взаимодействия](/05-architecture/#межнапарниковая-коммуникация-a2a). Например, менеджер просит своего Напарника собрать статусы по промо у коллег. Напарники коллег идут к своим сотрудникам, собирают данные, валидируют и возвращают ответ. Между подразделениями появляется аудируемый поток запросов, и он сам по себе становится данными о том, как работает организация.
На этом уровне начинает работать горизонтальный обмен паттернами. Удачный подход одного менеджера после валидации куратором становится доступен Напарникам всей команды. Так коллективная память переходит из описания в реальный рабочий механизм. Уровень 4 не включается рывком, он добавляется поверх первых трёх и требует отдельной проработки правил.
---
## Отличие ИИ-Напарника от функционального агента
Напарник и функциональный агент относятся к разным сущностям, и на словах их легко перепутать.
| Критерий | ИИ-Напарник | Функциональный агент |
|---|---|---|
| За кем закреплён | За конкретным сотрудником | За классом задач |
| Сколько в системе | По одному на сотрудника | Один общий, используется всеми Напарниками |
| Как вызывается | Сотрудник пишет в обычный мессенджер | Вызывается Напарником, не сотрудником |
| Что знает | Контекст и историю своего человека | Свою предметную область и инструменты |
| Что возвращает | Результат с рекомендацией следующего шага | Структурированный ответ по своей задаче |
| Доступ к данным | Через права своего сотрудника | По узкой инструментальной политике |
| Видим ли сотруднику | Да, постоянный собеседник | Обычно нет, работает «под капотом» |
В обычный рабочий день сотрудник может вообще ни разу не вызвать функционального агента напрямую. Все обращения идут через Напарника, и так получается удобнее. Но при необходимости менеджер может работать с конкретным функциональным агентом сам. Примеры функциональных агентов в [03-agents](/03-agents/#классификация-функциональных-агентов).
---
## Ограничения и границы ответственности
Напарник работает как компетентный партнёр, но самостоятельность у него ограничена. На критичных решениях он сотрудника не подменяет и в обход корпоративных правил не действует.
:::caution[Что Напарник не делает сам]
Сюда относятся внешние коммуникации от имени организации, изменения в учётных системах, инициирование платежей, договорные изменения, листинг и делистинг поставщиков, а также любые действия, которые сложно или невозможно откатить. Напарник всё это готовит, формулирует и рекомендует, но финальное действие подтверждает сотрудник.
:::
Границу автономии задаёт Tier-модель. Она разделяет действия по уровню эффекта и обратимости. Например, чтение данных и подготовка черновиков разрешены по умолчанию. А действия с внешним эффектом (отправка письма, изменение в учётной системе, бронирование встречи) требуют явного подтверждения сотрудника. Автономные действия по расписанию или триггеру включаются точечно по согласованным правилам, после периода доверия и согласования с ИБ. Конкретный состав уровней, классификация действий и механизм подтверждения описаны в [05-architecture, раздел «Tier-модель автономии»](/05-architecture/#tier-модель-автономии).
Помимо Tier-модели у Напарника есть несколько ограничений по содержанию работы.
С цифрами Напарник работает как передатчик, а не источник истины. Любая цифра, которую он показывает, ссылается на источник в корпоративном хранилище (таблицу, период, набор фильтров). Сотрудник может в один клик провалиться в источник и проверить.
В обход прав сотрудника Напарник тоже не работает. Если у менеджера нет доступа к данным соседнего подразделения, Напарник этих данных тоже не получит. Подробности лежат в [05-architecture, раздел «Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа).
---
## Метрики ценности ИИ-Напарника
Метрики удобно разносить на операционные, бизнес-метрики и пользовательские. Нужны все три. По одним бизнес-метрикам картина пилота выходит неполной, а на одних операционных не выйдет разговор с коммерческим директором.
| Уровень | Метрика | Как измеряется |
|---|---|---|
| Операционный | Время на типовой аналитический запрос | Замер до и после на одинаковом наборе вопросов |
| Операционный | Доля встреч с подготовленным досье | Отметка в календаре или подтверждение от менеджера |
| Операционный | Время от аномалии до алерта | Лог появления отклонения и времени уведомления |
| Бизнес | Эффект на маржу категории | Сравнение когорт менеджеров с Напарником и без |
| Бизнес | Дополнительная бэк-маржа в переговорах | Отдельная отметка по подготовленным переговорам |
| Бизнес | Время адаптации нового менеджера | До выхода на целевой KPI категории |
| Пользовательский | NPS менеджеров | Регулярный замер 1–2 раза в месяц |
| Пользовательский | Доля задач, в которых менеджер обращается к Напарнику | Лог обращений / общий объём типовых задач |
| Пользовательский | Качество диагностик | Оценка менеджера по 5-балльной шкале на каждом разборе |
:::note[Калибровка под заказчика]
Конкретный набор метрик и их пороги фиксируются на пресейле под конкретного заказчика. Универсального ROI у Напарника нет, он сильно зависит от того, какие сценарии входят в пилот, какая стартовая зрелость данных и какие процессы заказчик готов пересобрать.
:::
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Граница «персональный контекст vs функциональный агент»]
На словах разделение чёткое. Напарник помнит контекст сотрудника, а функциональный агент знает предметную область. На практике граница размывается. Профили контрагентов живут в личной памяти Напарника, но те же поставщики фигурируют и в данных, к которым ходят функциональные агенты. Где должна храниться истина по поставщику и кто её обновляет, пока решено не до конца.
:::
:::caution[Калибровка проактивности]
Между «дёргает по любому шороху» и «молчит, когда нужно было предупредить» лежит узкий коридор. Устоявшейся методики настройки порогов чувствительности под конкретного сотрудника у концепта нет, а неудачные начальные настройки по умолчанию способны оттолкнуть менеджера раньше, чем тот дойдёт до тонкой настройки. Кто и на каких данных подбирает первоначальные пороги, остаётся открытым вопросом.
:::
:::caution[Риск чрезмерного доверия]
Принцип «Напарник передатчик, а не источник истины» защищает от ошибок только если сотрудник реально проваливается в источник и перепроверяет цифры. На практике удобный и обычно правильный собеседник провоцирует обратное. Менеджер перестаёт перепроверять и принимает рекомендации на веру. Как удержать здоровый скепсис, не возвращая ручную работу, методологически не закрыто.
:::
:::caution[Управление скиллами и их конфликты]
Сотрудник сам добавляет и отключает индивидуальные скиллы, при этом поверх работают общие на компанию и встроенные. Когда индивидуальный скилл противоречит общему (например, *«не дёргай при отклонении меньше 5%»* против корпоративного порога эскалации), нужно правило разрешения конфликта и видимый сотруднику приоритет. Единого механизма пока нет.
:::
---
# Функциональные агенты
> Каталог функциональных агентов платформы. Что это такое, как они отличаются от ИИ-Напарника, по каким принципам проектируются, какие классы существуют и какие пять агентов имеет смысл собрать в первую очередь под пилот.
Источник: https://ai-partner-ru.chvanov.com/raw/03-agents.mdx
Функциональные агенты это специализированные ИИ-исполнители: они решают узкие классы задач и работают под координацией ИИ-Напарника. Здесь сведены принципы проектирования, классификация, шаблон карточки и подробный разбор пяти агентов, с которых имеет смысл начинать пилот.
## Из этого раздела вы узнаете
- что такое функциональный агент и какие три свойства отличают его от прочих сущностей платформы
- чем функциональный агент отличается от ИИ-Напарника и где проходит граница между ними
- как устроена классификация каталога на бизнес-функциональные и сервисные агенты
- какие пять агентов имеет смысл собрать первыми под MVP и пилот
- по каким принципам проектируется любой новый агент и из чего состоит шаблон его карточки
---
## Коротко
Функциональный агент это узкоспециализированный ИИ-исполнитель для одного класса задач. Это может быть например анализ продаж, поиск по регламентам, подготовка досье поставщика или мониторинг аномалий. Каждую такую работу закрывает отдельный агент: у него собственные инструменты и память, а правила и права доступа настроены под его узкую специализацию.
Сотрудник обычно этих агентов не видит. Запросы к ним отправляет ИИ-Напарник, он же собирает результаты в один ответ и приносит сотруднику. Так выглядит правильное разделение ответственности. Напарник имеет доступ к контексту сотрудника и [оркестрирует](/05-architecture/#оркестрация-задач) работу, а функциональный агент качественно и предсказуемо закрывает свою предметную область.
В этом документе мы не описываем весь возможный каталог функциональных агентов. Для начала рассмотрим [пять агентов](#карточки-приоритетных-агентов), которые ложатся в понятные бизнес-сценарии и на наш взгляд быстрее всего показывают ценность платформы. [Остальных агентов](/03-agents/#развитие-каталога-агентов) обозначим одним абзацем, и они появятся (или будут заменены другими) по мере роста зрелости внедрения.
:::tip[Главный тезис документа]
Функциональный агент это узкоспециализированный исполнитель для одного класса задач, который сотрудник напрямую не видит. Запросы к нему отправляет и собирает результаты [**ИИ-Напарник**](/02-partner/), а каталог таких агентов можно расширять без роста когнитивной нагрузки на человека.
:::
---
## Что такое функциональный агент
У функционального агента три отличительных свойства, и важны они все вместе.
Во-первых, у него один класс задач. Например, один агент разбирает отклонения в продажах, другой готовит досье на поставщика, третий следит за аномалиями. Размывать специализацию плохая идея, потому что универсальный агент тяжелее настраивать, его сложнее аудировать и сложнее улучшать по обратной связи. Лучше иметь пять агентов с понятными границами, чем один, который умеет всё подряд.
Во-вторых, у него узкая [инструментальная политика](/05-architecture/#инструментальные-политики). Функциональный агент видит только те данные и инструменты, которые ему нужны для его специализации. Например, у Text2SQL агента есть доступ (только на чтение) к корпоративному хранилищу и больше ничего. А агенту аномалий разрешено читать данные и отправлять сигнал Напарнику, но он не пишет в системы и не имеет доступ к веб-поиску.
В-третьих, функциональный агент стоит на одну роль выше слоя данных и на одну ниже Напарника. К нему как правило обращается не сотрудник напрямую, а Напарник от имени сотрудника. У функционального агента основная ответственность — качество исполнения предметной задачи, а не работа с контекстом конкретного человека. Контекст сотрудника находится на уровне Напарника.
:::tip[Один агент, один класс задач]
Практический признак для проверки. Если внутри одного агента появляются сразу две функции, которые требуют разных инструментов или разных прав, его пора делить. На старте такой дисциплины придерживаться сложно, но на среднем и длинном горизонте она окупается.
:::
---
## Роль функциональных агентов в платформе
Функциональные агенты дают платформе предметную глубину. Напарник без них умеет вести диалог, удерживать контекст пользователя и принимать решения о маршрутизации, но сам по себе не сделает качественный факторный анализ и не напишет SQL. Умение качественно решать такие задачи приходит через подключение нового функционального агента.
С точки зрения внедрения это достаточно удобно. Каталог функциональных агентов может расти постепенно. Сначала закрывают самые болезненные сценарии. На пилоте, например, это может быть разбор отклонений продаж и подготовка к переговорам. Остальное добавляется по мере того, как заказчик видит ценность и подтягиваются интеграции с источниками данных. Каждый новый агент работает как отдельная единица поставки с понятными границами, понятными тестами и измеримым эффектом.
Заметим, что каталог функциональных агентов можно расширять без увеличения когнитивной нагрузки на сотрудника. В мессенджере он по-прежнему пишет своему Напарнику тем же языком, что и вчера, просто Напарник теперь умеет ещё одну вещь. Это и даёт [четвёртой эпохе](/01-vision/#эпоха-4-ии-напарник-и-мультиагентная-среда) главное преимущество перед [третьей](/01-vision/#эпоха-3-функциональные-ии-агенты). В третьей эпохе каждый новый агент подключается к менеджеру напрямую и означает ещё одну вкладку, приложение или отчёт, которые нужно держать в голове. В четвёртой все они стоят за Напарником, и рост каталога сотруднику не виден.
---
## Отличие функционального агента от ИИ-Напарника
На словах эти сущности легко путаются. Различить их помогает простой тест границы:
- Если у сущности есть личный контекст конкретного сотрудника (его приоритеты и история решений), и она закреплена за человеком, то это часть Напарника.
- Если у сущности есть узкая инструментальная политика и она работает «под капотом», то это функциональный агент.
Когда границы соблюдаются, платформу проще аудировать и развивать.
Таблица отличий по семи критериям (за кем закреплён, кто вызывает, что знает, что возвращает, какой доступ к данным) лежит в [02-partner, раздел «Отличие ИИ-Напарника от функционального агента»](/02-partner/#отличие-ии-напарника-от-функционального-агента).
---
## Классификация функциональных агентов
Каталог функциональных агентов удобно разнести по двум большим группам. Это не строгая таксономия для технической документации, а скорее способ быстро ориентироваться при разговоре с заказчиком. Сразу видно, создаёт ли агент прямую бизнес-ценность или обслуживает работу остальных.
Граница между группами проходит по тому, закрывает ли агент самостоятельный бизнес-сценарий. Бизнес-функциональные агенты привязаны к конкретной предметной задаче коммерции, операций или работы с клиентами, и их эффект виден в P&L. Сервисные агенты живут в более технической и обслуживающей плоскости. Сами по себе они редко закрывают сценарий целиком, чаще их вызывает Напарник или другой агент как инструмент, но без них остальные агенты в некоторых случаях не смогут решить свою задачу.
### Бизнес-функциональные агенты
Эти агенты привязаны к конкретной бизнес-задаче, и их эффект виден в P&L. Внутри группы удобно различать три направления. Коммерция — повседневная работа категорийного менеджера и коммерческого блока: анализ продаж и маржи, разбор промо, подготовка к переговорам, ассортиментные решения, ценообразование (здесь больше всего агентов, P&L-эффект виден быстрее всего, и в пилоте область обычно берут первой). Операции — работа с поставками, остатками и доступностью товара: OOS, недопоставки, альтернативные маршруты при сбоях, оборачиваемость, списания (часто появляются на втором шаге пилота). Клиенты — сегментация, поведенческие паттерны, отклик на промо и удержание (полезны там, где у сети есть программа лояльности и сильная аналитика клиентского поведения).
### Сервисные агенты
Эти агенты живут в технической и обслуживающей плоскости. Сами по себе они редко закрывают бизнес-сценарий целиком, чаще их вызывает Напарник или другой агент как инструмент. Сервисные агенты удобно разнести по трём направлениям. Технические — слой, на котором держится почти всё остальное: Text2SQL, факторный анализ, прогнозирование, обнаружение аномалий, проверки качества данных. Коммуникационные отвечают за встречи и тексты: запись и краткий пересказ расшифровок встреч, follow-up, профили контактов, помощь с письмами и презентациями, поддержку в реальном времени во время переговоров. Сотрудников на пилоте такие агенты часто радуют сильнее всего, потому что экономия времени видна почти сразу. Организационные накапливают и переиспользуют опыт команды: коллективная память, поиск по регламентам, поддержка адаптации нового сотрудника, управление прецедентами. Их обычно подключают на втором-третьем этапе, когда у платформы уже есть данные о реальной работе менеджеров.
---
## Принципы проектирования агентов
Эти принципы прошиты в архитектуру, и им следует каждый новый функциональный агент.
Один агент закрывает один класс задач. У каждого агента есть короткое назначение в одну строку. Если объяснить его сложно, скорее всего, агент собран неправильно и его пора разделить.
Агент получает только те инструменты, которые ему нужны для работы. По умолчанию права только на чтение. Право на запись, отправку и обращения к другим агентам агент получает отдельно, под явное разрешение.
Любая цифра, которую возвращает агент, опирается на конкретный источник. Это может быть таблица в хранилище с периодом и набором фильтров или страница регламента. Сотрудник может в один клик провалиться и проверить.
У каждого агента есть свой формат вывода. Например, для аналитического агента это может быть диагностическая карточка с главным выводом, доказательной базой, отвергнутыми гипотезами и следующим шагом. Это нужно, чтобы Напарник смог качественно собирать ответы разных агентов в один результат для сотрудника.
Агент умеет принимать поправки от сотрудника. Реплика *«это был не OOS, а списание по сроку годности»* сохраняется как сигнал и учитывается в следующих похожих разборах. Без этой петли агент быстро упирается в потолок качества.
Несколько Напарников вызывают один и тот же агент параллельно, и контексты их вызовов не пересекаются. Технически изоляцию обеспечивает уровень сессий, это описано в [05-architecture, раздел «Модель взаимодействия агентов»](/05-architecture/#модель-взаимодействия-агентов).
Агенты не разговаривают с внешним миром от имени сотрудника. Внешние коммуникации, изменения в учётных системах, листинг и делистинг проходят через Напарника и через явное подтверждение человека. Эта граница описывается через Tier-модель автономии и подробно разбирается в [05-architecture, раздел «Tier-модель автономии»](/05-architecture/#tier-модель-автономии). В шаблоне карточки агента Tier фиксируется в пункте «Доступные действия и Tier автономии».
Удачные паттерны работы агента может быть полезно отчуждать в [скиллы](/05-architecture/#скиллы). Когда у конкретного агента закрепляется хорошо работающий подход (например, формат диагностической карточки факторного анализа или способ считать каннибализацию промо), его описывают как платформенный скилл и делают доступным всему каталогу. Это часть жизненного цикла агента и один из главных механизмов накопления коллективной экспертизы.
:::caution[Защита от prompt injection]
Внешние данные, которые попадают функциональному агенту на вход (например, письма поставщиков, ответы на запросы, содержимое веб-страниц), платформа оборачивает в служебные теги и помечает как недоверенные. Агент может их анализировать, но не может выполнять инструкции из их содержимого. Это особенно важно для агентов, работающих с почтой и внешним вебом. Любое действие с внешним эффектом, которое следует из такого содержимого, всё равно проходит через Напарника и Tier 2, то есть требует явного подтверждения сотрудника. Подробности лежат в [05-architecture, раздел «Защита от prompt injection»](/05-architecture/#защита-от-prompt-injection).
:::
---
## Когда агент, а когда скилл Напарника
Каталог выше неявно предполагает, что каждый бизнес-сценарий это отдельный функциональный агент. На практике это не всегда так. Часть сущностей, которые удобно называть «агентами», на деле не имеют собственного цикла рассуждений, собственных инструментов и собственной памяти. Они лишь маршрутизируют запрос к сервисным агентам (Text2SQL, база знаний, финансовый эффект) и склеивают ответы в нужный формат. С такой работой Напарник справляется сам, и тогда сущность правильнее оформить не как агента, а как [скилл Напарника](/05-architecture/#скиллы), то есть структурированную инструкцию в его промпте.
В разделе [«Принципы проектирования агентов»](#принципы-проектирования-агентов) описано прямое направление, когда удачный паттерн работы агента отчуждается в скилл. Бывает и обратное направление: сущность, которую интуитивно хочется назвать агентом, на старте может быть всего лишь скиллом и дорастать до полноценного агента по мере накопления собственной экспертизы.
Функциональный агент оправдан как отдельная сущность, а не скилл, когда у него есть хотя бы три из пяти свойств.
| Свойство | Что это значит |
|----------|----------------|
| **Собственный цикл рассуждений** | Агент перебирает гипотезы, итерирует, принимает промежуточные решения, а не выполняет линейный рецепт «вызови A, вызови B, склей». |
| **Собственные инструменты** | У агента есть инструменты, которых нет у Напарника, например SQL-доступ к хранилищу, RAG-поиск по документам или вызов ML-модели. |
| **Собственная память** | Агент накапливает доменные прецеденты, паттерны и метрики качества своей работы. |
| **Изолированная политика прав** | Агенту нужен доступ к данным, который по принципу минимальных прав не должен быть у Напарника. |
| **Переиспользование** | Одного и того же агента вызывают Напарники разных сотрудников. |
Если свойств нет совсем или есть только переиспользование, это скилл Напарника. Граница подвижна, и сущность может начинать жизнь как скилл и дорастать до агента ровно так же, как удачный паттерн агента может, наоборот, отчуждаться в общий скилл.
---
## Шаблон карточки агента
У всех функциональных агентов в каталоге один и тот же шаблон. Это нужно, чтобы карточки были сравнимы между собой и чтобы при внедрении не приходилось каждый раз изобретать структуру с нуля.
1. **Назначение.** Одна-две строки про то, какой класс задач закрывает агент. Если объяснить сложно, стоит вернуться к [принципам проектирования](/03-agents/#принципы-проектирования-агентов).
2. **Пользователи.** Кто из сотрудников будет ожидаемым или самым частым пользователем агента. Как правило, это не Напарник, а человек за ним. Например, категорийный менеджер коммерческой дирекции, логист направления, руководитель промо.
3. **Типовые вопросы.** Список реальных формулировок, с которыми сотрудник приходит к Напарнику и которые в итоге попадают этому агенту. Это нужно для отладки настройки агента.
4. **Используемые данные.** Источники, к которым агент обращается. Желательно с пометкой режима, например read-only, read+draft, read+write.
5. **Доступные действия и Tier автономии.** Что агент умеет делать и в каком [уровне автономии](/05-architecture/#tier-модель-автономии) каждое из этих действий выполняется. По умолчанию большинство функциональных агентов работают на Tier 1 (чтение, расчёты, подготовка артефактов внутри платформы). Действия с внешним эффектом (отправка письма, запись в учётную систему, бронирование встречи с внешним участником) идут под Tier 2 и требуют явного подтверждения сотрудника. Tier 3 (автономные действия по правилам) включается точечно по согласованным сценариям.
6. **Взаимодействие с другими агентами.** Кого вызывает или с кем работает в паре. Например, агент переговоров подтягивает Text2SQL для индексов цен и агент базы знаний для поиска прецедентов.
7. **Бизнес-эффект.** Какой эффект ожидается на цифрах. Достаточно одного-двух осмысленных тезисов.
8. **Метрики эффективности.** Как мы поймём, что агент работает. Например, время до ответа, точность диагностик, доля сценариев с использованием.
---
## Приоритетные агенты для MVP и пилота
Для первой версии концепта мы рекомендуем стартовый набор из пяти функциональных агентов плюс несколько скиллов Напарника. Состав отражает простой принцип, разобранный в разделе [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника). То, у чего есть собственный инструмент или тяжёлый фоновый цикл, выносится в отдельного агента, а сценарии, которые сводятся к [оркестрации](/05-architecture/#оркестрация-задач) сервисных агентов, остаются скиллами Напарника. Эти агенты закрывают самые понятные коммерческие сценарии, ложатся в одну архитектурную картинку и не требуют интеграций, которые невозможно собрать за разумное время.
Пост-анализ эффективности промо-акций, каннибализация, влияние на маржу. Помогает разбираться, почему одна акция сработала, а соседняя нет. Вынесен в отдельного бизнес-агента из-за тяжёлой аналитики. Подробная карточка лежит в разделе [«Агент промо»](/03-agents/#1-агент-промо).
Фоновый поиск аномалий и алгоритмический top-down разбор причин падения продаж по множеству срезов (группа, категория, бренд × сеть, регион, магазин). Выявляет проблему раньше, чем она доходит до отчёта. Подробная карточка лежит в разделе [«Агент мониторинга и аномалий»](/03-agents/#2-агент-мониторинга-и-аномалий).
Оценивает влияние решений на маржу, выручку, оборачиваемость и списания. Работает как кросс-функциональный калькулятор последствий, к которому обращаются почти все остальные агенты. Подробная карточка лежит в разделе [«Агент финансового эффекта»](/03-agents/#3-агент-финансового-эффекта).
Поиск по корпоративной базе знаний, куда входят регламенты, стандарты, прецеденты и переговорные практики. Отвечает «как мы делали это раньше» и дописывает новые прецеденты обратно в корпус. Подробная карточка лежит в разделе [«Агент базы знаний и регламентов»](/03-agents/#4-агент-базы-знаний-и-регламентов).
Переводит вопросы на естественном языке в SQL к корпоративному хранилищу и отдаёт срез данных. Базовый поставщик цифр, на котором держится работа остальных агентов. Подробная карточка лежит в разделе [«Text2SQL»](/03-agents/#5-text2sql).
Отдельных агентов под подготовку к переговорам, сравнение поставщиков, ведение досье контактов и обвязку встреч в стартовом наборе нет. Эти сценарии Напарник закрывает своими скиллами, опираясь на пятёрку агентов выше. Скилл переговоров собирает досье из Text2SQL, базы знаний и финансового эффекта, скилл встреч ищет свободный слот и работает с почтой и календарём. Подробнее о том, почему они оформлены как скиллы, в разделе [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника), а механизм скиллов разобран в [05-architecture, раздел «Скиллы»](/05-architecture/#скиллы). Полноценный [агент OOS](/03-agents/#7-агент-oos-и-запасов) и [агент встреч](/03-agents/#8-агент-встреч-и-follow-up) с расшифровками и таск-трекером отнесены в [развитие каталога](#развитие-каталога-агентов) и подключаются на следующих шагах.
:::note[Это стартовая гипотеза]
Под конкретного заказчика стартовый набор может смещаться. Если у сети нет отдельной системы ведения промо, то агент промо может уехать в бэклог, а вместо него поднимается, например, агент ценообразования и конкурентного мониторинга. Важно сохранить саму логику. Несколько сервисных агентов как фундамент (данные, финансовая модель, знания), два-три бизнес-агента на самых болезненных сценариях, а остальное закрывают скиллы Напарника поверх этого фундамента.
:::
---
## Карточки приоритетных агентов
### 1. Агент промо
**На старте.** В стартовой сборке вынесен в отдельный бизнес-агент. У него собственные расчётные скрипты разбора эффективности акций (uplift, ROI, каннибализация) и прямой доступ к данным, поэтому изоляция тяжёлой аналитики в отдельного исполнителя оправдана. По формальным критериям он пограничен, и точечный факторный разбор по конкретному срезу («почему упало вот это») остаётся скиллом Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Разбирает эффективность промо-акций. Что окупилось, что нет, где была каннибализация, где промо просто перенесло продажи во времени без прироста.
2. **Пользователи.** Категорийный менеджер, руководитель промо, коммерческий директор.
3. **Типовые вопросы.** *«Почему акция на молочку не дала ожидаемого роста?»*, *«Сравни эффективность февральских акций по кондитерке»*, *«Где в апреле была каннибализация между промо?»*, *«Готовь разбор летней промо-кампании к комитету»*.
4. **Используемые данные.** Из корпоративного хранилища приходят продажи, маржа, остатки, цены до и после. Из систем промо-планирования берутся параметры акции и планы. Данные о конкурентах подтягиваются из внешних источников, если подключены.
5. **Доступные действия и Tier автономии.** Всё, что делает агент промо, работает на [Tier 1](/05-architecture/#tier-модель-автономии). Это чтение данных, факторный анализ отклонений, оценка чистого эффекта промо, проверка гипотез о каннибализации, формирование диагностической карточки. Любые внешние действия по итогам разбора (например, отправка письма поставщику или изменение параметров будущей акции в системе планирования) проходят через Напарника и подтверждение менеджера, то есть уходят на [Tier 2](/05-architecture/#tier-модель-автономии).
6. **Взаимодействие с другими агентами.** Внутри обычно работает связкой с [агентом финансового эффекта](/03-agents/#3-агент-финансового-эффекта) (тот считает влияние на маржу) и [Text2SQL](/03-agents/#5-text2sql) (вытаскивает нужные срезы). По запросу подтягивает [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов), например, чтобы найти прецеденты похожих акций.
7. **Бизнес-эффект.** Меньше промо, которые повторяются «по инерции». Раньше виден провал плохой акции, и есть шанс закрыть её или переформатировать на ходу. На горизонте квартала ожидается снижение доли неэффективных промо.
8. **Метрики эффективности.** Доля неэффективных промо на горизонте квартала. Точность оценки чистого эффекта промо по факту. Доля промо-разборов, по итогам которых принято решение (закрыть, переформатировать, повторить).
---
### 2. Агент мониторинга и аномалий
**На старте.** Полноценный агент. Несёт собственный фоновый цикл поиска аномалий и алгоритмический top-down разбор причин по множеству срезов, поэтому вопрос «агент или скилл» для него не стоит ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Находит и объясняет аномальные отклонения KPI, прежде всего падение продаж, раньше, чем они доходят до отчёта. Алгоритмически сканирует продажи по множеству срезов (группа, категория, бренд в разрезе всей сети, региона и магазина), выделяет проблемные зоны и разбирает причину каждой через drill-down.
2. **Пользователи.** Категорийный менеджер, руководитель категории, коммерческий директор.
3. **Типовые вопросы.** *«Найди аномалии в продажах за апрель»*, *«Где у нас проседает по категориям и регионам?»*, *«Почему не выполнен план продаж по моей категории?»*, *«Просканируй категории на проблемные зоны»*.
4. **Используемые данные.** Основной источник это корпоративное хранилище, откуда приходят продажи, план, остатки и цены, всё только на чтение. Для нестандартных и уточняющих срезов опирается на [Text2SQL](/03-agents/#5-text2sql).
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент сканирует данные, ищет аномалии, выполняет top-down разбор причин, формирует диагностические карточки и сводную панель, отвечает на уточняющие вопросы и отправляет сигнал Напарнику. Любое внешнее действие по итогам разбора (письмо поставщику, изменение заказа) проходит через Напарника и [Tier 2](/05-architecture/#tier-модель-автономии).
6. **Взаимодействие с другими агентами.** Отдаёт находки Напарнику. Подтягивает [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки масштаба потерь и [Text2SQL](/03-agents/#5-text2sql) для нестандартных срезов. Работает в паре с [агентом промо](/03-agents/#1-агент-промо), когда аномалия связана с акцией.
7. **Бизнес-эффект.** Проблемы в категории видны практически сразу. Меньше «слепых зон», системные сбои всплывают раньше и с готовой фактурой для разбора.
8. **Метрики эффективности.** Время от появления аномалии до сигнала. Доля аномалий с объяснённой причиной. Доля ложных срабатываний.
---
### 3. Агент финансового эффекта
**На старте.** Полноценный сервисный агент. Имеет собственный инструментарий сценарного моделирования, поэтому вопрос «агент или скилл» для него не стоит ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Считает последствия коммерческих решений. Трансформирует гипотезы на человеческом языке в количественные метрики (цифры например по марже, выручке, оборачиваемости и списаниям).
2. **Пользователи.** Любой сотрудник, принимающий коммерческое решение. Это категорийный менеджер, прайс-менеджер, руководитель промо, директор по категориям.
3. **Типовые вопросы.** *«Что будет с маржой категории, если согласимся на +5% закупочной цены от Danone?»*, *«Сравни два варианта матрицы по эффекту на оборачиваемость»*, *«Если уберём этот SKU, что произойдёт за квартал?»*, *«Посчитай эффект промо на маржу с учётом каннибализации»*.
4. **Используемые данные.** Из хранилища берутся продажи, закупочные цены и цены продажи, маржа, остатки, списания. Финансовые модели и нормативы включают собственные нормы списаний и целевые показатели по марже. Параметры промо подтягиваются для расчёта чистого эффекта.
5. **Доступные действия и Tier автономии.** Агент финансового эффекта полностью живёт на [Tier 1](/05-architecture/#tier-модель-автономии). Это сценарное моделирование, расчёт чистого эффекта решений, сравнение вариантов, формирование короткого финансового резюме для разговора с руководителем. Никаких внешних действий он не делает по построению.
6. **Взаимодействие с другими агентами.** Этого функционального агента вызывают [агент промо](/03-agents/#1-агент-промо) (эффект акции), [агент мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) (масштаб потерь), [агент переговоров](/03-agents/#6-агент-переговоров-и-поставщика) (последствия уступок), [агент OOS](/03-agents/#7-агент-oos-и-запасов) (стоимость потери), а также [агент ассортимента](/03-agents/#9-агент-ассортимента) (последствия делистинга), когда он подключён. В общем, практически все функциональные агенты так или иначе с ним взаимодействуют.
7. **Бизнес-эффект.** Управленческие решения принимаются с подкреплённой цифровой фактурой.
8. **Метрики эффективности.** Доля значимых решений с предварительной оценкой эффекта. Точность прогноза по факту через квартал. Оценка качества разбора менеджером.
---
### 4. Агент базы знаний и регламентов
**На старте.** Полноценный сервисный агент. RAG-индекс и семантический поиск по корпусу работают как собственный инструмент, которого нет у Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Поиск по корпоративной базе знаний. Сюда входят регламенты, стандарты, прецеденты, переговорные практики и аналитические отчёты. Умеет дописывать новые прецеденты обратно в корпус.
2. **Пользователи.** Любой сотрудник, но чаще агента вызывает не человек напрямую, а Напарник и другие агенты (переговоры, промо), когда нужны прецеденты или регламент.
3. **Типовые вопросы.** *«По какому шаблону подаётся заявка?»*, *«Какие сроки согласования промо?»*, *«Что у нас по делистингу мелких поставщиков?»*, *«Как мы раньше решали похожий спор с поставщиком?»*.
4. **Используемые данные.** Корпоративный корпус регламентов, прецедентов и переговорных практик. Режим read + write-back. Агент читает корпус и дописывает в него новые прецеденты по итогам разборов.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент ищет по корпусу, цитирует с обязательной ссылкой на источник, формирует краткую выжимку и дописывает новый прецедент. Запись идёт во внутренний корпус платформы, поэтому остаётся в пределах Tier 1, в отличие от внешних действий.
6. **Взаимодействие с другими агентами.** Вызывается [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика) (прецеденты и регламенты), [агентом промо](/03-agents/#1-агент-промо) (похожие акции) и Напарником напрямую. Технически роль может расщепляться на агент регламентов и агент прецедентов, если они живут в разных системах (см. [открытые вопросы](#открытые-вопросы)).
7. **Бизнес-эффект.** Знания перестают жить «в головах» двух-трёх человек. Прецеденты и регламенты переиспользуются, адаптация нового сотрудника ускоряется.
8. **Метрики эффективности.** Доля ответов с корректной ссылкой на источник. Покрытие корпуса. Частота переиспользования прецедентов в реальных сценариях.
---
### 5. Text2SQL
**На старте.** Полноценный сервисный агент и фундамент всего набора. Собственный инструмент это SQL-доступ к хранилищу, которого по принципу минимальных прав нет у Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Переводит вопросы на естественном языке в SQL к корпоративному хранилищу и возвращает срез данных. Базовый источник цифр, на который опираются остальные агенты.
2. **Пользователи.** Напрямую человеком почти не вызывается. Его вызывают Напарник и другие агенты, когда нужен нестандартный срез, которого нет в готовых витринах.
3. **Типовые вопросы.** Приходят в основном от других агентов. Например, *«продажи и маржа по молочке за март в разрезе регионов»*, *«доля SKU поставщика в категории»*, *«остатки на РЦ по списку SKU»*.
4. **Используемые данные.** Корпоративное хранилище (DWH, реляционная база) строго в режиме read-only. Доступ ограничен по принципу минимальных прав, без права записи.
5. **Доступные действия и Tier автономии.** Только [Tier 1](/05-architecture/#tier-модель-автономии): строит и выполняет читающие запросы, формирует выборки. Никаких записей и внешних действий по построению.
6. **Взаимодействие с другими агентами.** Вызывается практически всеми, а именно [агентом промо](/03-agents/#1-агент-промо), [агентом мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий), [агентом финансового эффекта](/03-agents/#3-агент-финансового-эффекта) и [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика). Сам никого не инициирует, работает как инструмент.
7. **Бизнес-эффект.** Данные хранилища становятся доступны на естественном языке, без знания SQL и без аналитика-посредника между вопросом и цифрой.
8. **Метрики эффективности.** Доля корректных и исполнимых запросов. Время до ответа. Доля вопросов, закрытых без ручной доработки SQL.
---
## Развитие каталога агентов
После пяти приоритетных идёт развитие каталога. Первыми на очереди три сценария, которые в стартовой сборке закрыты скиллами Напарника или отложены, но имеют проработанные карточки, потому что входят в ближайший контур развития. Дальше идёт длинный хвост, по абзацу на агента, чтобы заказчик и команда внедрения видели, куда платформа может расти.
### 6. Агент переговоров и поставщика
**На старте.** Реализован как скилл Напарника, а не как отдельный агент. Собирает досье из сервисных агентов по устойчивому рецепту, собственного цикла рассуждений пока нет. До агента дорастает по мере накопления переговорной памяти и паттернов ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Готовит досье на поставщика и аргументацию к встрече. Подсвечивает сильные и слабые позиции и собирает прецеденты и цифры, которые должны лежать перед менеджером во время разговора.
2. **Пользователи.** Категорийный менеджер, руководитель направления, директор по закупкам.
3. **Типовые вопросы.** *«Поставщик X просит +5% к закупочной цене, встреча завтра»*, *«Подготовь досье на Saverio к четвергу»*, *«Что у нас в прецедентах по делистингу мелких поставщиков»*, *«Что предъявить Danone по SLA за квартал»*.
4. **Используемые данные.** Из корпоративного хранилища берутся закупки, продажи, маржа, доля в категории. Информация о SLA включает фактический fill rate, недопоставки, штрафы. Дополняют картину внешние индексы цен на сырьё и упаковку, а также корпоративная база знаний со стандартами переговоров, прецедентами прошлых уступок и историей переписки с поставщиком.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент собирает досье, рассчитывает основные индикаторы поставщика, ищет прецеденты, формирует аргументационный пакет и готовит слайды по корпоративному шаблону. Всё это остаётся внутри платформы. Любая внешняя коммуникация с поставщиком (письмо, запрос на пересмотр условий, инициирование штрафной процедуры) идёт через Напарника и [Tier 2](/05-architecture/#tier-модель-автономии), то есть подтверждается менеджером явно.
6. **Взаимодействие с другими агентами.** Вызывает Text2SQL для коммерческих срезов, [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки последствий уступок, [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов) для прецедентов и регламентов. Часто работает в паре с [агентом OOS](/03-agents/#7-агент-oos-и-запасов), если претензия касается поставок.
7. **Бизнес-эффект.** Доля встреч с подготовленным досье растёт с типичных 20% до подавляющего большинства. На переговорной марже это даёт прямой P&L-эффект, на масштабе крупной сети речь идёт о десятках миллионов рублей в год.
8. **Метрики эффективности.** Доля переговоров с готовым досье. Оценка качества досье менеджером после встречи. Эффект на бэк и фронт маржу в когорте подготовленных встреч против неподготовленных.
---
### 7. Агент OOS и запасов
**На старте.** Пограничный случай. В проактивном причинно-следственном режиме это полноценный агент, в реактивном «ответь по запросу» скорее скилл Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Отслеживает доступность товара, разбирает причины out-of-stock и предлагает действия. Агент работает преимущественно в фоне и инициативно сигналит, когда видит проблему. Но может работать и по запросу.
2. **Пользователи.** Категорийный менеджер, логист направления, операционный руководитель кластера.
3. **Типовые вопросы.** *«Почему по этим SKU третий день нулевой остаток?»*, *«Какие SKU сейчас под угрозой OOS на следующей неделе?»*, *«Разбери, что произошло с поставками молочки за март»*, *«Где у нас регулярные сбои по моей категории на конкретных РЦ»*.
4. **Используемые данные.** Основной источник данных это корпоративное хранилище. Оттуда приходят остатки на РЦ и в магазинах, продажи, прогноз спроса, поставки, графики и фактические даты прихода (обычно эти данные WMS регулярно выгружает в DWH). SLA-данные поставщиков включают fill rate, отказы, замены. Календарь промо нужен, чтобы понимать ожидаемый всплеск спроса. Прямое подключение к WMS возможно как исключение для сценариев, где нужна оперативность, которой суточная выгрузка не обеспечивает.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент считает текущий и прогнозный OOS, разбирает причины (недопоставка, недостаточный заказ, ошибка прогноза, всплеск спроса), формирует рекомендации (переключение на альтернативный РЦ, экстренный заказ, временная замена SKU) и отправляет алерт Напарнику. Само исполнение рекомендации (размещение заказа, изменение графика поставок) подтверждается менеджером или логистом и проходит под [Tier 2](/05-architecture/#tier-модель-автономии). Стандартное переключение между РЦ при OOS ниже согласованного порога может быть точечно вынесено в [Tier 3](/05-architecture/#tier-модель-автономии), но только по отдельно согласованному сценарию.
6. **Взаимодействие с другими агентами.** Работает в паре с [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика), когда речь идёт о систематических сбоях у поставщика. Подтягивает [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки потерянной выручки. Использует Text2SQL для нестандартных срезов.
7. **Бизнес-эффект.** Время от появления проблемы до её обнаружения сокращается с часов и дней до минут. Системные проблемы у конкретных поставщиков становятся видны раньше, и появляется фактура для разговора с ними. На полке становится меньше пустых мест, и выручка категории растёт.
8. **Метрики эффективности.** Время от события OOS до алерта. Доля OOS-инцидентов с предложенным решением до принятия менеджером. Динамика fill rate по проблемным поставщикам.
---
### 8. Агент встреч и follow-up
**На старте.** Полноценным агентом в стартовый набор не входит. Его обвязку (поиск свободного слота, создание встречи, работа с почтой и календарём) на старте закрывают скиллы Напарника. Отдельным агентом с расшифровками встреч, памятью по участникам и таск-трекером он становится на следующем шаге, когда выполняются все пять критериев ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Этот агент делает работу со встречами более осмысленной. Логистику (поиск свободного слота, создание встречи, приглашения) он оставляет календарному скиллу Напарника, а сам отвечает за содержание. До встречи готовит участникам короткий бриф, во время встречи фиксирует договорённости, после превращает их в задачи, рассылает Напарникам участников и (опционально) сам контролирует исполнение. Ищет по расшифровкам всех встреч.
2. **Пользователи.** Любой сотрудник, у которого встречи занимают значимую часть дня. Это категорийный менеджер, руководитель направления, директор.
3. **Типовые вопросы.** *«Что было на встрече с поставщиком в прошлый четверг?»*, *«Кто что обещал сделать к среде по итогам комитета»*, *«Напомни, на чём мы остановились с Ивановым по промо»*.
4. **Используемые данные.** Расшифровки встреч, корпоративный мессенджер для напоминаний и сбора статусов, таск-трекер для постановки задач. Доступ к календарю сотрудника и его коллег идёт через календарный скилл Напарника.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент формирует повестку, расшифровывает встречу, выделяет договорённости и дедлайны, готовит черновики follow-up. Бронирование встречи с внешним участником, постановка задачи коллеге в таск-трекере и отправка приглашений идут под [Tier 2](/05-architecture/#tier-модель-автономии) и проходят через подтверждение сотрудника (само бронирование и приглашения выполняет календарный скилл Напарника). В [Tier 3](/05-architecture/#tier-модель-автономии) могут быть вынесены рутинные напоминания об уже поставленных задачах и стандартные эскалации при пропуске согласованных сроков. Каждый Tier 3 сценарий согласовывается с комплаенсом отдельно.
6. **Взаимодействие с другими агентами.** Часто работает в паре с [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика) и [агентом базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов). Они готовят содержательное наполнение брифа, а агент встреч обеспечивает «обвязку», то есть время, формат и постановку задач после.
7. **Бизнес-эффект.** Сотрудник перестаёт быть контролёром. Договорённости со встреч не теряются, follow-up не превращается в работу самого менеджера. На горизонте месяца это видно по сокращению просроченных задач и по числу встреч, которые начинаются с готовой повестки.
8. **Метрики эффективности.** Доля встреч с автоматически сформированной повесткой. Доля договорённостей, превратившихся в задачи в течение часа после встречи. Число просроченных follow-up'ов до и после внедрения.
---
После трёх карточек ближайшего контура идёт длинный хвост. На первой версии каталога описывать его подробно не будем, обозначим пока одним абзацем на агента.
### 9. Агент ассортимента
Помогает работать с матрицей. Подсвечивает, где избыточные SKU, где, наоборот, не хватает позиций под спрос, какие листинги стоят дороже, чем приносят. Полезен в момент пересмотра матрицы и при подготовке ассортиментного комитета.
*На старте это скилл Напарника. Оркестрирует Text2SQL и финансовый эффект по линейному рецепту, дорастает до агента с собственной библиотекой паттернов матрицы.*
### 10. Агент ценообразования и конкурентного мониторинга
Анализирует ценовое позиционирование, оценивает эластичность по категориям и подсказывает, где переоценка даст эффект. Сам собирает рыночные данные о ценах, ассортименте и промо конкурентов, сравнивает с собственным предложением и выявляет разрывы. Полезен прайс-менеджерам и руководителям категорий, тесно связан с агентом финансового эффекта. На пилоте чаще всего идёт через внешние источники данных и требует отдельной интеграции.
*Полноценный агент. У него собственный внешний сбор конкурентных данных и изолированный доступ к внешним источникам, которых нет у Напарника, а на зрелом этапе возможен и собственный движок оценки эластичности.*
### 11. Агент факторного анализа
Раскладывает изменение показателя (выручка, маржа, средний чек, трафик) на вклад отдельных факторов (цена, объём, микс, промо, потери, списания) и помогает понять, что именно сдвинуло результат. Отвечает на вопрос «почему изменилось», в отличие от агента финансового эффекта, который отвечает «что будет, если».
*Скорее скилл. Это аналитический метод без собственных инструментов и данных. Точечный факторный разбор Напарник уже делает скиллом, а более тяжёлый отдаёт агенту промо. Выделять в отдельного агента имеет смысл, только когда у него появляется собственная библиотека факторных моделей.*
### 12. Агент прогнозирования
Прогноз спроса по SKU и категориям. Под капотом обычно стоит ML-модель, задача агента — обернуть её в удобный интерфейс, подтянуть промо-календарь и сезонность, сделать прогноз пригодным для разговора. Часто вызывается агентом OOS и агентом ассортимента.
*Полноценный агент. Под капотом у него собственная ML-модель, то есть инструмент, которого нет у Напарника.*
### 13. Коллективная память и агент-куратор
Накопление паттернов успешных решений всей команды (разборы кейсов, удачные тактики переговоров, нестандартные диагностики) это **слой памяти платформы**, но не отдельный функциональный агент. У него нет ни собственного класса бизнес-задач, ни цикла рассуждений, поэтому в каталоге агентов самой памяти не место. Подробно роль слоя описана в [05-architecture, раздел «Коллективная память»](/05-architecture/#коллективная-память).
Отдельно от хранилища стоит **агент-куратор коллективной памяти**, и вот он уже полноценный фоновый агент. Он ищет повторяющиеся паттерны в сессиях разных Напарников, оценивает их по частоте и устойчивости и предлагает кандидатов на вынос в общий слой (механизм описан в том же разделе [05-architecture](/05-architecture/#коллективная-память)). По свойствам он близок к [агенту мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий), то есть несёт собственный фоновый цикл, своё состояние и проактивность. Эту сущность и осмысленно оставлять в каталоге, а не «память» как таковую.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Где граница между скиллом Напарника и отдельным агентом]
Тест из раздела [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника) даёт практический ориентир (отдельный агент оправдан при трёх свойствах из пяти), но сам порог это скорее соглашение, но не строгое правило. Ряд сущностей сидит ровно на этой границе. Агент промо, агент OOS и агент ценообразования по формальным критериям пограничны, и отнесение их к агенту или скиллу меняется в зависимости от режима работы и зрелости внедрения. Сложнее то, что граница подвижна в обе стороны. Скилл дорастает до агента по мере накопления собственной экспертизы, а удачный паттерн агента, наоборот, отчуждается в общий скилл. Кто принимает это решение, по какому сигналу и в какой момент скилл «выпускается» в отдельного агента, концепт не формализует. Ошибка стоит дорого в обе стороны. Поспешно вынесенный агент добавляет инфраструктуру и стоимость там, где хватило бы инструкции в промпте, а запоздалое решение раздувает промпт Напарника линейными рецептами, которые давно просятся в отдельного исполнителя. На старте этот выбор делается экспертно и пересматривается под конкретного заказчика.
:::
:::caution[Где именно резать перекрытие между агентами]
Принцип «один агент, один класс задач» звучит как правило, но на практике это скорее суждение. Агент финансового эффекта («что будет, если») и агент факторного анализа («почему изменилось») работают с одними данными и легко сливаются в один. То же касается агента OOS и агента прогнозирования, который легко растворяется внутри него. Где проходит граница между «здоровой специализацией» и «искусственным дроблением», документ не формализует.
:::
---
# Сценарии использования
> Бизнес-сценарии, в которых ИИ-Напарник и функциональные агенты работают на стороне категорийного менеджера и смежных ролей. Включает подготовку к переговорам, разбор падения продаж, эффективность промо, управление OOS, межфункциональную встречу и backlog развития.
Источник: https://ai-partner-ru.chvanov.com/raw/04-usecases.mdx
Документ описывает работу платформы через реальные ситуации торговой сети. В каждом сценарии разобрано, что менеджер делает сегодня, что меняется с Напарником, какие агенты подключаются и какой эффект ожидается.
## Из этого раздела вы узнаете
- по каким принципам описаны сценарии, чтобы их можно было сравнивать и переиспользовать в презентациях
- какие роли участвуют в сценариях и кому достаётся ценность
- как устроена карта сценариев и что разобрано детально, а что лежит в backlog
- как платформа меняет пять ситуаций, среди них переговоры с поставщиком, разбор падения продаж, эффективность промо, управление OOS и межфункциональная встреча
- какие сценарии ждут детализации и от чего это зависит
---
## Коротко
В документе разобраны четыре сценария, на которых проще всего показать ценность платформы. Это подготовка к переговорам с поставщиком, разбор падения продаж по категории, анализ эффективности промо и управление OOS. Пятым идёт межфункциональная встреча. Аналитики в ней нет, зато видно, как Напарники договариваются между собой от имени своих сотрудников.
Все сценарии написаны от имени бизнеса. Нам было важно показать сдвиг в работе человека, а не устройство платформы.
Остальные сценарии (день категорийного менеджера, ассортиментный комитет, кризисная ситуация, онбординг, поиск лучших практик) пока в backlog. Они появятся, когда под них возникнет конкретная потребность у заказчика.
:::tip[Главный тезис документа]
Ценность платформы лучше всего видна на конкретных ситуациях. В каждом сценарии показан сдвиг в работе человека, без акцента на устройство [платформы](/05-architecture).
:::
---
## Принципы описания сценариев
Чтобы сценарии были сравнимыми и переиспользуемыми в презентациях, мы договорились о нескольких правилах.
Сценарий пишем от лица человека и его задачи. Названия агентов, ключи сессий и протоколы остаются под капотом. Технику показываем, но отдельным блоком в конце сценария, где это уместно.
Без раздела «как это устроено сейчас» цифры и обещания звучат неубедительно. Поэтому в каждом сценарии сначала идёт типичный день без платформы, со всеми переключениями и потерями времени, и только потом изменённая версия.
В сценарии всегда видно, что Напарник делает сам, что готовит на подпись, а что остаётся решением менеджера. Без этой границы быстро возникает страх «робот всё решит за меня», и разговор уходит в сторону.
Лучше осторожная цифра с пояснением «зависит от стартовой зрелости заказчика», чем ровные 30% к марже на каждом слайде. Красивые, но плохо измеримые эффекты выносим отдельно как качественные.
:::tip[Сценарий не равен дорожной карте]
Сценарии описывают, как работает уже развёрнутая платформа в конкретной ситуации, но не последовательность фаз внедрения. Привязка сценариев к фазам пилота, MVP и масштабирования описана в [07-roadmap, раздел «Приоритетные сценарии для старта»](/07-roadmap/#приоритетные-сценарии-для-старта).
:::
---
## Карта сценариев
Карта нужна, чтобы видеть общую картину и понимать, где какие агенты задействованы. Подробно разобраны первые четыре, пятый (межфункциональная встреча) проработан достаточно, чтобы стоять рядом с ними. Остальные в backlog.
| Сценарий | Главный пользователь | Основные агенты | Статус описания |
|---|---|---|---|
| [Подготовка к переговорам с поставщиком](#сценарий-1-подготовка-к-переговорам-с-поставщиком) | Категорийный менеджер | Переговоры, финансовый эффект, OOS, базы знаний | |
| [Разбор падения продаж по категории](#сценарий-2-разбор-падения-продаж-по-категории) | Категорийный менеджер | Факторный анализ, Text2SQL, OOS, промо | |
| [Анализ эффективности промо](#сценарий-3-анализ-эффективности-промо) | Руководитель промо, категорийный менеджер | Промо, финансовый эффект, конкурентный мониторинг | |
| [Управление OOS и доступностью товара](#сценарий-4-управление-oos-и-доступностью-товара) | Категорийный менеджер, логист | OOS, прогнозирование, переговоры | |
| [Межфункциональная встреча через Напарников](#сценарий-5-межфункциональная-встреча-через-напарников) | Любой сотрудник со встречами | Встреч и follow-up, промо, конкурентный мониторинг, финансовый эффект | |
| [День категорийного менеджера с Напарником](#день-категорийного-менеджера) | Категорийный менеджер | Все приоритетные | |
| [Подготовка к ассортиментному комитету](#подготовка-к-ассортиментному-комитету) | Категорийный менеджер, директор по категориям | Ассортимент, финансовый эффект, конкурентный мониторинг | |
| [Кризисная ситуация (срыв поставки)](#кризисная-ситуация) | Логист, категорийный менеджер | Алерты, OOS, переговоры, встреч и follow-up | |
| [Онбординг нового менеджера](#онбординг-нового-менеджера) | Новый сотрудник | Базы знаний, организационная память | |
| [Подготовка управленческого summary](#подготовка-управленческого-summary) | Руководитель направления, директор | Все, через Напарника | |
| [Поиск и распространение лучших практик](#поиск-и-распространение-лучших-практик) | Команда, куратор | Организационная память | |
---
## Шаблон описания сценария
Чтобы сценарии не разъезжались по форме, у каждого детально разобранного один и тот же набор разделов.
1. **Бизнес-ситуация.** Конкретная история, в которой оказался сотрудник. Что произошло, в каком контексте и к какому сроку надо отреагировать. Желательно с реалистичным сюжетом, а не с «менеджеру нужно подготовить отчёт».
2. **Участники.** Кто из людей вовлечён и какая у каждого роль. Сюда же попадают внешние участники, например поставщик.
3. **Текущий процесс.** Как ситуация разбирается сегодня, без платформы. По возможности с реальными временами и числом переключений между системами.
4. **Боли текущего процесса.** Что именно болит. Нужны конкретные потери (потерянное время, упущенные аргументы, неиспользованная фактура, забытые договорённости), а не общая формулировка «процесс несовершенен».
5. **Как процесс выглядит с Напарником.** Тот же сюжет в новой модели работы. Шаги диалога, что Напарник делает сам и где останавливается за подтверждением человека.
6. **Какие функциональные агенты участвуют.** Какие агенты подключаются и за что отвечает каждый. Подробности реализации лежат в [03-agents](/03-agents).
7. **Какие данные используются.** Источники, к которым обращается платформа. Обычно это хранилище, BI, регламенты, почта, календарь, внешние индексы.
8. **Какие решения принимаются.** Что меняется в рабочем дне сотрудника по итогам сценария и в какой форме это фиксируется (письмо, задача в трекере, документ на согласование).
9. **Где нужен human-in-the-loop.** Точки, в которых Напарник ждёт явного подтверждения. Они разные в зависимости от [Tier-модели](/05-architecture/#tier-модель-автономии).
10. **Ожидаемый бизнес-эффект.** Качественный и, по возможности, количественный. Лучше диапазон с оговорками, чем красивая средняя.
11. **Метрики успеха.** Как мы поймём, что сценарий действительно работает в пилоте.
---
## Сценарий 1. Подготовка к переговорам с поставщиком
### Бизнес-ситуация
Поставщик Saverio (молочная продукция) присылает письмо. С первого числа следующего месяца он хочет повысить закупочную цену на 5%, ссылается на рост себестоимости. Встреча в среду, у Алексея, категорийного менеджера направления «Молочные продукты», есть полтора рабочих дня на подготовку. Переговоры обещают быть сложными. Saverio занимает 34% полки в категории, его SKU давно знакомы покупателю, прямая замена быстро не находится. Согласие на +5% означает потерю бэк-маржи примерно на 18 миллионов рублей в год (бэк-маржи, не путать с недопоставками). Отказ означает риск ухудшения SLA, который и без того в зоне неопределённости.
### Участники
Переговоры ведёт категорийный менеджер. По данным он опирается на логиста направления (фактические поставки и SLA) и прайс-менеджера (ценовое позиционирование категории). Финальное решение по уровню компромисса подписывает коммерческий директор. На той стороне стола сидит менеджер по работе с сетями со стороны Saverio.
### Текущий процесс
Сегодня подготовка к такой встрече занимает у менеджера от полудня до целого дня и часто остаётся неполной.
1. Менеджер вытаскивает из BI продажи по SKU Saverio за последние 6–12 месяцев, отдельно по регионам и магазинам. Несколько часов на сборку, скриншоты, сведение в Excel.
2. Запрашивает у логистов данные по fill rate и недопоставкам. Логисты обещают вернуться завтра, потому что у них свой загруз и свой формат отчётов. Часть данных приходит в почте Excel-вложением.
3. Идёт в почту искать, что было с Saverio в прошлый раз. Когда повышал цену, на чём согласились, какие были аргументы. Часть переписки потеряна или в архиве, восстановить удаётся только последний раунд.
4. Звонит коллеге, который раньше вёл этого поставщика. Узнаёт про слабое место Saverio, недавнюю жалобу на упаковку из соседней сети. Записывает в блокнот.
5. Открывает аналитический Telegram-канал с индексами цен на сырое молоко. Видит, что индекс снизился на 3% за квартал. Делает скриншот.
6. Собирает аргументационный пакет в Word, частью пересказом, частью копипастой. Отдаёт коммерческому директору на ревью. Тот просит добавить разбор по доле SKU в категории, без него непонятен рычаг давления. Ещё полчаса.
7. К моменту встречи менеджер чувствует, что готов *«процентов на семьдесят»*. Какую-то часть аргументов не успел собрать, какую-то забыл вытащить из системы.
### Боли текущего процесса
Главная боль не во времени, хотя его уходит много, а в неравномерной готовности. Что менеджер успел собрать, он держит в голове. Аргументы, до которых не дошли руки, на встрече просто не появятся. Поставщик задаёт вопрос, ответ на который в данных есть, но менеджер его не посмотрел. Прецеденты теряются, потому что поиск по почте остаётся поиском по почте.
Вместе со временем теряется и системное знание о поставщике. Досье каждый раз собирается с нуля, опыт прошлых переговоров остаётся в голове конкретного человека и уходит вместе с ним из компании.
### Как процесс выглядит с Напарником
С платформой подготовка идёт по другому маршруту. Письмо от Saverio Напарник заметил сразу, классифицировал как переговорное и подсветил как требующее внимания.
1. **Утро понедельника.** В мессенджере менеджер видит сообщение от Напарника. *«Saverio запросил +5% к закупочной цене. Встреча у тебя в среду в 14:00 (поставил предварительно). Готовлю досье. По сильным сторонам нашей позиции у нас индекс цен на сырое молоко -3% за квартал, недопоставки на 17 млн ₽ из-за SLA 87% при норме 95%, в сентябре поставщик уже уступал при угрозе делистинга. По слабым сторонам у нас доля SKU в категории 34%, прямой замены без потерь нет. Подготовлю полный пакет к 12:00, согласовать со встречей коммерческому директору?»*.
2. **К полудню понедельника** менеджер получает структурированный документ. Внутри разбор продаж по SKU и регионам, анализ маржинальности, разбор SLA с разбивкой по месяцам, индексы цен на сырьё, прецеденты переговоров (2024, 2025), профиль контактного лица со стороны Saverio (что важно, какие аргументы работали, на что эмоционально реагирует) и оценка финансового эффекта решения «согласиться» против «не согласиться» и против промежуточных вариантов.
3. **Реакция менеджера.** Просит Напарника добавить разбор по двум SKU, по которым недавно меняли поставщика, чтобы было видно, что замена возможна. Напарник за минуту дописывает раздел.
4. **Тот же день, 14:00.** Менеджер делится черновиком с коллегами через Напарника. Напарник прайс-менеджера и Напарник логиста добавляют свои комментарии. У людей на той стороне это занимает минуты, потому что фактура уже подготовлена.
5. **Среда, 13:50.** Перед встречей Напарник присылает сжатую карточку на одну страницу. На ней главные аргументы и финансовый расклад, а отдельной строкой записана точка отступления, до которой менеджер готов уступить.
6. **Среда, 14:00.** Встреча идёт онлайн. Поставщик ссылается на рост стоимости упаковки. Напарник в реальном времени подсказывает в боковой канал, что индекс цен на гофрокартон -2% за квартал, а упаковка в структуре себестоимости поставщика около 8%. Менеджер встраивает это в разговор без видимой паузы. Поставщик уходит на аргумент про логистику, Напарник подсказывает SLA по последним трём месяцам и фактический fill rate 87%. Разговор заканчивается компромиссом. Повышение идёт на 1.5% при условии возвращения SLA к 95%, условие фиксируется в дополнительном соглашении.
7. **Среда, 15:30.** После встречи Напарник сам делает следующий шаг. Записывает договорённость в личную память, обновляет профиль контактного лица Saverio, ставит задачу логисту начать мониторинг fill rate под новое условие, готовит черновик письма-подтверждения от менеджера. Менеджер читает, нажимает «отправить». Договорённость уходит в коллективную память как кандидат для будущих переговоров. Это успешный паттерн «повышение в обмен на восстановление SLA» с пометкой «нужна валидация куратора перед публикацией».
### Какие функциональные агенты участвуют
Главную работу делает [агент переговоров](/03-agents/#6-агент-переговоров-и-поставщика). Он собирает досье, профилирует контактное лицо поставщика и формирует аргументационный пакет. Параллельно [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) моделирует варианты решения (что будет с маржой при каждом сценарии), [агент OOS](/03-agents/#7-агент-oos-и-запасов) приносит фактуру по SLA и недопоставкам, а [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов) достаёт прецеденты прошлых переговоров. На обвязке встречи (календарь, слот, постановка задач после) работает [агент встреч и follow-up](/03-agents/#8-агент-встреч-и-follow-up). Подробное устройство этих агентов лежит в [каталоге агентов 03-agents](/03-agents/#карточки-приоритетных-агентов) (часть из них на старте реализована как скиллы Напарника, см. там же раздел [«Когда агент, а когда скилл Напарника»](/03-agents/#когда-агент-а-когда-скилл-напарника)).
### Какие данные используются
В дело идут продажи, маржа и доля поставщика в категории, а также показатели поставок (fill rate, недопоставки, штрафы) из корпоративного хранилища (туда их регулярно выгружает WMS). К ним добавляются внешние индексы цен на сырьё и упаковку. Картину дополняют прецеденты прошлых уступок и стандарты переговоров из корпоративной базы знаний и история переписки с поставщиком из почты. Профиль контактного лица берётся из личной памяти Напарника, а слоты под встречу и follow-up живут в календаре и таск-трекере.
### Какие решения принимаются
Менеджер принимает два связанных решения. Первое касается позиции, с которой он садится за стол. Второе касается уровня допустимого компромисса по итогам встречи. По результатам менеджер обновляет условия контракта через стандартный согласовательный маршрут компании (не через Напарника), ставит логисту задачу по мониторингу SLA, и поставщику уходит письмо-подтверждение. Каждое из этих действий проходит через явный клик. Напарник готовит, а решение и кнопку «отправить» нажимает человек.
### Где нужен human-in-the-loop
Главная точка остановки находится на итоговой позиции на встрече. Напарник может рекомендовать диапазон, но решение всегда принимает менеджер. Вторая точка касается любого внешнего письма. Черновик готовит Напарник, кнопку «отправить» нажимает человек. Третья, менее очевидная, связана с публикацией паттерна в коллективной памяти. Здесь промежуточным звеном работает куратор [организационной памяти](/05-architecture/#память-и-контекст), потому что коммерчески значимые решения автоматическая консолидация публиковать не должна. Подробности механизма лежат в [05-architecture, раздел «Память и контекст»](/05-architecture/#память-и-контекст).
### Ожидаемый бизнес-эффект
Доля встреч с подготовленным досье в коммерческой дирекции обычно стартует с 20%. Это наша экспертная оценка по итогам пресейл-интервью с категорийными менеджерами розничных сетей в 2025–2026 годах. С платформой эта доля выходит на 90% и выше уже в пилоте, потому что досье готовится само. На бэк-марже это даёт прямой эффект, лучше подготовленный менеджер чаще выбивает условия в свою пользу. Размер зависит от категории и стартовой позиции сети, но речь идёт о десятках миллионов рублей в год на масштабе крупной сети.
Отдельно растёт защищённость от ухода сильного менеджера. Профили поставщиков, история уступок и удачные тактики не остаются в личной голове, а попадают в общий контур.
### Метрики успеха
Мерим долю переговоров, к которым менеджер приходит с готовым досье. Её замеряют до пилота и после, как и время на подготовку. Рядом работает качественная оценка досье менеджером после встречи по 5-балльной шкале. На бизнес-уровне сильнее всего звучит эффект на бэк-маржу, и его удобно мерить когортой подготовленных встреч против неподготовленных. Отдельно стоит держать долю паттернов, попавших в коллективную память и прошедших валидацию куратора. По ней видно, что платформа помогает в конкретной встрече и заодно собирает общий ресурс команды.
---
## Сценарий 2. Разбор падения продаж по категории
### Бизнес-ситуация
Понедельник, утренний ритуал. Категорийный менеджер открывает BI и видит «Молочные продукты, Сибирский ФО, март, факт −9.2% к плану». Через неделю еженедельная коммерческая планёрка, на ней нужно объяснить, что произошло, и сказать, что с этим делать. По сети в целом цифра в норме, провал именно в одном регионе.
### Участники
Разбор делает категорийный менеджер, и с ним он идёт на планёрку. До платформы такие запросы обычно делегировались аналитику коммерческой дирекции, поэтому он остаётся в сценарии как «человек, которого мы освобождаем». Логист направления отвечает за фактические данные по поставкам в Сибирский ФО, региональный коммерческий руководитель сидит в этом регионе как заинтересованная сторона, а коммерческий директор задаёт вопросы на планёрке.
### Текущий процесс
Сегодня разбор идёт в несколько итераций и редко укладывается в один день.
1. Менеджер видит цифру и формулирует первую гипотезу, что это, вероятно, OOS. Идёт в BI смотреть остатки. По нескольким SKU остатки действительно были низкие, но это не объясняет всего минуса.
2. Запрашивает у аналитика факторный разбор. Аналитик стоит в очереди, разбор будет *«к среде, может, к четвергу»*.
3. К среде разбор приходит диаграммой каскада. Главный вклад дают рост закупочных цен Danone +8% и недопоставки трёх SKU. Менеджер хочет провалиться в детали, но в Excel это сложно. Там готовый отчёт, перекроить разрез нельзя.
4. Идёт к логистам. Те подтверждают недопоставки, обещают прислать таблицу к концу дня. Таблица приходит в формате, не совместимом с Excel менеджера.
5. К пятнице картина вроде сложилась. Менеджер собирает презентацию. На планёрке коммерческий директор спрашивает, сравнивали ли с конкурентом. Сравнить времени уже не было.
6. После планёрки менеджер ставит себе задачу провалиться в данные конкурентов. Через неделю это снова не главный приоритет.
### Боли текущего процесса
Главная проблема в скорости. Между вопросом и обоснованным ответом проходит неделя, и за эту неделю состояние категории успевает измениться, так что часть выводов оказывается уже неактуальной к моменту планёрки.
Дальше ломается глубина. Аналитик отдаёт готовый отчёт со свёрнутым разрезом, и если на планёрке возникает новый вопрос (а он возникает почти всегда), ответа не будет до следующего цикла. Менеджер отвечает *«давайте проверим на следующей неделе»*, и эта «следующая неделя» означает реальный сдвиг решения в портфеле.
Ещё одна обидная вещь связана с ситуативной слепотой. Менеджер видит вопрос *«почему упало»*, но не видит автоматически смежные. Что с конкурентом, что с промо, что было с матрицей в этом периоде. Их приходится специально вспоминать, и на каждой планёрке находится тема, на которой не вспомнили.
И последнее, структурное. Расследование часто затевают ради планёрки, а не ведут как непрерывный процесс. Если планёрки нет, никто в цифру не проваливается. В результате тренды, которые можно было поймать заранее, обнаруживаются только когда упало достаточно сильно, чтобы попасть в обязательный отчёт.
### Как процесс выглядит с Напарником
В новой модели разбор начинается раньше, чем у менеджера возникает вопрос.
1. **Воскресенье ночью** агент аномалий замечает значимое отклонение по молочной продукции в Сибири и запускает факторный разбор автоматически.
2. **Утро понедельника, 9:15.** В мессенджере короткое сообщение от Напарника. *«По молочке в Сибири за март -9.2%. Главная причина в росте закупочных цен Danone на 8% (вклад -5.4 п.п.) и недопоставках трёх SKU из-за SLA 91% (вклад -2.3 п.п.). Эти два фактора покрывают не весь минус, ещё около 1.5 п.п. пока не разложены, копаю. Промо и конкуренты в норме. Доказательная база и отвергнутые гипотезы прикладываю. Через три дня встреча с Danone, готовить досье?»*.
3. **Менеджер уточняет.** *«Покажи разрез по магазинам, есть подозрение, что в одной из подсетей проблема»*. Напарник за тридцать секунд возвращает разрез. Половина минуса концентрируется на 12 магазинах из 87, и все они в одном кластере. По кластеру параллельно идёт ремонт холодильного оборудования.
4. **Менеджер уточняет ещё раз.** *«Что было бы, если бы не было этой проблемы с холодильниками?»*. Напарник делает контрфактический расчёт. -9.2% превратились бы в -5.8%, и тогда основным фактором оказывается цена Danone, а проблема холодильников добавляет 3.4 п.п. поверх.
5. **Менеджер просит сравнение с конкурентом.** Напарник вытаскивает доступные данные по доле полки и публичные индексы по категории. Делает оговорку, что на квартал у конкурента похожая динамика, но точную цифру по марту дать не может, данные публикуются с задержкой.
6. **Среда.** На планёрке менеджер заходит с готовой картинкой. В ней главная причина, второй и третий факторы, контрфактический расчёт, а в рекомендации отдельный план по холодильникам и пересмотр условий с Danone в эту пятницу. Коммерческий директор спрашивает про конкурента, менеджер отвечает по существу. Спрашивает про промо, Напарник в боковом канале мгновенно подсказывает, что промо в марте по молочке в Сибири было два, ROI обоих в норме, каннибализации нет. Менеджер озвучивает.
7. **После планёрки** Напарник записывает выводы в личную память. Теперь, если через два месяца возникнет похожая ситуация, он сразу поднимет прошлый разбор по молочке в Сибири с уже проверенными факторами и отвергнутыми гипотезами.
### Какие функциональные агенты участвуют
Ядро сценария составляет [агент факторного анализа](/03-agents/#11-агент-факторного-анализа). Он раскладывает отклонение на факторы и формирует диагностическую карточку с главным выводом, доказательной базой, отвергнутыми гипотезами и следующим шагом (структура карточки описана в [03-agents](/03-agents)). Дополняют его другие агенты. [Text2SQL](/03-agents/#5-text2sql) делает нестандартные срезы по запросу менеджера, [агент OOS](/03-agents/#7-агент-oos-и-запасов) приносит данные по SLA, а [агент промо](/03-agents/#1-агент-промо) проверяет, не объясняется ли часть просадки промо-эффектом. Цепочка запускается с одного действия. [Агент аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) первым ловит отклонение и проактивно запускает разбор, не дожидаясь, пока менеджер откроет BI.
### Какие данные используются
Базовый набор приходит из того же корпоративного хранилища (связку «хранилище ← WMS» см. в сценарии 1), сюда входят продажи, маржа, остатки, цены, фактические поставки и SLA. К ним добавляются календарь промо вместе с параметрами активных акций и, в той мере, в какой это есть у заказчика, внешние данные о конкурентах. Если в сети есть отдельная система мониторинга оборудования магазинов, она в этом сценарии особенно полезна, без неё связь «провал по кластеру = ремонт холодильников» не возникает автоматически.
### Какие решения принимаются
Менеджер решает, как формулировать ситуацию на планёрке и какие действия предложить. По итогам, как правило, выходит несколько связанных шагов. Прежде всего надо назначить разговор с поставщиком (см. сценарий 1). Параллельно запускается отдельный план по холодильному оборудованию через операционный блок, без него часть проблемы продолжит давить на полку. И корректируется план на следующий месяц с учётом того, что эффект ещё не выгорел.
### Где нужен human-in-the-loop
Сами разборы Напарник делает на [Tier 1](/05-architecture/#tier-модель-автономии) (чтение и подготовка), здесь явное подтверждение не требуется. Внешние действия по итогам разбора (постановка задач, запросы коллегам) идут через явный клик. Обновление коллективной памяти проходит через куратора, как в сценарии 1.
### Ожидаемый бизнес-эффект
Время от вопроса до обоснованного ответа сокращается на порядок. По нашим оценкам из пресейл-интервью с категорийными менеджерами, только на сведение данных уходит по несколько дней в месяц. С Напарником эта часть исчезает, и освободившееся время уходит на интерпретацию и решения.
Параллельно меняется качество разбора. У менеджера на руках всегда расширенная картина (с конкурентом, промо, контрфактическим расчётом), а не та, до которой он успел добраться. На планёрке это видно сразу.
И, наконец, накапливается ценный архив. Через полгода работы у менеджера в личной памяти Напарника лежат все значимые разборы по категории. Когда возникает похожая ситуация, она уже не разбирается с нуля.
### Метрики успеха
Главная операционная цифра здесь это время до первичного факторного разбора, оно должно сжаться от суток до минут. Дальше интересна доля разборов, к которым менеджер вернулся за уточнениями. Если она высокая, значит, Напарник не выдал «отчёт-кирпич», а работает в диалоге. Точность диагностики проще всего собирать как оценку менеджера по 5-балльной шкале. И последнее, что важно для коммерческой дирекции, это доля планёрок, на которых менеджер мог ответить на любой смежный вопрос без откладывания на потом.
---
## Сценарий 3. Анализ эффективности промо
### Бизнес-ситуация
Конец летней промо-кампании по кондитерским изделиям. Девять акций, четыре из них крупные, с инвестицией в маркетинг и в скидку. Через две недели комитет по промо, на нём нужно сказать, что сработало, что нет, и что мы делаем на осень. Параллельно у руководителя промо давление сверху, хочется делать поменьше акций, но более окупаемых, потому что бюджет на следующий год режут на 15%.
Это болезненная ситуация в индустрии. Внешние исследования говорят, что 59–72% трейд-промо в FMCG не окупаются (59% это оценка Nielsen по миру за 2014 год, 72% приводит McKinsey по рынку США), и эта оценка часто повторяется в консалтинговых отчётах разных лет. Реалистично ожидать, что и в этой кампании часть акций окажется в убытке. Открыт вопрос, какие именно и почему.
### Участники
Основным заказчиком разбора становится руководитель промо, ему нужны выводы под комитет и под защиту бюджета. Содержательно с ним работает категорийный менеджер по кондитерке, без него сложно интерпретировать, что произошло на полке. Прайс-менеджер смотрит, не размывает ли промо воспринимаемое ценовое позиционирование категории, а маркетинг приходит со своей частью (коммуникационным разбором и медиа-бюджетом). Финальное слово по осеннему плану остаётся за коммерческим директором.
### Текущий процесс
1. Руководитель промо запрашивает у аналитики разбор по кампании. Тот формирует Excel с продажами в промо, продажами до и после, скидкой, инвестицией и ROI. Около недели.
2. Параллельно категорийный менеджер делает свой разбор. Что у него на полке, как менялась маржа, не было ли каннибализации между SKU. Отдельный Excel.
3. Прайс-менеджер вносит свой кусок, ценовое позиционирование и сравнение с конкурентом в период промо. Третий Excel.
4. Маркетинг присылает свой отчёт с охватами, медиа-миксом и эффективностью каналов. Четвёртый.
5. Кто-то (обычно руководитель промо) пытается всё это свести. Сводка получается крупными мазками. Общий ROI кампании, две-три иллюстрации. Детальный разбор по каждой акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования собрать не получается, не хватает времени.
6. На комитете доклад звучит как *«общий ROI 12%, в целом успешно»*. Через месяц одна из акций оказывается в реальности в минусе по марже категории, потому что переключила покупателей с маржинального SKU на менее маржинальный. Это всплывает уже после, когда кто-то случайно посмотрел.
### Боли текущего процесса
Главная методологическая дыра кроется в каннибализации. Её почти никогда не считают в полную глубину, для этого нужно одновременно работать с продажами, маржой, ценами и матрицей, а у одного аналитика, как правило, нет всех этих данных в одном месте. Каннибализация и закупка впрок в нашей практике сильнее всего снижают ROI промо.
Дальше идёт фрагментация. Четыре отдельных разбора лежат в четырёх файлах без единой логики, и сводка из них получается рыхлой. Сравнить акции между собой по сравнимым метрикам почти невозможно, каждая считалась в своей системе координат.
И третья проблема в задержке. Пока разбор сводится между четырьмя людьми, осенние планы успевают свёрстываться, и часть выводов уже не влияет на решения. Сводка приходит, когда поезд ушёл.
### Как процесс выглядит с Напарником
В платформе разбор идёт сразу как сводный, и за каждым выводом закреплена цифровая фактура.
1. **Понедельник.** Напарник руководителя промо приносит сводный разбор летней кампании. *«9 акций, 4 крупные. Чистый ROI с учётом каннибализации составляет +21% (две акции), +6% (две акции), -4% (одна акция), -12% (две акции). Главный фактор отрицательного ROI это каннибализация на собственный маржинальный SKU. Подробный разбор по каждой акции прикладываю»*.
2. **В разборе по каждой акции** есть единый блок. Он сводит вместе цель акции, фактический результат, чистый эффект на категорию, разрезы по каннибализации и маржинальности, влияние на ценовое позиционирование и медиа-вклад. Каждая цифра кликабельна, можно провалиться к источнику.
3. **Руководитель промо ставит вопрос.** *«А что было бы, если бы убрали из плана две убыточные акции и оставшийся бюджет перераспределили на три самые сильные?»*. Агент финансового эффекта пересчитывает за минуту, что прирост составит +9 п.п. к общему ROI кампании, при этом охват сокращается на 18%. Развилка теперь стоит вокруг того, как сбалансировать маржу и охват, а вопрос «делать ли промо вообще» с повестки уходит.
4. **Категорийный менеджер кондитерки** через своего Напарника подключается к разбору. Видит свою часть, добавляет комментарий, что акция №7 каннибализировалась на собственный новый бренд, который пытались разогнать, и на осень эту пару акций нужно разнести по времени.
5. **Прайс-менеджер** видит своими глазами, что одна из акций просадила воспринимаемый ценовой уровень на 8% за категорию в целом и эффект продержался ещё месяц после акции. Это раньше никто не считал, потому что лень.
6. **Среда, комитет.** Доклад идёт по сводной картинке. На ней видно, что окупилось и почему, а что нет. Отсюда вырастает план на осень с учётом разбора. Сеть отказывается от двух исторически слабых форматов и перебрасывает бюджет на три, плюс одна экспериментальная новая. Сравнение с прошлым годом теперь идёт по реальному эффекту на маржу категории, а общий ROI уходит на второй план.
7. **После комитета** Напарник кладёт паттерн каннибализации между конкретной парой SKU в коллективную память. В следующий раз при планировании любой акции по этой паре Напарник предупредит автоматически.
### Какие функциональные агенты участвуют
Главным здесь работает [агент промо](/03-agents/#1-агент-промо). Он считает чистый эффект акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования. Рядом подключаются [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) (моделирует альтернативные сценарии вроде «убрать две убыточные акции и перераспределить бюджет») и [агент конкурентного мониторинга](/03-agents/#10-агент-ценообразования-и-конкурентного-мониторинга), добавляющий внешний контекст по ценам и ассортименту конкурентов. [Text2SQL](/03-agents/#5-text2sql) даёт доступ к нестандартным срезам, а подготовку комитета берёт на себя [агент встреч и follow-up](/03-agents/#8-агент-встреч-и-follow-up).
### Какие данные используются
Большую часть данных даёт корпоративное хранилище. Это продажи, маржа, остатки и цены до акции и после. К нему подключаются параметры акций и план из систем промо-планирования, а также медиа-часть из маркетинг-систем (бюджеты, охваты, креативы). Внешние данные о конкурентах участвуют в той мере, в какой они вообще подключены к платформе у заказчика.
### Какие решения принимаются
По итогам комитета согласуется осенний план промо с учётом разбора лета. Решается, какие форматы сеть больше не повторяет, какие пары SKU стоит разносить по времени из-за каннибализации, как перебалансировать бюджет на осень и зиму. Часть этих решений становится постоянными правилами в системе планирования, часть остаётся методическими заметками в коллективной памяти.
### Где нужен human-in-the-loop
Любые изменения в системе промо-планирования делает менеджер по стандартному маршруту. Напарник готовит обоснование, готовит черновик, рекомендует, а финальный шаг делает человек. Публикация паттерна каннибализации в коллективную память идёт через куратора.
### Ожидаемый бизнес-эффект
Прямой эффект в том, что неэффективных акций становится меньше. По индустриальным цифрам (те же оценки Nielsen и McKinsey), значительная часть промо в продуктовом ритейле не приносит прибыли при аккуратном подсчёте. На платформе такой расчёт получают по каждой акции, и заметная часть планируемых промо просто не доходит до запуска. Это сразу высвобождает бюджет, при этом доля категории на полке не падает. Наоборот, освободившиеся деньги идут на сильные форматы.
Косвенный эффект в том, что разговор между промо, категорийщиками и прайсом становится зрелее. Когда есть единый разбор с одинаковой методологией, спор вокруг *«у тебя одна цифра, у меня другая»* исчезает. Освободившееся внимание уходит в обсуждение, что делать дальше.
### Метрики успеха
Базовая методологическая метрика это доля промо, по которым посчитан чистый эффект с учётом каннибализации. Она обычно стартует с единиц процентов, целевое значение близко к 100%. На бизнес-уровне работает динамика общего ROI промо-портфеля категории и доля бюджета, перераспределённого с неэффективных форматов на эффективные. Отдельно стоит замерять скорость подготовки разбора. Она в этом сценарии падает от недель до часов, и это ощутимо снимает нагрузку с аналитики.
---
## Сценарий 4. Управление OOS и доступностью товара
### Бизнес-ситуация
Утро среды, среднее время приезда товара по плану два дня. Категорийный менеджер видит в BI, что по категории «Молочные продукты» три SKU вышли на нулевой остаток в шести магазинах одного кластера. Если ничего не делать, в выходные (пиковый день по категории) на полке будут пустые места. Прямые потери от классического OOS в продуктовом ритейле оцениваются примерно в 4% продаж. Эта цифра идёт из классического международного исследования Corsten и Gruen (GMA, 2002 год), которое до сих пор остаётся отраслевым ориентиром. До четвёртого июня (пятницы) короткий период, в который нужно либо переключиться на альтернативный РЦ, либо подгонять экстренный заказ, либо временно подменить SKU.
### Участники
Решение заказывает категорийный менеджер, но руками здесь работает в основном логист направления. Он переключает машины между РЦ и согласовывает с поставщиком экстренный заказ. Поставщик участвует с внешней стороны. Операционный руководитель кластера магазинов следит за полкой и решает скучный, но важный вопрос, что выкладывать вместо, пока товара нет.
### Текущий процесс
1. Менеджер замечает проблему сам в обычной утренней рутине, открыв BI. Это уже удача. Чаще проблему замечают, только когда прилетает жалоба от регионального руководителя.
2. Звонит логисту. Тот сейчас занят другой проблемой. Обещает посмотреть.
3. Логист через час перезванивает. Альтернативный РЦ есть, но переключить машину туда займёт два дня, и к выходным товар поспеет в притык, а часть магазинов останется без него.
4. Менеджер звонит поставщику, договаривается об экстренной партии. Поставщик подтверждает, но fill rate у него в этом квартале уже 84%, доверия не стопроцентное.
5. Менеджер просит операционного руководителя кластера временно расширить выкладку соседних SKU.
6. К пятнице картина следующая. На двух магазинах из шести товара нет, на четырёх есть, но мало. В выходные продажи категории в этом кластере проваливаются на 18% против обычного.
7. В понедельник менеджер разбирает случившееся. Первичный вывод сводится к недопоставке, второй к тому, что не успели переключиться. О том, что сигнал был во вторник вечером (а не в среду утром), узнают только когда смотрят логи.
### Боли текущего процесса
Главное в реактивности. OOS сегодня обнаруживается, когда уже почти поздно. Пока сигнал доходит до человека, окно для манёвра сокращается с 48 часов до 12, а на коротком окне почти все варианты дороже. У менеджера почти не остаётся выбора, он просто гасит то, что доступно.
Параллельно мешает разрозненность данных. Чтобы оценить серьёзность ситуации, менеджеру нужны одновременно остатки в магазинах, прогноз спроса, статус поставки, fill rate поставщика и календарь промо. Эти пять кусков информации лежат в четырёх разных системах, и одна только их сборка занимает у человека полчаса.
Хуже того, плохо видна системность. Конкретный OOS воспринимается как «случай», и каждый эпизод закрывается отдельно. А то, что у конкретного поставщика fill rate на 8 п.п. ниже SLA уже три квартала подряд, остаётся паттерном, который никто не собирает в одном месте, разные люди видят разные эпизоды и каждый в своей голове считает *«у меня было дважды»*.
И как следствие, в переговоры с поставщиком про SLA приходится идти с общими словами, без жёсткой фактуры. У поставщика всегда находится ответ *«ну это случай»*, и без накопленной картины спорить с ним сложно.
### Как процесс выглядит с Напарником
В платформе OOS перестаёт быть событием, которое замечает человек по утрам, и становится потоком, который ведут агенты.
1. **Вторник, 18:30.** Агент OOS видит, что по трём SKU в шести магазинах одного кластера прогноз остатка к утру среды уходит в ноль. С учётом календаря промо и сезонности по выходным это даст потерю выручки порядка 2.4 млн ₽ за уикенд. Запускает поиск решения.
2. **Вторник, 18:35.** Напарник менеджера приходит с уже собранным пакетом. *«Прогноз OOS по 3 SKU в кластере N к утру среды. Через альтернативный РЦ A переключимся за 36 часов, успеваем. Поставщик может прислать экстренную партию физически, но fill rate у него за квартал 84%, рекомендую как страховку, не как основной вариант. Подмена соседними SKU согласована операционным руководителем кластера ещё в апреле. По оптимальному плану переключаемся на РЦ A, делаем страховочный заказ и расширяем выкладку в шести магазинах. Запросить у Напарника логиста подтверждение?»*.
3. **Вторник, 18:40.** Менеджер подтверждает. Напарник логиста за десять минут получает добро от своего сотрудника. Переключение на РЦ A инициируется. Операционному руководителю кластера уходит уведомление с предложенной выкладкой.
4. **Среда и пятница.** Агент OOS отслеживает движение. Товар вышел с РЦ A в указанное время, доехал в магазины в пятницу к утру. Категорийный менеджер на этом этапе вообще не вовлечён, кроме одного автоматического статус-сообщения в среду вечером, что всё идёт по плану.
5. **Выходные.** Полка не пустая, продажи в норме. О ситуации, которая в старой модели стоила бы ему всей недели, менеджер только знает, что она была.
6. **Понедельник.** Напарник приносит короткий разбор. *«Эпизод OOS вторник-пятница закрыт. Корневая причина в недопоставке от поставщика B, fill rate которого за последние шесть месяцев колеблется около 84%. С июля у нас семь похожих эпизодов по этому поставщику. Готов добавить в досье следующих переговоров с ним»*. Менеджер подтверждает.
### Какие функциональные агенты участвуют
Главную работу делает [агент OOS](/03-agents/#7-агент-oos-и-запасов). Он и проактивно ловит проблему, и оркеструет варианты решения. К нему подключается [агент прогнозирования](/03-agents/#12-агент-прогнозирования) (он даёт оценку спроса с учётом промо и сезонности, без неё непонятно, насколько критична нехватка) и [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта), оценивающий стоимость каждого варианта в рублях. Параллельно идёт фоновая работа [агента переговоров](/03-agents/#6-агент-переговоров-и-поставщика). Он не вмешивается в сам инцидент, но копит фактуру по поставщику для следующего разговора. За уведомления и эскалации отвечает [агент аномалий](/03-agents/#2-агент-мониторинга-и-аномалий), для которого алертинг это встроенная функция. Подробное устройство этих агентов лежит в [03-agents](/03-agents).
### Какие данные используются
Из корпоративного хранилища (связку «хранилище ← WMS» см. в сценарии 1) берутся остатки на РЦ и в магазинах, продажи, прогноз спроса, поставки, графики, фактические даты прихода и SLA поставщиков с разбивкой на fill rate, отказы и замены. К ним подключаются календарь промо и карта альтернативных маршрутов между РЦ. Карта маршрутов нужна, чтобы агент мог сам предложить переключение, а не просить логиста собрать варианты руками. В сценариях, где задержка в выгрузке принципиально мешает работе (например, оперативная картина по конкретному РЦ в момент срыва поставки), допускается точечное прямое подключение к WMS, согласованное с владельцем системы.
### Какие решения принимаются
В моменте идут три связанных подтверждения от людей. Переключение машины на альтернативный РЦ (логист), экстренный заказ у поставщика (логист) и временное расширение выкладки соседних SKU (операционный руководитель кластера). На горизонте дольше принимается решение включить накопленный паттерн по fill rate этого поставщика в досье следующих переговоров. Его принимает категорийный менеджер уже после того, как эпизод закрыт.
### Где нужен human-in-the-loop
Любое физическое движение товара (переключение РЦ, экстренный заказ, подмена SKU) идёт через явный клик соответствующего сотрудника. Напарник готовит, человек подтверждает. На уровне [Tier 3](/05-architecture/#tier-модель-автономии) со временем можно вынести в автономный режим тривиальные случаи, например стандартное переключение между двумя ближайшими РЦ при остатке ниже X дней, но это включается точечно, после периода доверия. Подробности лежат в [05-architecture, раздел «Human-in-the-loop»](/05-architecture/#human-in-the-loop).
### Ожидаемый бизнес-эффект
Главный эффект в снижении длинного OOS, то есть случаев, которые длятся больше суток. Именно они успевают увести покупателя к конкуренту и дают непропорционально большой вклад в потери. В исследовании Corsten и Gruen около 3% самых ходовых позиций дают порядка 17% всех потерь от нехватки, поэтому гасить в первую очередь нужно именно их. С платформой длинные OOS почти не возникают, проблему замечают за часы, а не за дни.
Второй эффект связан с возвратом фактуры в переговоры. Когда у менеджера есть систематическая картина по fill rate каждого поставщика, с разрезом по месяцам, SKU и кластерам, переговорная позиция меняется. Это, в свою очередь, входит в сценарий 1 как одна из самых сильных аргументационных цепочек.
### Метрики успеха
Первая метрика здесь это время от события OOS до алерта. Оно должно перейти из часов и суток в минуты. Следом идёт доля длинных OOS длительностью больше 24 часов, и здесь целевая динамика к нулю. На горизонте полугода становится виден сдвиг по fill rate проблемных поставщиков, в их сторону начинает идти регулярная фактура. И отдельно стоит держать долю OOS-инцидентов, закрытых без вовлечения категорийного менеджера сверх одного подтверждения. По ней видно, насколько процесс действительно автоматизирован, а не просто оснащён красивыми алертами.
---
## Сценарий 5. Межфункциональная встреча через Напарников
Это сценарий другой природы. Здесь нет ни аналитики, ни переговоров с внешним участником, ни факторного анализа. Зато он показывает базовую координацию между сотрудниками внутри сети, когда Напарники начинают разговаривать между собой по управляемой политике межагентского взаимодействия.
### Бизнес-ситуация
Категорийному менеджеру по кондитерке нужно за неделю встретиться с прайс-менеджером и руководителем промо, чтобы обсудить летнюю акцию по конкретной линейке шоколадных конфет. Календари у всех плотные. Тема несрочная, но если её отложить, промо поедет вкатываться без согласования и потом будет тяжело сводить.
### Участники
Встречу инициирует категорийный менеджер, приглашёнными участниками идут прайс-менеджер и руководитель промо. У всех троих свои Напарники, и в этом сценарии вся настройка встречи происходит между ними, а не между людьми.
### Текущий процесс
Сегодня это занимает по-человечески обидное количество шагов.
1. Менеджер пишет обоим в мессенджере, что нужна встреча на 30 минут на следующей неделе, есть что обсудить по акции.
2. Один отвечает *«попробую посмотреть, перезвоню»*. Второй через два часа просит дать слот, который он подберёт. Менеджер пишет, у кого какие свободные слоты он видит в общем календаре. Тот говорит *«не подходит, давай в четверг утром»*. Первый говорит *«я по утрам в четверг занят»*. Идёт переписка.
3. Менеджер ставит встречу в четверг днём, оба соглашаются. Повестку формулирует в стиле *«обсудим летнее промо по конфетам»*.
4. Никто из участников не готовится. Все приходят с тем, что помнят.
5. Встреча начинается с того, что каждый вытаскивает свой контекст. Менеджер пересказывает ситуацию с поставщиками, прайс-менеджер добавляет картину по ценам, руководитель промо подтягивает свой медиа-бюджет. Уходят первые 15 минут из 30.
6. До решения дело доходит, но вскользь. Договариваются вернуться к этому ещё раз через неделю.
### Боли текущего процесса
Половина встречи уходит на то, чтобы все вошли в один и тот же контекст. Никто не пришёл подготовленным, потому что не было повода готовиться и не было материала перед встречей. Договорённости фиксируются устно и часто теряются между встречами.
И самое скучное в том, что на сборку самого факта встречи в календарях уходит несколько перепалок и рабочих часов трёх человек.
### Как процесс выглядит с Напарниками
В новой модели встреча собирается между Напарниками и готовится автоматически.
1. Менеджер говорит своему Напарнику. *«Поставь встречу с прайс-менеджером и руководителем промо на следующей неделе на 30 минут. Хочу обсудить летнее промо по линейке шоколадных конфет»*.
2. Напарник менеджера обращается к Напарникам прайс-менеджера и руководителя промо. Они согласовывают слоты, проверяя у своих сотрудников предпочтения (кто-то не любит ставить встречи до 11:00, кто-то блокирует пятницу под планёрку). Через две минуты у менеджера в мессенджере приходит результат, что договорились на четверг 15:00, встреча поставлена, повестка добавлена.
3. **Накануне встречи** каждый из трёх Напарников готовит своему сотруднику короткий бриф под эту встречу, каждый со своей оптики. Категорийный менеджер получает по линейке прирост 4% к прошлому году, отметку, что две из трёх SKU участвовали в весеннем промо с ROI 9% и -2%, и напоминание, что в феврале поставщик просил +3% к закупочной цене, отбили. У прайс-менеджера своя картина, по этой линейке сеть дороже конкурента в своём ценовом сегменте на 3%, чем и объясняется часть провала по объёму, а уход в промо ниже на 7% вывел бы на конкурентный уровень. Руководителю промо важнее бюджет, летом по кондитерке его порезали на 15%, выгоднее вложиться в две акции вместо обычных трёх, и тогда стоит решить, какую из обсуждаемых линеек брать.
4. **Встреча.** У всех троих перед глазами свой бриф. Никто не пересказывает контекст друг другу, он у всех в голове. Обсуждение начинается сразу с предмета. Брать ли линейку в летнее промо, какой формат, какой уровень скидки, как избежать каннибализации. За 30 минут принимается решение.
5. **После встречи** Напарник категорийного менеджера фиксирует договорённости в виде задач. Подготовить запрос поставщику на дополнительные объёмы, согласовать с ценообразованием окончательную скидку, отправить в маркетинг бриф на креатив. Каждая задача попадает к нужному сотруднику через его Напарника. Никто из людей не тратит на эту обвязку ни минуты.
### Какие функциональные агенты участвуют
Этот сценарий особенный тем, что одного главного агента в нём нет. Логистику встречи (поиск общего слота, бронирование, повестку, приглашения) берёт на себя календарный скилл каждого Напарника, а сами слоты Напарники согласовывают между собой напрямую по A2A. Содержание брифов собирают предметные агенты, каждый со своей оптики. Категорийному менеджеру готовит выжимку [агент промо](/03-agents/#1-агент-промо), прайс-менеджеру [агент ценообразования и конкурентного мониторинга](/03-agents/#10-агент-ценообразования-и-конкурентного-мониторинга), руководителю промо [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта). Follow-up после встречи, когда договорённости превращаются в задачи, на старте тоже остаётся за Напарником.
Вся эта содержательная обвязка (бриф до встречи, фиксация договорённостей во время, задачи после) и есть будущая зона [агента встреч и follow-up](/03-agents/#8-агент-встреч-и-follow-up). В стартовой сборке отдельного такого агента ещё нет, его работу закрывают скиллы Напарника. Полноценным агентом с расшифровками встреч и таск-трекером он становится на следующем шаге.
Главное действующее лицо здесь не отдельный агент, а само [межнапарниковое взаимодействие](/05-architecture/#межнапарниковая-коммуникация-a2a). По сути этот сценарий показывает, как четвёртая эпоха проявляется в самой обыденной операции, в постановке встречи трёх человек.
### Какие данные используются
Главный набор данных составляют календари трёх сотрудников и корпоративный мессенджер, на них держится сама механика встречи. Содержание брифов берётся из хранилища (продажи, цены, маржа) и параметров промо-плана, дополняется внешними данными о конкурентах в той части, в какой они подключены. Поверх всего лежит личная память каждого Напарника со своими хранимыми мелочами, такими как предпочтения сотрудника по слотам, привычный стиль брифа, чувствительные темы, которые лучше не выносить в общий чат.
### Какие решения принимаются
Самое крупное решение касается того, включать ли линейку в летнее промо. Если включать, то решаются формат акции, дата старта и источник бюджета (а это, как правило, перенос денег с другой акции, которую решили в этом году не повторять). Параллельно фиксируется список последующих действий с конкретными ответственными, без него встреча превращается в обмен мнениями.
### Где нужен human-in-the-loop
Согласование слотов идёт по сути без участия людей. Напарники договариваются между собой и приходят к сотрудникам уже с готовым предложением, которое можно скорректировать. Постановка любых задач проходит через явное подтверждение того, кто их получает. Любая внешняя коммуникация (письмо в маркетинг, запрос поставщику) идёт через клик человека.
### Ожидаемый бизнес-эффект
На метриках это видно сразу с нескольких сторон. Сокращается время между «возникла потребность во встрече» и «встреча состоялась», растёт доля встреч с подготовленной заранее повесткой, становится меньше повторных встреч *«давайте вернёмся через неделю»*. На стороне ощущений короче и чище становятся сами рабочие процессы. Менеджеры тратят меньше внимания на координационный шум и больше на содержание.
### Метрики успеха
Самая операционная метрика это время на постановку межфункциональной встречи. Оно должно перейти из «несколько перепалок и пара рабочих часов трёх человек» в минуты. Дальше работает доля встреч с автоматически сформированной повесткой и брифом, а также доля договорённостей, превратившихся в задачи в течение часа после встречи. О том же говорит число повторных встреч на ту же тему. В текущем процессе их много, в новом становится заметно меньше.
---
## Backlog сценариев
Эти сценарии в первой версии концепта описаны кратко. Они появятся в виде подробных разделов, когда станет понятно, что под них есть конкретный заказчик и конкретный пилот.
### День категорийного менеджера
Не аналитический сценарий, а сюжетный. Один полный рабочий день человека с Напарником, от утреннего брифинга до вечернего проактивного разбора в фоне. Полезен на демо как обобщающая иллюстрация, в которой все остальные сценарии встречаются маленькими фрагментами. Заметка для будущей детализации лежит в [02-partner, раздел «Рабочий день, в котором Напарник работает сам»](/02-partner/#рабочий-день-в-котором-напарник-работает-сам), там уже есть рабочий каркас.
### Подготовка к ассортиментному комитету
Раз в квартал категорийный менеджер защищает изменения в матрице. Сценарий объединяет работу нескольких агентов, среди них ассортимент, финансовый эффект, ценообразование и конкурентный мониторинг, факторный анализ. Похож на разбор продаж, но горизонт длиннее и решения тяжелее. Листинг и делистинг относятся к необратимым шагам, и здесь особенно важна [Tier 2](/05-architecture/#tier-модель-автономии) граница автономии.
### Кризисная ситуация
Сюда попадают срыв поставки, пожар на РЦ, проблема с регуляторикой по группе SKU. Общая черта в том, что внутренний таймер сжат до часов. Здесь хорошо видно ценность проактивного агента алертов и сценарий «9:00, утром в мессенджере уже забронирован антикризисный звонок», описанный в исходных материалах концепта. Подробное описание появится, когда станет понятно, какие именно типы кризисов наиболее частые у конкретного заказчика.
### Онбординг нового менеджера
Когда сильный категорийщик уходит, новый человек первые недели восстанавливает картину по обрывкам. Платформа меняет это. Личная память Напарника предшественника не передаётся напрямую (это было бы небезопасно), но коллективная память и базы знаний открывают новому менеджеру доступ к проверенным паттернам с первого дня. Сценарий привязан к зрелости коллективной памяти и куратора, поэтому подробное описание разумно делать на втором-третьем этапе внедрения.
### Подготовка управленческого summary
Руководитель направления или коммерческий директор регулярно просит сводку по портфелю. Сегодня это *«соберите мне отчёт к понедельнику»* с задействованием десятка людей. С платформой Напарник руководителя обращается к Напарникам категорийщиков, те собирают данные, валидируют их у своих сотрудников и возвращают. Это сценарий вертикальной агрегации, и в нём особенно важна управляемость прав, кто и что может запрашивать.
### Поиск и распространение лучших практик
Удачная тактика переговоров одного менеджера, нестандартная диагностика OOS у другого, успешный формат промо у третьего. Сегодня всё это остаётся в личной голове. Сценарий описывает, как Напарники и куратор организационной памяти превращают такой опыт в общий ресурс команды. Сильно зависит от наличия куратора в роли и от готовности заказчика инвестировать в коллективную память. Подробное описание появится в более поздних версиях концепта.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Эффект-цифры взяты из индустрии, а не измерены у заказчика]
Опорные числа сценариев это внешние индустриальные оценки и наблюдения практиков, а не замеры в контуре конкретной сети. Рост доли подготовленных досье с 20% до 90% это наша экспертная оценка, опубликованного источника под ней нет. Цифра 59–72% неокупаемых промо опирается на Nielsen (мир, 2014 год) и на McKinsey с данными Nielsen по США. Потери около 4% продаж от OOS идут из исследования Corsten и Gruen (GMA, 2002 год). Более свежие замеры (Circana по промо за 2023 и 2024 годы, NielsenIQ по пустым полкам за 2021 год) подтверждают направление, но часть из них завышена пандемийными перебоями поставок, поэтому за базовые мы берём прежние бенчмарки. На пресейле эти числа нужно подавать как ориентир и порядок величины, а не как обещание. Честная защита требует отдельно проговорить, на каких допущениях держится оценка, и заранее договориться, как тот же показатель будет замеряться в пилоте.
:::
:::caution[Реалтайм-подсказки на переговорах]
В сценарии 1 Напарник подсказывает менеджеру в боковой канал прямо во время встречи. Технически это самый недоказанный элемент. Непонятны допустимая латентность, способ незаметной доставки подсказки, поведение при онлайн- и офлайн-встрече, а также приватность (запись и расшифровка живого разговора с внешним участником поднимает юридический вопрос). Сценарий уже опирается на эту механику, хотя её осуществимость на стороне заказчика ещё предстоит подтвердить.
:::
:::caution[Надёжность контрфактических расчётов]
Ответы вида *«что было бы, если бы не было проблемы с холодильниками»* (сценарий 2) и пересчёт ROI при снятии двух акций (сценарий 3) полностью зависят от качества модели атрибуции факторов. Риск в том, что платформа уверенно назовёт ошибочный фактор главным, а менеджер примет это за факт и пойдёт с этим на планёрку. Где проходит граница между обоснованным расчётом и правдоподобной выдумкой и как помечать неуверенность, концепт пока не фиксирует.
:::
:::caution[Сценарий 5 предполагает зрелость Эпохи 4]
Межфункциональная встреча через Напарников работает только при условии, что у всех участников уже есть свой Напарник и между ними включён [A2A-обмен](/05-architecture/#межнапарниковая-коммуникация-a2a) по согласованной политике. На ранних этапах внедрения, когда платформа развёрнута на нескольких добровольцах, этот сценарий невоспроизводим в полном виде. Его стоит показывать как целевую картину, а не как то, что заработает в первом пилоте.
:::
---
# Архитектура, безопасность, управление
> Логическая архитектура корпоративной мультиагентной ИИ-платформы для Retail: карта архитектуры, оркестрация агентов, память и контекст, инструменты, скиллы, команды, безопасность, управление, наблюдаемость и варианты развёртывания.
Источник: https://ai-partner-ru.chvanov.com/raw/05-architecture.mdx
Документ описывает логическую архитектуру платформы. Из каких блоков она состоит, как агенты взаимодействуют друг с другом, как устроена память и контекст, где проходят границы доверия и как организованы управление, аудит и наблюдаемость.
## Из этого раздела вы узнаете
- какие архитектурные принципы прошиты в конструкцию платформы и из каких блоков она собрана
- как устроены инструменты, скиллы, команды и workflow и что даёт семантический слой данных
- как Напарник оркеструет функциональных агентов, что такое субагенты и как работает коммуникация между агентами(A2A)
- как устроены память и контекст и где проходит граница автономии (Human-in-the-loop, Tier-модель)
- как реализованы безопасность, управление, аудит, наблюдаемость и какие есть варианты развёртывания
---
## Коротко
Платформу удобно представлять как несколько блоков с разной природой и ролью. Наверху находятся сотрудники, которые разговаривают со своими ИИ-Напарниками через корпоративный мессенджер. Под ними работают агенты. Персональные Напарники координируют работу, а функциональные агенты её выполняют, а у каждого агента свой набор инструментов и своя область данных, а права доступа ограничивают, что именно он может с ними делать. Агенты оснащены инструментами, скиллами и памятью и дотягиваются до корпоративных данных через управляемые коннекторы, не перенося данные в свой периметр. Всё это пронизывает сквозной контур безопасности, аудита и управления, который работает на уровне платформы, а не на уровне инструкций модели.
Главная идея архитектуры в том, что безопасность и контроль встроены в саму конструкцию платформы. Агент получает только те инструменты, которые ему явно выданы. Данные менеджера A недоступны Напарнику менеджера B. Критические действия проходят через подтверждение человека. Платформа логирует и аудирует каждое действие каждого агента. Эти свойства не зависят от того, что написано в инструкциях модели, потому что они реализованы на уровне платформы.
:::tip[Главный тезис документа]
Безопасность и контроль вшиты в конструкцию платформы, а не в инструкции модели. Инструментальные политики, [Tier-модель автономии](#tier-модель-автономии) и сквозной аудит работают на уровне платформы.
:::
---
## Архитектурные принципы
Эти принципы прошиты в саму конструкцию платформы. Они работают как ограничения при проектировании новых агентов, интеграций и сценариев. Если конкретное архитектурное решение противоречит любому из них, нужно либо найти другой способ, либо сознательно зафиксировать исключение и его обоснование.
Новый агент по умолчанию не умеет ничего. Каждое право (чтение данных, запись, отправка сообщений, обращение к другим агентам) выдаётся явно. Это принцип наименьших привилегий. Агент видит только то, что ему нужно для работы, и ничего больше.
Данные одного сотрудника недоступны Напарнику другого, кроме случаев явной межагентской коммуникации по управляемой политике. Сессии, память, файлы и учётные данные изолированы на уровне агента и сессии.
Инструментальные политики (какие инструменты доступны агенту), Tier-модель автономии (какие действия требуют подтверждения человека) и правила межагентского взаимодействия (кто кому может писать) работают на уровне платформы. Никакая модификация промпта не может их обойти.
Платформа логирует каждый ход (turn) каждого агента. Каждое обращение к данным несёт ссылку на источник. Любое действие любого агента можно воспроизвести по журналу. Журнал аудита встроен в архитектуру и ведётся всегда.
LLM-провайдер, агентный runtime, мессенджер, хранилище данных, MCP-коннекторы рассматриваются как заменяемые компоненты. Конкретные компоненты выбирают под ИТ-политику и инфраструктуру заказчика. Архитектура не завязана на единственного вендора.
Платформа проектируется так, чтобы можно было начать с минимального контура (один Напарник, два-три функциональных агента, одна интеграция) и наращивать без перестройки. Добавление нового агента, нового коннектора или нового Напарника это операция конфигурации, а не проект архитектурной переработки.
---
## Карта архитектуры
Платформа собирается из нескольких блоков.
Люди и канал. Сотрудник общается с платформой через корпоративный мессенджер с мобильной и десктопной версиями (Telegram, MAX, eXpress, Mattermost или другой инструмент, допустимый ИТ-политикой заказчика). Мессенджер остаётся основным каналом, потому что менеджер и без платформы проводит в нём значительную часть дня, и порог входа стремится к нулю. Через тот же канал приходят уведомления о действиях, инициированных Напарником и другими агентами. Когда Напарник коллеги попросил собрать статусы по промо или согласовал слот для встречи, в мессенджере появляется короткое сообщение о том, что произошло и где требуется явное подтверждение сотрудника. У каждого сотрудника свой бот (или DM-канал), и все сообщения из него маршрутизируются к его персональному Напарнику. Веб-интерфейс и дашборды добавляются позже, под сценарии с длинными аналитическими артефактами, а голосовой канал рассматривается отдельно в [04-usecases](/04-usecases). Конкретный механизм маршрутизации собирается под заказчика и вынесен в [Backlog как routing topology](#backlog-детализации-архитектуры).
Агенты. Напарник и функциональный агент образуют две роли одной и той же архитектурной сущности. Напарник персональный и координирует работу, функциональный агент же специализирован на исполнении узкого класса задач. Оркестрация описывает, как Напарник вызывает функциональных агентов и связывается с Напарниками коллег, и подробно разобрана в разделах [«Модель взаимодействия агентов»](#модель-взаимодействия-агентов) и [«Оркестрация задач»](#оркестрация-задач).
Оснащение агентов. Помимо генерации текста агент пользуется инструментами (поверхность действий), скиллами (инструкции, как этими инструментами пользоваться), памятью (личная, корпоративная, коллективная) и командами с workflow. Это экипировка агента, и она разобрана в разделах [«Инструменты агентов»](#инструменты-агентов), [«Скиллы»](#скиллы), [«Команды и workflow»](#команды-и-workflow) и [«Память и контекст»](#память-и-контекст).
Данные и путь к ним. Корпоративные системы (DWH, BI, ERP, WMS, CRM, почта, календарь, внешние источники) остаются на месте, а агенты дотягиваются до них через интеграционный контур из MCP-коннекторов, API, RAG и event-шин. Данные не покидают периметр, в котором они были. Эта часть разобрана в разделах [«Данные»](#данные), [«Семантический слой данных»](#семантический-слой-данных), [«Интеграции»](#интеграции) и подробно в [06-integrations](/06-integrations).
Контур безопасности и контроля пронизывает все остальные блоки и работает на уровне платформы, а не инструкций модели. В него входят инструментальные политики, Tier-модель автономии, аудит, управление и наблюдаемость. Разобран в разделах [«Безопасность и права доступа»](#безопасность-и-права-доступа) и [«Управление мультиагентной средой»](#управление-мультиагентной-средой).
---
## Агенты
Каждый сотрудник работает с одним персональным Напарником. Это полноценный изолированный агент со своей рабочей директорией, своей памятью, своими учётными данными и своей историей сессий. С точки зрения архитектуры у Напарника есть рабочая директория с файлами личности (инструкции по роли и зоне ответственности, профиль сотрудника, стиль коммуникации, оперативная память), хранилище сессий, изолированные учётные данные (профили доступа к корпоративным системам в рамках прав конкретного сотрудника) и набор инструментов для оркестрации, межагентской коммуникации, работы с памятью, уведомлений и расписания. Пользовательская модель Напарника подробно описана в [02-partner](/02-partner).
Напарник не имеет прямого доступа к корпоративному хранилищу. Все обращения к данным идут через функциональных агентов, у каждого из которых свои ограничения. Так устроена граница безопасности. Раз у Напарника нет инструмента для прямого запроса, он оркеструет, но сам по себе не может написать произвольный SQL или прочитать произвольную таблицу.
Функциональный агент это специализированный исполнитель, и каждый закрывает свой класс задач, будь то факторный анализ, Text2SQL, поиск по регламентам, подготовка досье на поставщика или мониторинг аномалий. В архитектурном плане это отдельная сущность со своей рабочей директорией, своей инструментальной политикой и своим набором доступных данных. Один экземпляр функционального агента используется всеми Напарниками в системе, но каждый вызов изолирован в отдельной сессии, и контексты разных вызовов не пересекаются. Подробный каталог агентов и принципы их проектирования описаны в [03-agents](/03-agents).
---
## Модель взаимодействия агентов
Агенты в платформе взаимодействуют по нескольким типовым паттернам. Каждый паттерн решает свой класс задач и имеет свои правила безопасности.
### Делегирование
Основной паттерн. К Напарнику приходит ситуация от сотрудника, и он делегирует её функциональному агенту (или нескольким). Каждую делегированную задачу Напарник запускает в изолированной сессии. Агент берёт конкретное задание с параметрами, работает асинхронно, возвращает результат.
Когда ситуация требует нескольких агентов, Напарник запускает их параллельно и затем дожидается результатов от всех запущенных задач, прежде чем продолжить. После получения всех ответов Напарник синтезирует итог для сотрудника.
```
Сотрудник: *«Почему упала молочка в Сибири?»*
│
Напарник
│
├── → Агент факторного анализа (период, регион, категория) ── параллельно
├── → Агент OOS (SLA, поставки) ── параллельно
│ [ждём оба результата]
└── ← Результаты: факторная карточка + данные по SLA
│
└── → Синтез + следующий шаг → сотруднику
```
Для подготовки к переговорам Напарник может запустить четыре-пять агентов одновременно.
```
Напарник (подготовка к переговорам)
│
├── → Агент переговоров (досье поставщика) ── параллельно
├── → Агент финансового эффекта (сценарии) ── параллельно
├── → Агент OOS (SLA и недопоставки) ── параллельно
├── → Агент базы знаний (прецеденты) ── параллельно
│ [ждём все четыре результата]
└── ← Четыре результата → синтез → сотруднику
```
Платформа ограничивает максимальное количество параллельных задач на одного Напарника и глобально. Обычно это до пяти задач на одного Напарника и до десяти глобально. Благодаря этому лимиту платформа удерживает число задач от неконтролируемого роста и бережёт бюджет токенов.
Ключевое свойство делегирования это изоляция контекстов вызовов. Агент факторного анализа, вызванный Напарником менеджера A, не видит контекст вызова от Напарника менеджера B. Это обеспечивается тем, что каждый вызов порождает отдельную сессию со своим ключом.
### Механики вызова функциональных агентов
Напарник может задействовать функционального агента двумя способами. Способ выбирают архитектурно при проектировании конкретного агента, а не на каждом вызове.
**Вариант A. Субагент.** Субагент это технический способ запустить агента в одноразовой изолированной сессии. Это механизм исполнения, а не отдельный класс сущностей рядом с Напарником и функциональными агентами. Когда Напарнику нужен функциональный агент для разовой задачи (факторный разбор, подготовка досье, расчёт финансового эффекта), платформа порождает субагент с профилем нужного агента. Ему дают ту же инструментальную политику и тот же набор инструкций, что и постоянному экземпляру, но живёт он ровно столько, сколько нужно для одного задания, а после завершения возвращает результат инициатору и автоматически архивируется.
Субагент работает в урезанном контексте. Он не наследует личность инициатора и историю его диалогов, только задание и рабочие инструкции. Это намеренное ограничение. Субагент должен качественно закрыть свою предметную задачу, а не вести диалог. Форма удобна там, где важны изоляция и предсказуемая стоимость. Каждый разовый разбор это отдельный контекст, и он не загрязняет историю предыдущих вызовов. Параллельная оркестрация (Напарник запускает несколько субагентов одновременно для разных частей одной ситуации) тоже хорошо ложится на эту форму. Для субагентов как правило используется более экономичная языковая модель, поскольку их задачи обычно хорошо определены и не требуют сложных рассуждений.
**Вариант B. Постоянный агент.** Напарник отправляет сообщение в постоянную сессию функционального агента, и тот отвечает в контексте своей накопленной истории. Этот вариант нужен агентам с собственным состоянием. Например, агент алертов хранит историю аномалий, а агент коллективной памяти накапливает знания команды. Их важно вызывать как постоянные сессии, а не пересоздавать при каждом обращении.
### Многоуровневая оркестрация
Для сложных задач платформа поддерживает иерархию глубиной два. Напарник порождает агента-оркестратора, который сам может запускать агентов-исполнителей. Результаты поднимаются обратно по цепочке. Исполнитель передаёт оркестратору, оркестратор Напарнику, а Напарник сотруднику.
Глубина вложенности ограничена платформой (типично максимум два уровня). Это сознательное решение. Глубокая иерархия создаёт проблемы с наблюдаемостью и контролем бюджета, а на практике двух уровней хватает для подавляющего большинства задач.
### Межнапарниковая коммуникация (A2A)
Напарники разных сотрудников могут обращаться друг к другу с конкретными запросами. Это управляется через явный белый список на уровне платформы.
```
Напарник менеджера A: *«Собери статусы по промо у коллег»*
│
├── → Напарник менеджера B: *«Статус промо Q2 по кондитерке?»*
├── → Напарник менеджера C: *«Статус промо Q2 по молочке?»*
│
├── ← Напарник B: *«Акция запущена, ROI +12%, каннибализация 8%»*
├── ← Напарник C: *«Акция перенесена на июль, бюджет утверждён»*
│
└── Синтез → менеджеру A
```
A2A-коммуникация по умолчанию выключена. Включается явно и содержит белый список допустимых пар. Функциональные агенты в A2A-список не входят. Они работают только через делегирование от Напарника.
Та же механика используется для согласования совместных действий, а не только для запроса данных. Например, при постановке межфункциональной встречи Напарник инициатора обращается к Напарникам приглашённых, те проверяют у своих сотрудников предпочтения по слотам и накладывают свободные окна в календаре, между собой согласуют общий слот, ставят встречу и каждый готовит своему сотруднику бриф под её повестку. Со стороны людей это выглядит как одно сообщение *«договорились на четверг 15:00»*, без переписки на троих и без человеческой обвязки. Подробный сюжет такого сценария разобран в [04-usecases, раздел «Межфункциональная встреча через Напарников»](/04-usecases/#сценарий-5-межфункциональная-встреча-через-напарников). Архитектурно он реализуется на тех же механизмах, что описаны выше. A2A работает по белому списку допустимых пар, календарь подключён как инструмент с правом на чтение и бронирование, а постановку встречи в свой календарь каждый сотрудник подтверждает явно.
### Проактивный цикл
Часть работы выполняется без запроса от сотрудника. Планировщик по расписанию запускает агентов мониторинга. В их числе агенты алертов, аномалий и контроля договорённостей. При обнаружении значимого события агент передаёт результат Напарнику соответствующего сотрудника, и тот формулирует уведомление.
```
[Планировщик, каждые 2 часа]
│
Агент алертов
├── Запрос аномалий в хранилище
├── Проверка входящей почты
│
├── Обнаружена аномалия: -15% по кондитерке
│ └── → Напарник менеджера: *«⚠️ Аномалия: ...»*
│
└── Обнаружено письмо: срыв поставки
└── → Напарник менеджера: *«🔴 Критично: ...»*
```
Поддерживаются одноразовые запуски (по абсолютному времени), периодические (через интервал) и классические календарные расписания (день недели, число месяца, время).
Сессия в контексте работы агента это контейнер для одного диалога, аналог ветки переписки. Напарник всегда работает в своей основной сессии, и это его «домашний» диалог с сотрудником. Задачи, запущенные по расписанию, могут выполняться в новых изолированных сессиях или передавать результаты прямо в основную сессию Напарника, в зависимости от настройки.
### Изоляция контекстов
Каждый порождённый агент работает в изолированной сессии. Он получает конкретное задание с параметрами, доступ к инструментам в рамках своей инструментальной политики и рабочие инструкции (роль, специализация, формат ответа).
Он не получает историю диалога сотрудника с Напарником, данные других сотрудников, инструменты не предусмотренные его политикой и возможность порождать собственных агентов (кроме случаев многоуровневой оркестрации с явным разрешением).
Это свойство критично для безопасности. Функциональный агент не видит ничего лишнего, даже если модель, стоящая за ним, теоретически может интерпретировать более широкий контекст.
---
### Оркестрация задач
Любая задача в платформе проходит через стандартный жизненный цикл.
1. **Инициация.** Сотрудник формулирует ситуацию, или триггер (алерт, расписание, событие) запускает задачу автоматически.
2. **Маршрутизация.** Напарник определяет, какие функциональные агенты нужны, формулирует задание для каждого с конкретными параметрами.
3. **Делегирование.** Напарник порождает изолированные сессии для функциональных агентов. Агенты работают параллельно или последовательно, в зависимости от зависимостей между задачами.
4. **Исполнение.** Каждый функциональный агент выполняет свою работу. Он обращается к данным, считает, ищет, формирует структурированный ответ.
5. **Синтез.** Напарник получает результаты всех агентов и собирает единый ответ для сотрудника. Это именно синтез. Один главный вывод с доказательной базой под ним, и завершается он предложением следующего шага, но не склейкой отдельных отчётов.
6. **Доставка.** Результат возвращается сотруднику в мессенджер. Если требуется действие (отправка письма, постановка задачи), Напарник предлагает его и ждёт подтверждения.
7. **Обратная связь.** Сотрудник может пометить результат как верный или неверный, уточнить или дополнить. Напарник запоминает поправку и учитывает её в следующий раз.
---
## Инструменты агентов
Инструменты охватывают всё, что агент может делать помимо генерации текста. Каждый инструмент соответствует конкретному действию (прочитать файл, выполнить запрос к базе данных, отправить сообщение, запустить субагента). Агент получает только те инструменты, которые ему разрешены через инструментальную политику.
Инструменты делятся на встроенные (доступны сразу при создании агента) и плагинные (устанавливаются дополнительно под конкретные задачи).
В контексте retail-платформы инструменты делятся на следующие группы.
- работа с данными - чтение из корпоративных систем. Основной канал в подавляющем большинстве сценариев это запросы к DWH. Прямые обращения к API ERP, WMS и другим бизнес-критичным системам возможны, но это исключение под конкретный сценарий, где задержка выгрузки в хранилище принципиально мешает работе. Сюда же относится поиск по RAG-индексу корпоративной базы знаний. Большинство аналитических агентов работают только с этой группой;
- файловая работа и память - чтение и запись файлов в рабочей директории агента, семантический поиск и чтение из памяти. Используются Напарниками для хранения заметок, профилей контрагентов и истории решений;
- оркестрация - порождение субагентов, отправка сообщений другим агентам, просмотр истории сессий, ожидание результатов от параллельных задач. Основная группа инструментов для Напарников;
- исполнение кода - запуск произвольных команд и скриптов, управление фоновыми процессами. Используется в Text2SQL агентах и сценариях с вычислениями;
- веб - поиск и чтение веб-страниц. Актуально для агентов мониторинга внешней среды, например новости о поставщиках, цены конкурентов, публичные отчёты;
- обмен сообщениями - отправка сообщений во все подключённые каналы. Используется агентами алертов для уведомления Напарников;
- медиа и интерфейсы - анализ изображений, генерация визуальных материалов, управление браузером для автоматизации веб-интерфейсов. Подключаются дополнительно под специализированные сценарии;
- планирование и управление платформой - запуск задач по расписанию, управление конфигурацией платформы. Доступны служебным агентам с соответствующими правами.
Каждый агент в каталоге ([03-agents](/03-agents)) получает строго ограниченный набор инструментов. Аналитический агент работает только с инструментами чтения данных. Напарник добавляет к ним оркестрацию и память, но не получает прямого доступа к DWH.
---
## Скиллы
Скилл (skill) это файл с инструкциями, который платформа автоматически добавляет в системный контекст агента. Скиллы учат агента когда и как использовать инструменты и сервисных агентов, какие форматы ответов предпочтительны в конкретных ситуациях, как интерпретировать специфические данные или ситуации.
В retail-платформе скиллы быстро становятся одним из главных способов передачи знания между агентами и сотрудниками. Несколько примеров, которые уже работают в демо-контуре Напарника.
Напарник готовит досье к переговорам, оркеструя сразу несколько сервисных агентов. Text2SQL отвечает за коммерческие срезы поставщика, агент базы знаний за прецеденты, агент финансового эффекта за сценарии уступок. Ответы складываются в стандартное досье. По сути это и есть бизнес-агент, у которого нет собственного цикла рассуждений, а есть устойчивый порядок вызова сервисных агентов.
Напарник ведёт и по запросу собирает карточки поставщиков, контактных лиц и коллег. В карточку входят доля в категории, история контрактов и поставок, контактные лица, чувствительные темы и предпочитаемый формат общения. Удобно при подготовке к встрече или передаче ведения переговоров другому менеджеру.
Напарник разбирает входящую почту, готовит черновики ответов, ищет свободный слот и ставит встречу. Отправка письма и постановка встречи с внешним участником идут под [Tier 2](#tier-модель-автономии), то есть с явным подтверждением сотрудника.
Скилл «Как считать каннибализацию промо» фиксирует формулу, перечень источников и правила интерпретации. Один и тот же скилл использует и агент промо, и агент финансового эффекта. Раньше методология жила в головах двух-трёх аналитиков, после оформления в скилл стала общей.
Задаёт агенту мониторинга порядок обхода категории сверху вниз по множеству разрезов (регион, формат, поставщик, ценовой сегмент), правила отбора значимых отклонений и формат итоговой карточки с графиками. Благодаря этому скиллу разбор воспроизводим от запуска к запуску.
Жизненный цикл скилла напоминает жизненный цикл агента. Сначала паттерн появляется в работе одного агента или Напарника как удачное решение. Дальше его описывают и оформляют как скилл, а если он воспроизводим и применим шире, после валидации куратора его делают доступным всему каталогу. Это один из главных механизмов накопления коллективной экспертизы, и он подробно разобран в разделе [«Память и контекст»](#память-и-контекст).
Отдельный методологический вопрос, где проходит граница «агент или скилл» разобран в [03-agents, раздел «Когда агент, а когда скилл Напарника»](/03-agents/#когда-агент-а-когда-скилл-напарника).
---
## Команды и workflow
Основная модель взаимодействия с Напарником остаётся диалоговой. Сотрудник пишет обычным языком, Напарник распознаёт ситуацию и собирает ответ. Так живут все сценарии в [04-usecases](/04-usecases) и пользовательская модель в [02-partner](/02-partner). Поверх диалога платформа поддерживает два дополнительных механизма для повторяющихся операций, у которых уже сложилась устойчивая форма.
Текстовые команды начинаются с `/` и обрабатываются платформой напрямую, минуя языковую модель. Они работают мгновенно и не расходуют токены. Например, `/статус` показывает активные задачи Напарника, `/брифинг` генерирует утренний обзор, `/переговоры Saverio` запускает сбор досье по конкретному поставщику. Это удобно для операций, которые менеджер делает каждое утро или несколько раз в день. Команды никогда не заменяют диалог. Если у сотрудника есть нестандартный вопрос, он формулирует его обычным языком, как и раньше.
Программируемые workflow позволяют описать многошаговый процесс как детерминированную последовательность с контрольными точками. Модель здесь идёт по заранее заданному сценарию, свободного диалога с ней нет. Агент выполняет шаги по порядку, в нужных местах останавливается и ждёт подтверждения от сотрудника. Workflow хорошо подходят для стандартных операций, где важна предсказуемость. Например, процедура подготовки к квартальным переговорам включает сбор данных, проверку досье, формирование повестки и финальное согласование с менеджером. Workflow также удобны там, где конкретный сценарий должен исполняться одинаково у всех менеджеров (например, чтобы методология подготовки к ассортиментному комитету не расползалась по людям).
---
## Память и контекст
Память платформы устроена в три слоя с разными правилами доступа, наполнения и жизненного цикла. Корпоративная база знаний хранит формализованное организационное знание под присмотром людей. Личная память Напарника накапливает контекст конкретного сотрудника. Коллективная память сохраняет проверенные паттерны и переносит их между людьми, чтобы опыт сильного менеджера не пропадал с его уходом. Так память закрывает сразу три задачи. Сотрудник получает Напарника, который помнит его контекст, организация получает общий доступ к формализованному знанию, а удачный опыт остаётся в команде даже после ухода человека.
Профили контрагентов и коллег стоят особняком. Они не образуют отдельный слой, а живут сразу в личной и коллективной памяти, поэтому ниже разобраны своим разделом.
Пользовательскую сторону, то есть что из этой памяти видит сам сотрудник, описываем в [02-partner, раздел «Персональный контекст пользователя»](/02-partner/#персональный-контекст-пользователя).
### Корпоративная база знаний
Курируемое людьми хранилище формализованного знания. Сюда входят регламенты, стандарты, переговорные прецеденты, аналитические отчёты и нормативные документы. Этот слой доступен агентам только для чтения. Они могут искать и читать, но не могут вносить изменения напрямую.
Обновления в корпоративную базу знаний вносят ответственные сотрудники. Агент базы знаний обеспечивает поиск по ней (через RAG, семантический поиск или полнотекстовый индекс).
### Личная память Напарника
У каждого Напарника есть собственное хранилище, в котором накапливается контекст конкретного сотрудника. Сюда попадают оперативные заметки (что на столе, какие дедлайны, какие переговоры активны), история решений (что делал в похожих ситуациях, какие поправки вносил к результатам агентов), профили контрагентов и коллег (стиль, чувствительные темы, прецеденты встреч) и предпочтения по коммуникации (как формулирует письма, какую длину ответов предпочитает).
Этот слой привязан к конкретному Напарнику и изолирован от других сотрудников. Когда Напарнику менеджера B нужны данные из контекста менеджера A, это идёт через [межнапарниковую коммуникацию (A2A)](/05-architecture/#межнапарниковая-коммуникация-a2a) с явным разрешением и видимым обменом.
Личная память подчиняется политике хранения. Данные, которые больше не нужны, архивируются или удаляются по расписанию. Политика согласовывается с комплаенсом и зависит от типа данных. Оперативные заметки могут жить 90 дней, история решений хранится год, а профили контрагентов живут, пока существует рабочее отношение.
### Коллективная память
Обезличенные паттерны успешных решений, выявленные на масштабе команды. Сюда попадают проверенные тактики переговоров и удачные диагностики типовых ситуаций. Этот слой не содержит персональных данных и не привязан к конкретному Напарнику.
Наполнение коллективной памяти - деликатная и нетривиальная задача, требующая внимания. Платформа поддерживает три механизма, применимых в зависимости от зрелости организации и чувствительности данных.
Для низкорисковых операционных паттернов (типовые диагностики, форматы отчётов) агент коллективной памяти может искать повторяющиеся паттерны в сессиях разных Напарников, оценивать их по частоте и устойчивости и автоматически выносить в общий слой. Применимо там, где ошибочная публикация паттерна не создаёт коммерческого риска.
Для коммерчески значимых паттернов (тактики переговоров, нестандартные ходы). Агент предлагает кандидатов, человек-куратор валидирует. Куратор здесь есть роль в организации (например, руководитель направления), формально ответственный за качество коллективной памяти. Этот механизм уже работает в сценариях [04-usecases](/04-usecases). Например, успешная переговорная тактика попадает в коллективную память после валидации куратора.
Для регламентов, стратегических решений и прецедентов. Полностью ручное ведение, аналогично корпоративной базе знаний, но с фокусом на паттерны и уроки, а не на формальные документы.
### Профили контрагентов
Как уже сказано, профили поставщиков, контактных лиц и коллег не образуют отдельный слой памяти. Они лежат в личной памяти Напарника и частично выносятся в коллективную. Менеджер A видит поставщика через свои переговоры и свой контекст, менеджер B видит того же поставщика через свои. Склеивать эти наблюдения автоматически было бы ошибкой, потому что у разных менеджеров разный фокус и разный уровень отношений с поставщиком.
Менеджеры могут также строить и поддерживать собственные профили менеджеров, которые становятся доступны Напарникам коллег через механизм A2A. Так сотрудники видят зону ответственности друг друга, текущие приоритеты и предпочитаемые форматы коммуникации. Полезно при подготовке совместных переговоров или при передаче ведения переговоров другому менеджеру.
По мере зрелости платформы становится разумно наводить мост между личным и коллективным. Общие факты (fill rate, история контрактов, публичные данные) выносятся в коллективную память, а субъективные наблюдения (стиль переговоров, эмоциональные триггеры) остаются в личном слое. Этот мост требует отдельной проработки под конкретного заказчика и не включается автоматически.
---
## Данные
Корпоративные данные остаются в корпоративных системах. Платформа не дублирует хранилище, не создаёт собственный Data Lake и не перемещает данные в свой периметр. Вместо этого агенты обращаются к данным через инструменты (MCP-коннекторы, API, RAG), и каждое такое обращение проходит через инструментальную политику.
Это архитектурное решение важно для комплаенса. Данные не покидают тот периметр, в котором они были до появления платформы. Если хранилище стоит on-premise, то и запросы к нему идут on-premise. Если доступ к хранилищу идёт через VPN или корпоративный шлюз, платформа использует тот же маршрут.
Источники данных удобно разделить на четыре группы. У каждой свой темп обновления, свои паттерны доступа и своя роль в работе агентов.
DWH, BI, аналитические витрины, семантические модели. Источник аналитической фактуры. К нему обращаются [Text2SQL](/03-agents/#5-text2sql), [агент факторного анализа](/03-agents/#11-агент-факторного-анализа), [агент промо](/03-agents/#1-агент-промо), [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта). Доступ как правило только для чтения, через коннекторы и семантические модели.
ERP, WMS, TMS, системы ценообразования, промо-планирования, документооборота. Здесь живут поставки, остатки, договоры, цены и фактические даты прихода. На практике агенты редко читают из этих систем напрямую, потому что они бизнес-критичные и к нагрузке на них владельцы относятся ревностно. Основной маршрут идёт через DWH, куда операционные данные регулярно выгружаются. Прямое подключение возможно как исключение под конкретный сценарий, где нужна большая свежесть. Запись в эти системы по умолчанию закрыта и идёт только под [Tier 2](/05-architecture/#tier-модель-автономии).
Корпоративный мессенджер, почта, календарь, таск-трекер. Источник того, что происходит вокруг сотрудника прямо сейчас. К ним обращаются Напарник и агент встреч и сопровождения договорённостей. Чувствительная зона по комплаенсу, потому что здесь часто лежат персональные данные и переписка с внешними контрагентами.
Корпоративная база знаний, регламенты, стандарты, прецеденты, аналитические отчёты, инструкции. Подключаются через RAG-индекс или семантический поиск. К ним обращаются агент базы знаний, агент регламентов, агент переговоров (за прецедентами). Сюда же относятся внешние источники, такие как индексы цен и публичные отчёты.
В реальном внедрении эти группы редко покрываются одинаково. Аналитический слой обычно зрелый, а семантический ещё нет. Операционные системы хорошо описаны, но сложные по правам. Коммуникационный контекст требует отдельной проработки комплаенса. Документы и регламенты часто разбросаны по нескольким системам, и RAG приходится собирать поверх неоднородного хранения. На пресейле от стартовой зрелости конкретной группы зависит, какие сценарии и какие агенты входят в первый этап пилота. Подробный список систем, протоколов и интеграционных паттернов разобран в [06-integrations](/06-integrations).
## Семантический слой данных
Сырые данные из хранилища сами по себе мало полезны агентам без понимания их бизнес-смысла. Агент, который не знает, что `avg_fill_rate_30d` означает средний уровень выполнения заявок за 30 дней в разрезе поставщика, не сможет правильно интерпретировать аномалию в этой метрике.
Семантический слой собирает сразу несколько вещей. Прежде всего это дата-каталог: описание витрин, того, что в них хранится, как связаны таблицы и какие поля для каких задач актуальны. Если такой каталог уже ведётся в хранилище, агенты ходят прямо в него, если нет, платформа держит собственный реестр семантических моделей. Рядом лежит корпоративный словарь. Он закрепляет, что в этой компании понимают под «выполнением заявок», «промо-акцией», «каннибализацией» или «чистым приростом», иначе агенты толкуют одни и те же термины вразнобой. И отдельно прописано, как именно считается каждый основной показатель, с источниками, периодами и правилами отбора, что критично для факторного анализа и Text2SQL.
На практике поддержание семантического слоя в актуальном состоянии вырастает в отдельную операционную задачу. Платформа поддерживает служебных агентов, которые берут эту работу на себя. Агент семантического слоя следит за изменениями в структуре хранилища и обновляет описания витрин. Агент корпоративного словаря помогает вести и пополнять глоссарий. Оба работают как фоновые сервисы и не требуют ручного участия при каждом изменении схемы.
Семантический слой не существует сам по себе, он подключается через тот же интеграционный контур, через который агенты ходят в DWH и BI. На практике это либо отдельный коннектор к корпоративному дата-каталогу (например, DataHub, Amundsen, Atlan), либо собственный реестр платформы, синхронизируемый с источниками. Конкретные интеграционные паттерны и приоритеты подключения семантического слоя в MVP разбираются в [06-integrations](/06-integrations).
## Интеграции
Через интеграционный контур платформа подключается к корпоративным системам по MCP-коннекторам, API и event-шинам. Каждый коннектор подключается один раз и переиспользуется всеми агентами в рамках их инструментальных политик. Например, новый коннектор к WMS добавляют один раз, и все агенты, которым он нужен, получают к нему доступ, без переделки самих агентов. Так каталог интеграций растёт без перестройки платформы. Как этот контур собирается, переиспользуется и эволюционирует, какие протоколы и паттерны применяются и какой минимальный набор интеграций имеет смысл собирать на старте, подробно разобрано в [06-integrations](/06-integrations).
---
## Human-in-the-loop
Граница автономии агентов определяет, какие действия агент выполняет сам, какие требуют подтверждения человека и какие допускаются только после явного разрешения с отдельной санкцией.
### Tier-модель автономии
Сбор данных, анализ, факторный разбор, подготовка черновиков писем, презентаций, досье. Разрешено по умолчанию. Всё, что делается на Tier 1, остаётся внутри платформы и не покидает её.
Отправка черновика по почте, изменение в учётной системе, бронирование встречи с внешним участником, постановка задачи коллеге. Каждое такое действие требует явного подтверждения сотрудника.
Стандартные операции по расписанию или триггеру в заранее согласованных границах. Сюда входят утренние брифинги, контроль договорённостей, рутинные напоминания и стандартное переключение между РЦ при OOS ниже порога. Включается точечно, после периода доверия и согласования с комплаенсом.
### Примеры классификации действий по Tier
| Действие | Tier | Обоснование |
|---|---|---|
| Факторный разбор, аналитика, поиск | 1 | Только чтение, без внешних эффектов |
| Подготовка черновика письма, досье | 1 | Результат остаётся внутри платформы |
| Отправка письма от имени сотрудника | 2 | Внешняя коммуникация, необратимо |
| Изменение данных в ERP/CRM | 2 | Запись в учётную систему |
| Бронирование встречи с внешним участником | 2 | Создаёт обязательство |
| Листинг/делистинг поставщика | 2 | Коммерчески значимое, необратимое |
| Утренний брифинг | 3 | Стандартная операция, согласована |
| Напоминание коллеге о дедлайне | 3 | Внутренняя коммуникация, низкий риск |
| Стандартное переключение РЦ при OOS | 3 | Согласованный сценарий с явными границами |
На пилоте рекомендуется начинать с Tier 1 и точечных Tier 2. Tier 3 включается после наработки доверия, и каждый конкретный Tier 3 сценарий согласовывается с комплаенсом.
### Механизм подтверждения
В корпоративном мессенджере подтверждение реализуется через встроенные кнопки. Агент предлагает действие, показывает его содержание (например, текст письма, параметры задачи, суть изменения) и ждёт нажатия кнопки «Подтвердить» или «Отменить». Без подтверждения действие не выполняется.
Этот механизм работает **на уровне платформы**, но не на уровне инструкций модели. Даже если инструкции модели изменены или обойдены (например, через prompt injection), платформа не позволит выполнить Tier 2 действие без нажатия кнопки человеком.
---
## Безопасность и права доступа
### Доступ к платформе
Аутентификация сотрудника через корпоративную SSO/LDAP или через белый список в мессенджере. Каждый сотрудник может обращаться только к своему Напарнику. Посторонний пользователь не может послать сообщение боту без явного разрешения.
### Инструментальные политики
Инструментальные политики определяют, какие инструменты доступны конкретному агенту. Право пользоваться инструментом ещё не значит пользоваться им без ограничений. Политики настраиваются на нескольких уровнях, и каждый следующий уровень может только сузить набор, но не расширить.
Глобальная политика платформы фиксирует общие ограничения. Например, любая запись в учётные системы идёт под Tier 2 и требует подтверждения человеком. Эти правила не обходит ни одна нижестоящая политика.
Политика провайдера модели уточняет глобальную для конкретного LLM. Бывает, что провайдер требует не передавать определённые типы персональных данных в промпт, и это сужение спускается на все агенты, работающие через этого провайдера.
Политика конкретного агента описывает рабочий минимум прав. Агенту OOS разрешено читать остатки из WMS и видеть статусы поставок. Записывать в WMS, отправлять письма и обращаться к DWH ему не разрешено, потому что в его задаче это не нужно.
Политика субагента ещё уже. Когда Напарник порождает разовый расчёт, субагент получает только то подмножество прав агента, которое нужно для конкретного задания. Остальное обрезается.
Политика песочницы (sandbox) накладывается поверх всего перечисленного для агентов, исполняющих произвольный код. Например, для [Text2SQL](/03-agents/#5-text2sql)-агента, который запускает SQL во внешнем процессе. Sandbox обрезает сетевые вызовы за пределы разрешённого и ограничивает файловую систему рабочей директорией.
| Уровень политики | Кто настраивает | Что задаёт |
|---|---|---|
| Глобальная | Администратор платформы | Базовые ограничения, единые для всех агентов |
| Провайдер модели | Администратор платформы | Уточнения под конкретного LLM-провайдера |
| Агент | Команда внедрения | Рабочий минимум прав конкретного агента |
| Субагент | Платформа автоматически | Подмножество прав агента под задачу |
| Sandbox | Команда внедрения | Изоляция исполнения произвольного кода |
Как эта иерархия проявляется при подключении конкретных коннекторов, разобрано в [06-integrations, раздел «Управление доступом к инструментам»](/06-integrations/#управление-доступом-к-инструментам).
**Типичные политики для разных типов агентов**
| Тип агента | Разрешено | Запрещено |
|---|---|---|
| **Напарник** | Оркестрация, межагентская коммуникация, память, уведомления, расписание | Прямой доступ к DWH, запись в системы, системное администрирование |
| **Аналитический агент** | Чтение данных (DWH, Text2SQL) | Запись, отправка сообщений, межагентская коммуникация, браузер |
| **Агент переговоров** | Чтение данных, поиск по базе знаний | Запись, отправка сообщений, администрирование |
| **Агент алертов** | Чтение данных, отправка уведомлений Напарнику | Запись в системы, браузер, администрирование |
### Песочница (sandbox)
Для функциональных агентов, которые выполняют произвольный код (например, Text2SQL с запуском SQL), платформа поддерживает исполнение в изолированном контейнере. Песочница ограничивает среду выполнения. Агент не может выйти за пределы своего контейнера, прочитать файлы других агентов или обратиться к сервисам, не предусмотренным его политикой.
Режим песочницы настраивается по агенту и по сессии. Типичная конфигурация такова, что Напарники работают без песочницы (им нужен доступ к файлам личности и памяти), а функциональные агенты работают в песочнице.
### Защита от prompt injection
Внешний контент (письма, ответы API, содержимое веб-страниц) оборачивается в XML-теги с пометкой «внешний контент» и предупреждением для модели. Это рекомендательная мера. Она снижает вероятность того, что модель выполнит инструкцию из внешнего содержимого, но не гарантирует этого на 100%.
Основная защита от prompt injection имеет архитектурную природу. Даже если модель интерпретирует внешние данные как инструкцию, инструментальные политики не позволят ей выполнить запрещённое действие. Агент, у которого нет права на запись, не сможет записать, что бы ни стояло во внешнем содержимом.
---
### Аудит и журналирование действий
Платформа полностью логирует каждый ход каждого агента. В журнале фиксируются входящее сообщение (от сотрудника, от другого агента, от планировщика), системный контекст (какие файлы личности были загружены, какие инструменты доступны), каждый вызов инструмента с параметрами и результатом, ответ модели (включая reasoning, если включён) и метрики выполнения (токены, стоимость, время).
Журналы хранятся в структурированном формате (JSONL). Доступ к ним имеет только комплаенс-офицер и администратор платформы. Агенты могут читать историю своих собственных сессий, но не сырые журналы.
Любая цифра, которую возвращает агент, содержит ссылку на источник в корпоративном хранилище. Указываются таблица, период, набор фильтров. Сотрудник может провалиться в источник и проверить. За счёт этого растёт доверие к выводам, и у каждого аналитического вывода есть проверяемая цепочка до источника.
---
### Наблюдаемость и мониторинг
Платформа поддерживает несколько уровней наблюдаемости.
Статус шлюза платформы (gateway), подключённых каналов, активных агентов, очередей задач. Шлюз платформы работает как центральный серверный процесс, который принимает входящие сообщения, маршрутизирует их к агентам, управляет сессиями и контролирует исполнение инструментов. Мониторинг ресурсов охватывает CPU, память, диск и сетевые подключения. Автоматические алерты при сбоях.
Платформа считает по каждому агенту и в агрегате количество ходов, среднее время ответа, число ошибок и расход токенов. Так видно, кто из агентов перегружен, кто простаивает и где растёт стоимость.
Оценки менеджеров по диагностикам (5-балльная шкала), доля уточняющих вопросов, доля результатов, которые менеджер принял без изменений. Это метрики зрелости, по ним калибруется качество каждого агента.
Попытки доступа за пределами разрешённого, нетипичные запросы, аномалии в использовании инструментов. Автоматический мониторинг плюс ручной аудит по расписанию.
---
## Управление мультиагентной средой
Управление платформой отвечает на вопрос о том, кто и как руководит платформой, агентами и правилами их работы.
### Роли управления
Управляет конфигурацией. Добавляет агентов, настраивает инструментальные политики, маршрутизацию, интеграции. Обычно это ИТ-команда заказчика совместно с командой внедрения.
Валидирует паттерны перед публикацией в коллективную память. Обычно это руководитель направления или эксперт, ответственный за методологическое качество базы знаний.
Согласует Tier 3 сценарии (автономные действия по правилам), проверяет политики хранения данных, контролирует доступ к журналу аудита. Обычно это ИТ-безопасность или внутренний аудит.
Определяет, какие сценарии приоритетны, какие метрики отслеживать, какие пороги чувствительности настроить для алертов. Обычно это руководитель функции (коммерческий директор, директор по категориям).
### Жизненный цикл агента
Каждый новый агент в каталоге проходит стандартный цикл, который включает проектирование, разработку, тестирование, пилотирование и вывод в промышленную эксплуатацию.
1. **Проектирование.** Формулировка назначения, определение инструментальной политики, выбор модели, описание формата ответа. Главный артефакт этапа это заполненная карточка агента по шаблону из [03-agents, раздел «Шаблон карточки агента»](/03-agents/#шаблон-карточки-агента). Поля карточки агента одновременно задают и основу технического задания на разработку, и контрольный список для приёмки на следующих этапах.
2. **Разработка.** Создание рабочей директории, написание инструкций, настройка инструментов и коннекторов. Тестирование на исторических данных.
3. **Пилотирование.** Ограниченное внедрение у нескольких Напарников. Обратная связь от менеджеров, калибровка качества.
4. **Промышленная эксплуатация.** Добавление в общий каталог, доступ для всех Напарников. Мониторинг метрик качества, регулярный пересмотр инструментальной политики.
5. **Эволюция.** Обновление по обратной связи, расширение источников данных, уточнение инструкций. Агент живёт и развивается, а не остаётся в первоначальной конфигурации.
### Управление правилами межагентского взаимодействия
Правила A2A-коммуникации (кто кому может писать и по каким поводам) настраиваются на уровне платформы и пересматриваются при изменении организационной структуры. Например, Напарники менеджеров одного направления могут обращаться друг к другу; Напарник руководителя может запрашивать данные у Напарников его подчинённых; функциональные агенты не участвуют в A2A, только принимают делегирование; агент алертов может отправлять уведомления Напарникам, но не может запрашивать у них информацию.
### Управление стоимостью
Каждый ход агента означает расход токенов LLM. Ход это один полный цикл работы агента. Он включает получение входящего сообщения, его обработку, вызов нужных инструментов и формирование ответа. Платформа поддерживает несколько механизмов контроля стоимости.
- Разные модели для разных ролей снижают стоимость без потери качества. Напарники работают на сильной модели, от неё нужны суждение и синтез под конкретного сотрудника, а функциональные агенты и субагенты могут работать на более экономичной, там нужна надёжность исполнения, а не креативность.
- Тайм-ауты ограничивают каждую делегированную задачу по времени. Если агент не вернул результат за отведённое время, задача прерывается.
- Лимиты параллелизма ограничивают количество одновременных задач и предотвращают неконтролируемый расход.
- Бюджеты задают квоты на агента, на Напарника или на отдел. Опциональная мера, но полезная при масштабировании.
- Обнаружение зацикливания. Платформа отслеживает повторяющиеся вызовы инструментов без прогресса и при отсутствии движения к результату предупреждает или останавливает агента, чтобы не расходовать токены впустую.
---
## Варианты развёртывания
На уровне концепта рассматриваются три модели развёртывания. Модель выбирают под конкретного заказчика, она зависит от ИТ-политики, комплаенс-требований, бюджета и стратегических предпочтений.
**Данные on-premise, LLM через корпоративный шлюз.**
Шлюз платформы (gateway, внутренний серверный процесс) и все данные размещаются на инфраструктуре заказчика (on-premise или в корпоративном облаке). Обращения к LLM-провайдеру идут через корпоративный LLM-шлюз (API-шлюз к внешнему провайдеру) с шифрованием, аутентификацией и логированием.
Данные не покидают периметр. Лучшее качество моделей (доступ к ведущим LLM) и быстрый старт без развёртывания локальных моделей. Ограничения связаны с зависимостью от внешнего LLM-провайдера, потому что промпты и ответы проходят через внешний API (хотя данные остаются в запросах агентов, а не передаются напрямую).
Подходит там, где заказчик допускает использование внешних LLM-сервисов через корпоративный шлюз и комплаенс разрешает передачу промптов наружу при условии шифрования и обезличивания.
**Всё на инфраструктуре заказчика, включая модели.**
Шлюз, данные и LLM-модели размещаются внутри корпоративного периметра. Модели запускаются на собственном оборудовании или на выделенных серверах в корпоративном ЦОД.
Полный контроль. Ничего не покидает периметр. Соответствие самым строгим комплаенс-требованиям. Но требуются вычислительные ресурсы для LLM (GPU-серверы), качество локальных моделей может уступать ведущим провайдерам, и эксплуатация обходится дороже.
Подходит там, где заказчик категорически не допускает передачу любых данных наружу и у него есть собственные GPU-ресурсы или готовность их приобрести.
**Данные и модели в российском облачном сервисе.**
Использование российских LLM-провайдеров (например, YandexGPT или GigaChat) и российской облачной инфраструктуры. Данные остаются в российской юрисдикции.
Вариант обеспечивает соответствие требованиям по локализации данных и снимает зависимость от зарубежных провайдеров. Качество моделей пока отличается от ведущих провайдеров, хотя разрыв сокращается, а выбор инструментов экосистемы ограничен.
Подходит там, где заказчик обязан хранить и обрабатывать данные на территории РФ или отдаёт стратегическое предпочтение отечественным решениям.
:::note[Гибридные конфигурации]
На практике чаще всего реализуется гибрид. Например, данные on-premise, основная модель через корпоративный шлюз к Anthropic/OpenAI, а для чувствительных сценариев (персональные данные, финансовые детали) используется локальная или российская модель. Платформа поддерживает маршрутизацию запросов к разным моделям по типу задачи и уровню чувствительности данных.
:::
---
## Архитектурные ограничения и риски
У реального внедрения есть ограничения и риски.
| Ограничение | Описание | Рекомендация |
|---|---|---|
| **Качество LLM** | Модели ошибаются. Качество факторного анализа, Text2SQL и интерпретации ситуации полностью зависит от качества модели. Галлюцинации остаются проблемой. | Ссылка на источник в каждом факте. Обратная связь от менеджера. Проверка критических выводов человеком. |
| **Prompt injection** | Внешний контент (письма, URL) может содержать инструкции для модели. | Архитектурная защита (инструментальные политики, Tier-модель). XML-обёртки как дополнительная мера. Tier 2 для чувствительных действий. |
| **Стоимость токенов** | Каждый ход агента расходует токены. На масштабе сотни Напарников стоимость может быть значительной, а проработанной модели стоимости с цифрами пока нет. | Механизмы контроля описаны в [«Управлении стоимостью»](#управление-стоимостью). |
| **Латентность** | Параллельная оркестрация нескольких агентов плюс обращения к DWH могут занимать десятки секунд. | Кэширование частых запросов. Упреждающая подготовка (досье готовится до запроса). Прогрев данных. |
| **Зависимость от данных** | Если DWH содержит некачественные или неполные данные, агенты вернут некачественные результаты. | Агент качества данных в каталоге ([03-agents](/03-agents)). Проверка целостности данных перед каждым аналитическим запросом. |
| **Масштабирование** | Один шлюз платформы обрабатывает все запросы. На масштабе сотен одновременных пользователей нужна горизонтальная масштабируемость. | Архитектурная готовность к горизонтальному масштабированию. На пилоте не блокер. |
| **Зрелость организации** | Платформа требует готовности к изменениям, а именно формализации процессов, назначения куратора памяти, согласования Tier-модели. Без организационной поддержки техническое внедрение не даёт полного эффекта. | Организационные условия описаны в [07-roadmap](/07-roadmap). Включаются с Фазы 0. |
---
## Backlog детализации архитектуры
Темы, которые можно вынести в отдельные технические замечания по мере необходимости. На первой версии концепта они не требуют полного описания.
- **Detailed security model.** Полная модель угроз по MITRE ATLAS, матрица рисков, план митигации.
- **Agent runtime specification.** Точная спецификация среды исполнения агента. Охватывает формат рабочей директории, жизненный цикл сессий и механизм hot-reload конфигурации.
- **Memory architecture.** Детальный дизайн трёхслойной памяти с деталями по индексации, поиску, жизненному циклу записей и политикам хранения.
- **Evaluation framework.** Инфраструктура тестирования качества, включая бенчмарки, регрессионные тесты и human evaluation pipeline.
- **Prompt / policy management.** Версионирование, A/B-тестирование, rollback.
- **Deployment topology.** Физическая топология для разных моделей развёртывания. Охватывает сетевую архитектуру, балансировку и отказоустойчивость.
- **Routing topology.** Отдельное замечание по правилам привязки источников к агентам, приоритетам и сценариям с несколькими мессенджерами, группами и общими каналами. Топология собирается под мессенджер и оргструктуру конкретного заказчика.
- **Cost management.** Детальная модель стоимости с прогнозом расхода токенов по сценариям, оптимизацией и мониторингом бюджетов. Базовые механизмы контроля уже описаны в разделе [«Управление стоимостью»](#управление-стоимостью), цифры выносятся под пресейл конкретного заказчика.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Механизм «моста» между личными и коллективными профилями контрагентов]
Личные профили одного и того же поставщика у разных Напарников расходятся, потому что каждый менеджер видит его через свои переговоры и свой уровень отношений. Архитектура предлагает «мост» в коллективную память (общие факты выносятся, субъективные наблюдения остаются личными), но не описывает, как этот мост устроен механически. Какие данные выносятся автоматически, а какие только через куратора; как разрешается конфликт, когда наблюдения двух менеджеров о поставщике прямо противоречат друг другу; как при этом не склеить в общую картину то, что должно остаться приватным. Пользовательская сторона этого вопроса (где вообще должна жить истина по контрагенту) поднята в [02-partner](/02-partner/#персональный-контекст-пользователя); здесь открыт именно механизм консолидации, и он сознательно не включается автоматически.
:::
:::caution[Evaluation framework как замкнутый круг калибровки]
Качество каждого агента (точность факторного анализа, релевантность поиска по базе знаний, корректность Text2SQL, адекватность алертов) нужно измерять системно, иначе калибровка сводится к субъективным оценкам менеджеров по 5-балльной шкале. Но для системной оценки нужна размеченная история решений и эталонные ответы, которых в типовой сети нет, а проверка диагностик (был ли например назван верный главный фактор) требует базы сравнения, которую сама платформа только начинает накапливать. Получается замкнутый круг. Качество нельзя надёжно оценить, пока не накоплена история, а доверять выводам агента нужно с первого дня. Отдельной инфраструктуры тестирования, бенчмарков и оценок в первой версии концепта нет, и на каком объёме данных она становится осмысленной, остаётся открытым вопросом.
:::
:::caution[Граница «у Напарника нет прямого доступа к DWH» защищает слабее, чем кажется]
Архитектура объявляет главной границей безопасности отсутствие у Напарника инструмента прямого запроса к хранилищу. Но функциональные агенты в сумме покрывают почти все данные, а оркестрация Напарником разрешена по определению. Скомпрометированный или подвергшийся prompt injection Напарник не пишет SQL сам, зато может последовательно выдёргивать нужные срезы через делегирование. То есть граница ограничивает прямой произвольный запрос, но не суммарную досягаемость данных. Где здесь проходит реальный, а не декларативный периметр и нужны ли ограничения на сами цепочки делегирования, концепт пока не отвечает.
:::
:::caution[A2A-белый список не масштабируется как механизм управления]
Коммуникация между Напарниками управляется явным белым списком допустимых пар «кто кому может писать». На десятках Напарников число потенциальных пар растёт квадратично, а сам список привязан к организационной структуре, которая постоянно меняется (переходы, реорганизации, временные проекты). Ручное ведение такой матрицы быстро отстаёт от реальности, а её устаревание ломает либо сценарии (запрет нужного обмена), либо безопасность (разрешённый, но уже неуместный обмен). Перехода от попарного списка к ролевой или атрибутной модели доступа документ пока не описывает.
:::
:::caution[Prompt injection]
Prompt injection остаётся открытой проблемой индустрии. Ни одна из существующих мер (XML-обёртки, системные инструкции, fine-tuning) не даёт стопроцентной защиты. Архитектурный подход платформы (инструментальные политики плюс Tier-модель плюс sandbox) значительно сужает поверхность атаки, но не устраняет её полностью. Для действий с высоким потенциальным ущербом единственная надёжная защита состоит в подтверждении человеком (Tier 2).
:::
---
---
# Интеграционный слой
> С какими корпоративными и внешними системами интегрируется мультиагентная платформа, какие интеграционные паттерны применимы, какой набор интеграций имеет смысл собирать в первую очередь и как этим слоем безопасно управлять.
Источник: https://ai-partner-ru.chvanov.com/raw/06-integrations.mdx
Этот документ про интеграционный слой платформы. Какие данные и действия становятся доступны агентам, через какие паттерны это устроено, как платформа подключается к корпоративным и внешним системам и какой минимальный набор интеграций имеет смысл собирать на старте.
## Из этого раздела вы узнаете
- зачем платформе нужен интеграционный слой и какие четыре задачи он решает
- какие принципы прошиты в каждый коннектор и почему один коннектор пишут один раз для всех агентов
- по каким типам и паттернам группируются интеграции и чем платят за каждый из них
- какой минимальный набор интеграций имеет смысл собирать для MVP и какие системы лежат в справочнике на вырост
---
## Коротко
Главная ценность интеграционного слоя в том, что один коннектор пишут один раз, и пользуются им все агенты в рамках своих прав. Количество подключённых систем тут вторично. За счёт этого разрастание каталога агентов превращается в операцию конфигурации.
Платформа сознательно не дублирует корпоративное хранилище и не строит собственный Data Lake поверх корпоративного. Данные остаются в тех системах, где они уже живут, а агенты обращаются к ним через управляемые коннекторы. Это решение продиктовано комплаенсом и эксплуатацией, и подробно разобрано в [05-architecture, раздел «Данные»](/05-architecture/#данные).
Для первой версии концепта список конкретных систем менее важен, чем понимание интеграционных паттернов и их компромиссов. Один и тот же DWH в разных сетях подключается по-разному, и универсальной таблицы коннекторов здесь не получится. Зато паттерны переносимы. Поэтому в этом документе сначала разбираются типы и паттерны интеграций, потом приоритетный набор для MVP, и только в конце справочник возможных систем как опорный материал для разговора с конкретным заказчиком.
:::tip[Главный тезис документа]
Главный смысл интеграционного слоя: один коннектор пишут один раз, и им пользуются все агенты в рамках своих прав. За счёт этого расширение каталога агентов превращается из проекта интеграции в операцию конфигурации, а количество подключённых систем вторично.
:::
---
## Роль интеграционного слоя
Без интеграций мультиагентная платформа превращается в обособленный диалоговый интерфейс. Сотрудник по-прежнему сам идёт за цифрой в BI и за письмом в почту, а статус поставки ему приходится отдельно выяснять в WMS. Ценность [Напарника](/02-partner) и [функциональных агентов](/03-agents) раскрывается ровно в той мере, в какой они дотягиваются до корпоративных данных и действий.
Через интеграционный слой агенты закрывают четыре задачи одновременно.
Агенты читают из корпоративных систем нужные им аналитические витрины, операционные системы, документы, почту, календарь и внешние индексы. Каждое обращение проходит через инструментальную политику.
Помимо чтения, агенты могут исполнять действия (отправить письмо, поставить задачу, обновить статус, забронировать слот). Все действия с внешним эффектом проходят через [Tier-модель](/05-architecture/#tier-модель-автономии) и явное подтверждение человека. Подробности лежат в [05-architecture, раздел «Human-in-the-loop»](/05-architecture/#human-in-the-loop).
Платформа сама запрашивает данные и вдобавок получает уведомления от внешних систем о сорванных поставках, аномалиях в продажах, входящих письмах от поставщиков и изменениях статуса в трекере. Каждое такое событие превращается в задачу для агентов мониторинга.
Система, подключённая под один сценарий, остаётся доступной для всех следующих агентов. Сотрудник получает нового агента с уже доступными ему данными, без ожидания отдельной интеграции под этот сценарий.
В архитектуре платформы интеграционный контур стоит между инструментами агентов и корпоративными данными. Агенты обращаются к данным через инструменты, а инструменты к системам через коннекторы. Подробное место этого контура в общей картине лежит в [05-architecture, раздел «Карта архитектуры»](/05-architecture/#карта-архитектуры).
---
## Принципы интеграции
Эти принципы прошиты в каждый коннектор и каждую инструментальную политику. Они работают как ограничения при подключении новой системы и как чек-лист при пресейле, когда нужно быстро понять, какие риски и сложности возникнут в конкретном ИТ-окружении заказчика.
Систему подключают один раз на уровне платформы. Дальше любой агент, у которого в инструментальной политике стоит право пользоваться этим коннектором, получает доступ. Команде внедрения дублировать интеграцию под каждого агента нельзя. Почему именно так, разобрано ниже.
Любой новый коннектор подключается в режиме только чтения. Запись добавляется отдельно, под явное обоснование и с явным расширением инструментальной политики. Это снижает класс возможных ошибок и упрощает согласование с информационной безопасностью.
Когда Напарник идёт за данными, у него доступ ровно такой, какой есть у его сотрудника. Если у менеджера нет доступа к данным соседнего подразделения, у Напарника тоже нет. Подробности механизма лежат в [05-architecture, раздел «Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа).
Платформа не дублирует и не перемещает данные. Запросы исполняются там, где данные физически живут, и в том же сетевом контуре. Если хранилище стоит on-premise, обращение к нему идёт on-premise.
Любой вызов коннектора попадает в журнал. В журнале фиксируется агент-инициатор, инструмент, параметры запроса и сжатый результат. Сотрудник может в один клик провалиться в источник, а комплаенс-офицер может разобрать любой случай по записи.
По возможности интеграция строится на стандартном протоколе (MCP-подобный коннектор, REST, событийная шина), а не на одноразовых скриптах. Это проще тестировать, проще менять провайдера и проще передавать в эксплуатацию заказчику.
:::tip[Почему именно один коннектор]
Соблазн собрать «специальную интеграцию для агента переговоров» в начале выглядит дешевле. На горизонте года это превращается в три похожих, но несовместимых коннектора к одному и тому же DWH. Платформенный коннектор к DWH с управляемой инструментальной политикой обходит эту проблему по конструкции.
:::
:::caution[Про прямое чтение из бизнес-критичных систем]
Чтение операционных данных платформа в подавляющем большинстве случаев организует через хранилище, а не из самих ERP, WMS, TMS и систем ценообразования. Эти системы относятся к бизнес-критичным, и любая дополнительная нагрузка на них воспринимается их владельцами как риск. Прямое подключение к ним возможно, но это исключение под конкретный сценарий, где задержка в выгрузке принципиально мешает работе. В таких случаях интеграция делается точечно, через выделенную сервисную учётную запись и с явным согласованием с владельцем системы.
:::
---
## Типы интеграций
Интеграции удобно сгруппировать по тому, что именно агент делает с системой. У каждой группы свои паттерны, свои комплаенс-нюансы и свой темп подключения.
Запросы к DWH, BI и семантическим витринам. Сюда же относятся [Text2SQL](/03-agents/#5-text2sql) поверх корпоративного хранилища и обращения к [семантическому слою](/05-architecture/#семантический-слой-данных). Чаще всего самая зрелая группа в крупной сети.
Текущая операционная картина (SLA поставщиков, фактические даты прихода, остатки, договоры, цены) на практике берётся из хранилища, куда эти данные регулярно выгружаются из ERP, WMS, TMS и систем ценообразования. Прямое обращение в сами бизнес-критичные системы остаётся исключением (см. ниже про прямое чтение).
RAG-контур поверх корпоративных регламентов, прецедентов, аналитических отчётов и стандартов. Может включать также общие папки, корпоративный портал и базы знаний. Подробнее эта группа разобрана в разделе [«RAG по корпоративным документам»](#rag-по-корпоративным-документам).
Корпоративный мессенджер, почта, календарь, таск-трекер. Это и пользовательский интерфейс платформы, и источник того, что происходит вокруг сотрудника прямо сейчас. Чувствительная зона по комплаенсу, потому что здесь часто лежат персональные данные и переписка с внешними контрагентами.
Запись в учётные системы, отправка писем, постановка задач, бронирование слотов в календаре. Все такие интеграции подключаются под Tier 2 как минимум. Подробности подтверждения человеком собраны в [05-architecture, раздел «Human-in-the-loop»](/05-architecture/#human-in-the-loop).
Индексы цен на сырьё, публичные отчёты, рыночные данные, мониторинг конкурентов. Внешний контент по умолчанию недоверенный и оборачивается специальной разметкой, чтобы агент не выполнил инструкции, спрятанные в письме или на странице. Механизм описан в [05-architecture, раздел «Защита от prompt injection»](/05-architecture/#защита-от-prompt-injection).
В реальном внедрении эти группы редко покрываются одинаково и одновременно. Аналитика обычно зрелая, операционные системы хорошо описаны, но сложные по правам, документы разбросаны по нескольким источникам. От стартовой зрелости каждой группы зависит, какие сценарии и какие агенты войдут в первую фазу пилота. Эта картина важна на пресейле, и подробный разбор лежит в [07-roadmap](/07-roadmap).
---
## Интеграционные паттерны
Один и тот же DWH разные заказчики подключают к платформе через разные паттерны. Иногда выбирают MCP-подобный коннектор, иногда обычный REST-API, иногда выгрузку на S3 раз в сутки. Универсального правильного ответа здесь нет, но есть несколько устойчивых паттернов, и каждый применим в своих условиях.
| Паттерн | Когда подходит | Чем платим |
|---|---|---|
| [API-интеграция](#api-интеграции) | У системы есть аккуратное REST/GraphQL/gRPC API с понятной аутентификацией и нагрузочными ограничениями. | Каждый запрос идёт в систему-источник в реальном времени. Это требует доступности этой системы. |
| [Event-driven](#event-driven-интеграции) | Система должна реагировать на события сама, не дожидаясь запроса по требованию. Агент отслеживает сорванную поставку, новое письмо или аномалию. | Сложнее наладить надёжную доставку и идемпотентность. Требуется событийная инфраструктура у заказчика. |
| [Batch](#batch-интеграции) | Большие объёмы исторических данных, ночные витрины, тяжёлые отчёты. | Данные в платформе будут отставать на интервал выгрузки. Не подходит для оперативной картины. |
| [RAG поверх документов](#rag-по-корпоративным-документам) | Когда нужно искать смысл в неструктурированных текстах (регламенты, прецеденты, отчёты). | Качество зависит от качества индекса и обновлений. Нужна отдельная процедура переиндексации. |
| [Tool calling](#tool-calling-вызов-функций) | Любая интеграция, которую агент должен вызывать сам, через стандартизованные функции. | Накладные расходы на проектирование функций и их версионирование. |
| [MCP-подобный коннектор](#mcp-подобные-подходы) | Когда нужна управляемая интеграция со стандартным интерфейсом, общая для всех агентов. | Требуется поддержка платформой и провайдером. Выгода видна на масштабе нескольких систем. |
Паттерны можно и нужно комбинировать. Один и тот же DWH может быть подключён через MCP-коннектор для горячих запросов и через batch-выгрузку для тяжёлых аналитических задач. Один и тот же мессенджер может одновременно отдавать события об упоминаниях и принимать команды через API.
### API-интеграции
Это базовый паттерн для большинства корпоративных систем с современным интерфейсом. Платформа делает запрос в систему-источник и возвращает агенту полученный ответ. Преимущество в простоте и в том, что данные приходят свежими, ровно в момент запроса.
В аккуратной API-интеграции аутентификация идёт через сервисную учётную запись с минимальным набором прав, а не через персональный токен сотрудника. Лимиты вызова платформа отслеживает у себя, чтобы один пытливый агент не перегрузил систему-источник, а ошибки и тайм-ауты обрабатывает явно, не превращая их в зависший шаг агента. Версию API при этом закрепляют явно, чтобы обновление на стороне поставщика не сломало работу платформы.
### Event-driven интеграции
Этот паттерн нужен там, где работа агентов начинается не с вопроса сотрудника, а с события в корпоративной среде. Это может быть сорванная поставка, аномалия в продажах, входящее письмо от поставщика или изменение статуса в трекере. Платформа подписывается на поток событий и превращает их в задачи для агентов мониторинга.
Технически это может быть Kafka, Rabbit, Event Hub, Redis Streams или другая событийная шина заказчика. В этом сюжете платформа - один из потребителей. На стороне платформы сидит агент мониторинга или планировщика, который читает поток, фильтрует события по релевантности и доставляет их подходящему [Напарнику](/02-partner).
При event-driven интеграциях доставка событий должна быть как минимум at-least-once, иначе часть оповещений будет теряться. Идемпотентность обязательна, потому что одно и то же событие может прийти дважды. Задержка от события до агента считается на этапе проектирования. Полчаса для аналитического оповещения обычно нормально, для срыва поставки уже долго.
### Batch-интеграции
Этот паттерн подходит для тяжёлых витрин, исторических массивов и для систем, у которых нет нормального API. Выгрузка идёт по расписанию (раз в сутки, раз в час), результат складывается в стандартное место (S3, локальная папка, внутренняя витрина), и агенты обращаются уже к ней.
Главный компромисс в актуальности. Если данные обновляются раз в сутки, утренний брифинг строится на вчерашней картине. Это терпимо для долгих аналитических разборов и непригодно для оперативной коммуникации. Поэтому batch-интеграции обычно дополняют API-интеграции, а не заменяют их.
### RAG по корпоративным документам
Через RAG (Retrieval-Augmented Generation) к платформе подключают всё, что не лежит в реляционной модели: регламенты, стандарты, переговорные прецеденты, аналитические отчёты, инструкции, шаблоны писем и методологии. Агент задаёт семантический поиск по индексу, получает релевантные фрагменты и опирается на них при формировании ответа.
В крупной сети документы редко лежат в одном месте. Часть в SharePoint, часть в Confluence, часть в общих папках, часть в корпоративном портале, часть в почтовых архивах. Поэтому в RAG-контуре обычно работает не один коннектор, а сборщик, который ходит по нескольким источникам, нормализует контент, разбивает его на фрагменты и поддерживает индекс актуальным.
Четыре приёма экономят время на пилоте RAG:
1. Не индексируйте всё подряд. Сначала закрываются конкретные сценарии: регламенты переговоров, прецеденты по поставщикам, шаблоны коммерческих писем, антикризисные протоколы. Индекс «вообще все документы компании» обычно не работает.
2. Контролируйте права доступа: индекс должен помнить, к какому фрагменту у какого сотрудника есть доступ, иначе агент случайно покажет менеджеру коммерческой дирекции содержимое HR-документов. Подробнее эта тема разобрана в [05-architecture, раздел «Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа).
3. Поддерживайте свежесть индекса. Регламенты обновляются, и устаревший фрагмент в ответе агента это уже ошибка. Переиндексация по расписанию плюс инкрементальные обновления при появлении новых документов.
4. Фиксируйте источник в каждом ответе. Когда агент опирается на фрагмент из регламента, в ответе должна стоять ссылка на конкретный документ и страницу, иначе сотрудник не сможет проверить и платформа теряет доверие.
### Tool calling (вызов функций)
Это стандартный для современных LLM механизм, в котором модель сама решает, какую функцию вызвать и с какими параметрами, а платформа исполняет вызов и возвращает результат в контекст. На уровне архитектуры это та конструкция, через которую агент превращает желание (получить данные, выполнить действие) в реальный вызов конкретного инструмента.
При проектировании функций для агентов имя и описание пишут для модели, а не для разработчика. Нечёткое описание приводит к тому, что модель применяет функцию не туда. Параметры строго типизированы, потому что свободный JSON быстро превращается в источник ошибок. Возвращаемый результат структурирован одинаково для похожих функций, иначе агент учится вручную пересобирать ответы. Каждая функция атомарна и закрывает одно действие. «Универсальная функция работы с заказами» это плохая идея, по тем же причинам, по которым плохая идея универсальный агент.
Подробнее про инструменты и их группировку можно посмотреть в [05-architecture, раздел «Инструменты агентов»](/05-architecture/#инструменты-агентов).
### MCP-подобные подходы
Model Context Protocol и его аналоги стали в 2025 году стандартом для подключения корпоративных систем к LLM-приложениям. К концу 2025 и началу 2026 MCP поддерживается всеми крупными провайдерами моделей, и для большинства распространённых корпоративных систем уже есть готовые серверы.
Для платформы это удобно по нескольким причинам. Один коннектор подключается один раз, а пользоваться им могут все агенты в рамках своих прав. Авторизация и квоты управляются на уровне сервера, а не вшиваются в каждого агента. Замена провайдера модели не ломает интеграцию, потому что протокол стандартизованный.
В контексте retail это работает так. У сети есть DWH, BI, ERP и WMS. Платформа поднимает четыре MCP-сервера (или использует готовые от поставщика). Дальше агент [Text2SQL](/03-agents/#5-text2sql) получает право обращаться к серверу DWH в режиме read, агент [OOS](/03-agents/#7-агент-oos-и-запасов) получает право обращаться к серверу WMS, агент [переговоров](/03-agents/#6-агент-переговоров-и-поставщика) читает из DWH через тот же сервер. Когда в каталоге появляется новый агент, он получает доступ к нужным серверам через [инструментальную политику](/05-architecture/#инструментальные-политики), и подключение готово.
:::caution[Реалистичная картинка зрелости]
Готовые MCP-серверы есть для распространённых SaaS и open-source систем. Для проприетарных корпоративных систем (включая многие российские ERP и WMS) MCP-серверы как правило приходится писать на стороне внедрения. Поэтому MCP не отменяет работу по интеграции, но даёт стандартный формат, в котором эта работа упаковывается.
:::
---
## Управление доступом к инструментам
Право пользоваться коннектором ещё не значит пользоваться им без ограничений. Доступ к каждой интеграции проходит через ту же иерархию инструментальных политик, что и любой другой инструмент агента. На каждом уровне (платформа, провайдер модели, агент, субагент, песочница) разрешения можно только сузить, но не расширить. Полное устройство этой иерархии с разбором каждого уровня и таблицей политик разобрано в [05-architecture, раздел «Инструментальные политики»](/05-architecture/#инструментальные-политики).
На практике это значит, что один коннектор к DWH подключают на уровне платформы, а право обращаться к нему получают только те агенты, которым он нужен для задачи. [Text2SQL](/03-agents/#5-text2sql) читает из хранилища, а агенту [OOS](/03-agents/#7-агент-oos-и-запасов) тот же коннектор недоступен, потому что в его сценарии хранилище не используется. Так одна интеграция обслуживает несколько агентов, и при этом каждый видит ровно тот срез, который ему положен.
:::tip[Главный практический совет]
При подключении новой интеграции по умолчанию закрывайте всё, кроме одного агента и одного действия, под которые она и подключается. Расширять права проще и безопаснее, чем сужать после инцидента.
:::
---
## Приоритетные интеграции для MVP
Стартовый набор интеграций должен закрывать понятные сценарии и не требовать инфраструктуры, которой у заказчика ещё нет. Для большинства крупных торговых сетей этот набор устроен примерно одинаково и состоит из пяти позиций.
| Интеграция | Что даёт на старте | Связанные агенты и сценарии |
|---|---|---|
| [DWH, Data Lake, Lakehouse](#dwh-data-lake-lakehouse) | Аналитическая фактура, продажи, маржа, остатки, цены, промо. Без этого не работает ни один аналитический сценарий. | Text2SQL, агент факторного анализа, агент промо, агент финансового эффекта. Сценарии 2 и 3 из [04-usecases](/04-usecases). |
| [Корпоративные документы и регламенты](#документы-и-регламенты) | RAG-контур для прецедентов, регламентов и стандартов. Главный источник «что у нас уже было в похожих ситуациях». | Агент базы знаний, агент регламентов, агент переговоров (за прецедентами). |
| [Корпоративный мессенджер, почта, календарь](#корпоративный-мессенджер) | Канал общения сотрудника с Напарником, источник входящих сигналов, возможность бронировать слоты и ставить задачи. | Все Напарники, агент встреч и контроля договорённостей. Сценарий 5 из [04-usecases](/04-usecases). |
| [BI-системы](#bi-системы) | Готовые расчёты и нормализованные витрины, поверх которых проще делать факторный анализ и формировать презентации. | Аналитические агенты, агент факторного анализа, генерация презентаций. |
| [Таск-трекер или система поручений](#таск-трекеры) | Точка фиксации действий и follow-up. Без неё договорённости теряются между мессенджером и почтой. | Агент встреч и follow-up, контроль договорённостей у Напарника. |
Этот набор сознательно не включает ни ERP, ни WMS, ни систему ценообразования. Они подключаются на следующих фазах под конкретные сценарии. На старте пилота их отсутствие не блокирующее, потому что данные о поставках и SLA как правило уже доступны в DWH через регулярные выгрузки. Подробное соответствие интеграций фазам внедрения собрано в [07-roadmap, раздел «Приоритетные интеграции для старта»](/07-roadmap/#приоритетные-интеграции-для-старта).
---
## Справочник потенциальных интеграций
Этот раздел не нужно полностью заполнять в первой версии концепта. Он работает как каталог возможностей и опорный материал для разговора с заказчиком. Конкретные системы под конкретного заказчика добавляются точечно, и далеко не все интеграции из списка имеет смысл строить.
### DWH, Data Lake, Lakehouse
Главный источник аналитических данных для платформы. В крупных российских сетях это чаще всего Greenplum, ClickHouse, реже PostgreSQL или Vertica. Постепенно растёт доля решений на базе Lakehouse (Apache Iceberg, Delta Lake) поверх объектного хранилища.
Платформа подключается к DWH в режиме read-only. Через него работают [Text2SQL](/03-agents/#5-text2sql), [агент факторного анализа](/03-agents/#11-агент-факторного-анализа), [агент промо](/03-agents/#1-агент-промо), [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) и [агент аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) (канонические названия агентов и их инструментальные политики разобраны в [03-agents](/03-agents)). [Семантический слой](/05-architecture/#семантический-слой-данных) поверх DWH (если он есть) подключается отдельно и используется агентами для интерпретации полей и метрик. Подробнее про семантический слой написано в [05-architecture, раздел «Семантический слой данных»](/05-architecture/#семантический-слой-данных).
Уровень нагрузки от агентов на DWH вырастает заметно, особенно с [проактивным циклом](/05-architecture/#проактивный-цикл). Этот рост закладывается в проектирование: выделенная сервисная учётная запись, отдельная очередь ресурсов и кэширование частых запросов на стороне платформы.
### ERP
Источник договоров, поставок, заказов, контрактных условий и многих корпоративных справочников. В российских сетях это чаще всего 1С в одной из конфигураций, реже SAP S/4HANA, Oracle EBS или собственная разработка.
По общему принципу (см. «Про прямое чтение из бизнес-критичных систем») платформа берёт данные ERP из его регулярных выгрузок в DWH. Прямое подключение к ERP оправдано только там, где задержка в выгрузке принципиально мешает сценарию или где нужна запись (например, обновление статуса заказа). В этих случаях интеграция собирается точечно, под узкий список операций, и согласуется с владельцем системы. Запись в ERP подключается под Tier 2.
### CRM и CDP
CRM хранит работу с поставщиками и клиентами, а именно историю контактов, контракты и активные сделки. CDP агрегирует поведение покупателей сети, программу лояльности, отклик на промо.
В коммерческой дирекции крупной сети CRM иногда отсутствует как отдельная система, и его роль закрывают почта, Excel и заметки в мессенджере. В таких случаях коннектор к CRM не нужен, а профили поставщиков ведутся в личной памяти [Напарника](/02-partner) (как Напарник ведёт профили контактов в личной памяти, описано в [02-partner, раздел «Уровень 3. Коммуникационный помощник»](/02-partner/#уровень-3-коммуникационный-помощник)). В сетях с зрелой CRM коннектор полезен для [агента переговоров](/03-agents/#6-агент-переговоров-и-поставщика), чтобы тянуть историю контактов и контракты.
### PIM и MDM
PIM хранит атрибуты товаров, MDM хранит мастер-данные по поставщикам, контрагентам, локациям. Эти системы подключаются для сценариев, в которых нужна точная атрибутика. Например, разбор ассортиментной матрицы или подготовка к листингу нового SKU.
На стартовом наборе MVP эти интеграции обычно избыточны. Они подключаются ближе к зрелости платформы, когда коммерческий контур уже работает.
### SRM
Система управления отношениями с поставщиками. Закрывает профили поставщиков, контракты, KPI поставщика, тендеры. У большинства крупных сетей SRM как отдельной системы нет. Если есть, коннектор к ней полезен для агента переговоров, потому что он перестаёт собирать профиль поставщика по почте и трекерам.
### WMS и TMS
WMS отвечает за склады, остатки, фактические поставки и SLA по поставщикам. TMS отвечает за транспорт. Остатки, поставки и SLA для [агента OOS](/03-agents/#7-агент-oos-и-запасов) и [агента аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) чаще всего читаются из DWH, куда WMS их регулярно выгружает.
Прямое подключение к WMS оправдано только там, где сценарию принципиально нужна свежесть, которую выгрузки в DWH не обеспечивают (например, оперативная картина по конкретному РЦ в момент срыва поставки), и собирается точечно по общему принципу (см. «Про прямое чтение из бизнес-критичных систем»). Запись в WMS как правило не подключается вообще. Запросы на изменение поставок идут через стандартные маршруты компании, а не через агентов. Это сознательное архитектурное ограничение, которое снижает риск неоткатываемых ошибок.
### BI-системы
BI как правило уже работает в сети и закрывает регулярную аналитику. На платформе BI используется двумя способами. Первый, через прямое чтение тех же витрин, поверх которых строятся дашборды. Это удобно, потому что витрины уже валидированы. Второй способ, через интеграцию с самим BI-инструментом для встраивания готовых отчётов в ответы агентов и для генерации новых дашбордов под конкретные ситуации.
Распространённые BI-инструменты в российских сетях включают PIX BI, Datalens, Apache Superset, реже Tableau и Power BI на отдельных контурах. Подключение к ним идёт через REST-API инструмента или через прямое чтение витрин в DWH.
### Системы ценообразования
Системы ценообразования содержат правила переоценки, ценовое позиционирование, эластичность спроса. На пилоте обычно не входят, потому что аналитический агент в первую очередь работает с историческими ценами из DWH. Подключение нужно для сценариев, в которых агент должен предлагать новую цену или объяснять причину изменения.
### Системы промо-планирования
Аналогично системам ценообразования. Параметры промо обычно сначала берутся из DWH, и подключение к самому планировщику нужно только тогда, когда агент должен моделировать новые акции или валидировать план. На MVP это интеграция второго круга.
### Документы и регламенты
Через эту интеграцию агенты дотягиваются до корпоративной базы знаний, переговорных прецедентов, аналитических отчётов, инструкций, шаблонов писем и методологий. В крупной сети всё это редко лежит в одном месте, поэтому работа с группой идёт через RAG-паттерн со сборщиком по нескольким источникам, разобранный в разделе [«RAG по корпоративным документам»](#rag-по-корпоративным-документам).
Через эту интеграцию работают [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов), агент регламентов и [агент переговоров](/03-agents/#6-агент-переговоров-и-поставщика) в части прецедентов. На стартовом наборе MVP эта интеграция входит, потому что без прецедентов и регламентов вес коммерческих сценариев заметно проседает.
### Системы документооборота
ЭДО хранит контракты, дополнительные соглашения, согласования. Подключение нужно для сценариев, где агент должен поднять конкретный контракт или статус согласования. Интеграция чувствительная по правам и обычно идёт после стандартной RAG-интеграции с базой знаний.
### Таск-трекеры
Это точка фиксации задач и договорённостей. В сетях это часто Jira, реже Asana, иногда внутренний инструмент или 1С с надстройкой. Коннектор полезен с первой фазы, потому что без него follow-up [Напарника](/02-partner) не доходит до сотрудников.
Чтение задач подключается сразу. Запись задач (постановка нового задания, обновление статуса) подключается под Tier 2 и проходит через подтверждение человеком.
### Корпоративный мессенджер
Главный пользовательский канал платформы. В российских сетях это чаще всего Telegram или MAX, в более закрытых контурах eXpress, Mattermost, корпоративные сборки Rocket.Chat. Архитектурно это коннектор, а не сама парадигма, и он меняется под политику заказчика. Подробности базового решения по каналу лежат в [01-vision, раздел «Базовые допущения концепта»](/01-vision/#базовые-допущения-концепта).
### Почта
Источник писем от поставщиков, коллег и систем. Подключается через стандартные протоколы (IMAP, MS Graph, JMAP) или через корпоративную почтовую систему. Чтение почты входит в стартовый набор, потому что без него Напарник не видит входящих сигналов.
Отправка писем от имени сотрудника подключается под Tier 2. Черновик готовит агент, кнопку «отправить» нажимает человек.
### Календарь
Через календарь работают сценарии встреч, бронирования, напоминаний. Подключение делается на стороне корпоративного провайдера (Microsoft 365, Google Workspace, Яндекс 360, отечественные альтернативы). Чтение слотов входит в стартовый набор, бронирование под Tier 2, согласование между Напарниками разных сотрудников разбирается в [04-usecases, разделе «Сценарий 5. Межфункциональная встреча через Напарников»](/04-usecases/#сценарий-5-межфункциональная-встреча-через-напарников).
### Встречи и видеоконференции
Сюда относятся Zoom, Microsoft Teams, Яндекс.Телемост, отечественные альтернативы. Платформа подключается к ним через корпоративный API или через бот-участника. Этот коннектор нужен для сценариев записи встречи, последующего разбора транскрипта и генерации follow-up.
Подсказки в реальном времени на встрече требуют отдельной обвязки и обычно подключаются позже, как продвинутый сценарий. Подробности этой темы собраны в [02-partner, раздел «Уровни зрелости ИИ-Напарника»](/02-partner/#уровни-зрелости-ии-напарника).
### Данные конкурентов
Цены, ассортимент, активные акции, наличие в магазинах. В сетях это часто отдельный сервис парсинга или внешний поставщик. Коннектор подключается для агента конкурентного мониторинга, который стоит во втором круге каталога. Подробности про самого агента лежат в [03-agents](/03-agents).
### Рыночные данные
Сюда входят индексы цен на сырьё и упаковку, отраслевые отчёты, валютные курсы и макроэкономические показатели. Коннектор полезен для агента переговоров, который опирается на эти данные при формировании аргументации. Источники могут быть платными (CRU, ICIS), бесплатными (Росстат, профильные СМИ) или внутренними индексами компании.
### Данные поставщиков
Открытые данные конкретных поставщиков: финансовая отчётность, новости, тендерная активность, изменения в собственности. Коннектор полезен для агента переговоров и для оценки рисков по поставщику. На пилоте эта интеграция обычно не нужна, и достаточно того, что агент опирается на корпоративные данные.
### Открытые источники
К открытым источникам относятся веб-поиск, агрегаторы новостей и отраслевые форумы. Они подключаются через стандартные поисковые API и оборачиваются защитной разметкой как источник недоверенного контента.
---
## Ограничения интеграционного слоя
Чтобы концепт не выглядел как идеальная сборка, важно явно зафиксировать ограничения, с которыми столкнётся реальное внедрение.
| Ограничение | Описание | Что делать |
|---|---|---|
| **Зрелость API у систем** | У части корпоративных систем API ограниченный или его вовсе нет. Особенно у проприетарных российских ERP и специфичных WMS. | На старте идти через DWH-выгрузки. API подключать в момент, когда без него блокируется конкретный сценарий. |
| **Качество данных** | Если в DWH есть пустые поля, расхождения между справочниками или неактуальные витрины, агенты будут возвращать некачественные результаты. | Подключать агента качества данных, фиксировать критичные витрины и согласовывать SLA с владельцами данных. |
| **Доступ и комплаенс** | Часть данных попадает под дополнительные требования (персональные данные клиентов, финансовые детали, переписка с внешними контрагентами). Подключение требует согласований. | Эти интеграции выносятся из MVP и подключаются точечно после согласования с информационной безопасностью. |
| **Нагрузка на источники** | Проактивный цикл и параллельная оркестрация дают заметный рост запросов к DWH и BI. Без подготовки это может ухудшить работу штатной аналитики. | Выделенная сервисная учётная запись, отдельная очередь ресурсов, кэширование частых запросов на стороне платформы. |
| **Версионирование интерфейсов** | Изменение API на стороне поставщика без согласования ломает работу платформы. | Версия API фиксируется явно, обновления проходят через регрессионный прогон агентов на тестовом контуре. |
| **Устаревание индекса в RAG** | Устаревший фрагмент в ответе агента уже ошибка, подробнее в разделе [«RAG по корпоративным документам»](#rag-по-корпоративным-документам). | Регулярная переиндексация плюс инкрементальные обновления. Фиксация даты документа в каждом ответе агента. |
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Зрелость MCP-серверов под российские системы]
Что из MCP-серверов готово, а что приходится писать самим, разобрано выше в разделе [«MCP-подобные подходы»](#mcp-подобные-подходы). Открытый вопрос в том, как на пресейле честно оценить трудоёмкость собственной разработки сервера под проприетарную систему и сравнить её с временной альтернативой через DWH-выгрузки.
:::
:::caution[Допущение «операционные данные всё равно лежат в DWH»]
На нём держится решение не включать в MVP ни ERP, ни WMS, ни систему ценообразования. Но регулярная выгрузка в хранилище проектировалась под отчётность, а не под агентов, и часто не содержит того среза, который нужен сценарию (например, причину срыва поставки, а не сам факт), либо отстаёт на ночной цикл. Если по факту обнаруживается, что половина операционных сценариев требует прямого подключения к бизнес-критичным системам, экономика «дешёвого старта на одном DWH» рушится, а согласование прямого доступа с владельцами систем становится критическим путём пилота, а не следующей фазой.
:::
:::caution[«Один коннектор на всех» против гранулярности прав]
Главный тезис документа экономит на интеграции, но создаёт нагрузку на слой политик. Если к одному MCP-серверу DWH ходят и Text2SQL, и агент переговоров, и проактивный мониторинг, то всё разграничение (какие схемы, какие строки, какой объём) переезжает в инструментальные политики и row-level-доступ единой сервисной учётной записи. Концепт постулирует, что «права сотрудника не расширяются», но как технически удержать персональный периметр доступа сотрудника при обращении через общий служебный коннектор, на уровне реализации не доказано и для проприетарных систем без row-level-security может оказаться нерешаемым без дублирования коннекторов, которое тезис как раз и запрещает.
:::
:::caution[Граница записи в учётные системы и обещание отката]
В архитектуре запись в WMS «как правило не подключается вообще» ради защиты от неоткатываемых ошибок, а запись в ERP/CRM идёт через Tier 2. Но подтверждение человеком не делает операцию обратимой. Подтверждённое изменение статуса заказа или цены в учётной системе так же необратимо, как и неподтверждённое. Где проходит граница операций, которые агенту разрешено инициировать вообще (даже с подтверждением), и нужен ли отдельный механизм компенсирующих транзакций, концепт не формулирует, а ответ различается между заказчиками и должен фиксироваться для каждого внедрения.
:::
:::caution[Право-зависимый RAG-индекс как узкое место качества и стоимости]
Требование «индекс помнит, к какому фрагменту у кого есть доступ» легко записать абзацем, но дорого реализовать. Права в SharePoint, Confluence, портале и почтовых архивах живут в разных моделях, меняются ежедневно, и фильтрация по ним на этапе извлечения либо роняет полноту поиска (агент не видит релевантный фрагмент, к которому доступ есть), либо рискует утечкой при рассинхронизации индекса с источником прав. Простой RAG поверх единого индекса упирается в этот потолок раньше, чем в качество ранжирования, и переход к более сложным схемам (графовое представление, переиндексация прав в реальном времени) меняет стоимость владения контуром на порядок. А на какой зрелости платформы этот переход оправдан, концепт не определяет.
:::
---
# Дорожная карта внедрения
> Как разворачивать платформу во времени. Фазы внедрения от подготовки до масштабирования, приоритетные сценарии и интеграции для старта, метрики успеха и организационные условия, без которых техническое внедрение не даёт полного эффекта.
Источник: https://ai-partner-ru.chvanov.com/raw/07-roadmap.mdx
Документ собирает агентов, сценарии и интеграции в последовательность фаз внедрения. Он отвечает на вопрос, в каком порядке разворачивать платформу, с чего начинать пилот, как понять, что он удался, и какие организационные условия нужны, чтобы техническое внедрение дало эффект.
## Из этого раздела вы узнаете
- из каких фаз состоит внедрение, от подготовки до масштабирования, и почему они перекрываются
- какие сценарии разумно брать в пилот первыми и почему аналитические
- какие интеграции нужны на старте, а какие сознательно переносятся на потом
- как оценивать пилот по метрикам скорости, денег и пользовательского принятия
- какие организационные условия должны быть закрыты, иначе техническое внедрение буксует
---
## Коротко
Платформу разворачивают поэтапно, а не одним релизом. Она растёт по фазам, и каждая следующая опирается на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности предыдущей. Эта логика повторяет лестницу уровней зрелости Напарника из [02-partner](/02-partner/#уровни-зрелости-ии-напарника), но смотрит на неё со стороны проекта внедрения, а не со стороны сотрудника.
Старт почти всегда устроен одинаково: один Напарник, четыре-пять [функциональных агентов](/03-agents), одна-две понятные интеграции и небольшая группа менеджеров-добровольцев в одном подразделении. Дальше контур расширяется по мере того, как заказчик видит ценность и подтягиваются источники данных.
:::tip[Главный тезис документа]
Платформу разворачивают поэтапно, а не одним релизом. Начинать нужно с узкого пилота на зрелых данных и быстром аналитическом эффекте, а расширение контура и [межнапарниковую коммуникацию](/05-architecture/#межнапарниковая-коммуникация-a2a) подключать только после того, как заказчик увидел ценность и закрыл организационные условия.
:::
---
:::caution[Статус документа]
Это черновик-скелет. Разделы намечены, но детальная проработка фаз, цифр и чек-листов появляется при подготовке к конкретному пилоту. Пока документ задаёт каркас и связывает остальные разделы концепта между собой.
:::
## Этапы внедрения
Ниже укрупнённая последовательность фаз. Это карта зависимостей, а не жёсткий календарный план. На реальном проекте фазы перекрываются, потому что базовый аналитический контур обычно поднимается одновременно с операционным помощником.
1. Фаза 0, подготовка. Здесь нет ещё ни одного работающего [Напарника](/02-partner), зато закладывается всё, без чего пилот не поедет. Команда внедрения вместе с ИТ заказчика выбирает мессенджер, согласует модель развёртывания и доступы, фиксирует Tier-модель автономии (см. [05-architecture](/05-architecture/#tier-модель-автономии)) и договаривается о метриках успеха. Параллельно назначается куратор [организационной памяти](/05-architecture/#память-и-контекст) и владелец бизнес-сценария. Организационная часть этой фазы разобрана ниже в разделе «Организационные условия успеха».
2. Фаза 1, пилот. Команда внедрения запускает узкий контур на нескольких менеджерах-добровольцах. Обычно это операционный и аналитический уровни Напарника, два-три приоритетных сценария из [04-usecases](/04-usecases) и минимальный набор интеграций. Цель фазы — получить первый видимый эффект на реальной работе и собрать обратную связь от людей.
3. Фаза 2, расширение. Контур растёт. Команда подключает новые функциональные агенты из каталога, операционные сценарии (OOS, недопоставки) и новые интеграции к операционным системам через выгрузки в хранилище, а затем — коммуникационный уровень Напарника с [профилями контрагентов](/05-architecture/#профили-контрагентов) и подсказками на встречах.
4. Фаза 3, масштабирование. Платформа выходит за пределы первого подразделения, и включается мультиагентный уровень. Напарники начинают [разговаривать между собой по управляемой политике](/05-architecture/#межнапарниковая-коммуникация-a2a), появляется коллективная память с куратором, дозревает управление. На этой фазе становятся значимыми [управление стоимостью](/05-architecture/#управление-стоимостью) и операционная поддержка на стороне заказчика.
---
## Приоритетные сценарии для старта
В пилот разумно брать сценарии, которые быстро дают видимый эффект и не требуют интеграций, которые невозможно собрать за разумное время. Из [04-usecases](/04-usecases) на эту роль лучше всего ложатся два аналитических сценария.
[Сценарий 2](/04-usecases/#сценарий-2-разбор-падения-продаж-по-категории) опирается на хранилище и BI, которые у крупной сети обычно уже зрелые. Эффект на скорости разбора виден почти сразу, и под него не нужны операционные интеграции.
На [Сценарии 1](/04-usecases/#сценарий-1-подготовка-к-переговорам-с-поставщиком) виден прямой P&L-эффект на бэк-марже. Часть данных по поставкам и SLA приходит из хранилища, поэтому ERP и WMS на старте не нужны.
Операционные сценарии (управление OOS, кризисные ситуации) и межфункциональную координацию подключаем на следующих фазах. Они дают много ценности, но требуют более зрелых интеграций и наработанного доверия к автономным действиям. Полный список сценариев со статусами лежит в [04-usecases, раздел «Карта сценариев»](/04-usecases/#карта-сценариев).
---
## Приоритетные интеграции для старта
Стартовый набор интеграций должен закрывать выбранные сценарии и не упираться в инфраструктуру, которой у заказчика ещё нет. Подробный разбор лежит в [06-integrations, раздел «Приоритетные интеграции для MVP»](/06-integrations/#приоритетные-интеграции-для-mvp). Если коротко, на старте нужны хранилище и BI как источник аналитики, RAG поверх регламентов и прецедентов, корпоративный мессенджер с почтой и календарём, а также таск-трекер для фиксации договорённостей.
Этот набор сознательно не включает ERP, WMS и системы ценообразования. Данные о поставках и SLA на старте берём из хранилища через регулярные выгрузки, поэтому прямое подключение бизнес-критичных систем оставляем на более поздние фазы.
---
## Метрики успеха
Пилот оцениваем по заранее согласованному набору метрик, который команда внедрения и заказчик фиксируют ещё на Фазе 0. Без этой договорённости разговор о результате после пилота превращается в спор об ощущениях. Метрики удобно разносить на операционные, бизнес-метрики и пользовательские. Полный каталог с примерами и способами замера лежит в [02-partner, раздел «Метрики ценности ИИ-Напарника»](/02-partner/#метрики-ценности-ии-напарника).
Эффект смотрим с нескольких сторон сразу. По скорости это время на типовой аналитический запрос и путь от аномалии до оповещения. На деньгах эффект виден по марже категории и дополнительной бэк-марже в переговорах. А чтобы понять, прижился ли инструмент у людей, собираем NPS менеджеров и долю задач, в которых сотрудник идёт к Напарнику.
Универсального ROI у платформы нет. Финальная цифра зависит от того, какие сценарии входят в пилот, какая стартовая зрелость данных у заказчика и какие процессы он готов пересобрать. Поэтому набор метрик и их пороги мы привязываем к стандартному пресейл-процессу и определяем под конкретного заказчика.
---
## Организационные условия успеха
Техническое внедрение само по себе не даёт полного эффекта. Платформа требует организационной готовности, и эту часть лучше начинать на Фазе 0, а не оставлять на потом.
Нужна роль, формально ответственная за качество [коллективной памяти](/05-architecture/#коллективная-память). Обычно это руководитель направления или сильный эксперт. Без куратора коммерчески значимые паттерны либо не попадают в общий контур, либо попадают туда без проверки.
[Tier-модель автономии](/05-architecture/#tier-модель-автономии), политики хранения данных и доступ к журналу аудита согласуются с информационной безопасностью заранее. Особенно это касается Tier 3, где каждый автономный сценарий проходит отдельную санкцию.
Часть ценности раскрывается только тогда, когда заказчик готов формализовать процессы вокруг новой модели работы. Если процесс остаётся прежним, [Напарник](/02-partner) ускоряет отдельные операции, но не меняет темп функции целиком.
Пилот стартует на тех, кому это интересно. Лучшие менеджеры, перегруженные сильнее всех, дают и самую честную обратную связь, и самый заметный эффект.
Отдельно стоит модель совместной эксплуатации. К шестому-двенадцатому месяцу внедрения Glowbyte и заказчик распределяют роли между собой. Glowbyte остаётся архитектурным партнёром и развивает каталог агентов и сценариев, а ИТ-команда заказчика постепенно берёт на себя операционную поддержку платформы. Эту модель важно проговорить с самого начала, потому что от неё зависит передача знаний на протяжении всего проекта.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Карта зависимостей без календаря трудно превращается в обязательство]
Длительности фаз и календарные сроки заданы намеренно условно («к шестому-двенадцатому месяцу»), потому что зависят от стартовой зрелости заказчика. Но заказчик на пресейле почти всегда хочет дату и фиксированный объём первой фазы. Как давать дорожную карту, по которой можно зафиксировать обязательства и бюджет, не подменяя их вилкой «зависит от вас», концепт пока не формулирует.
:::
:::caution[Фаза 0 несёт орг-риск, а не технический]
Фазовая модель предполагает перекрытие фаз, но всё внедрение упирается в Фазу 0, а именно в куратора организационной памяти, согласование с комплаенсом и готовность пересобрать процессы. Если у заказчика эти условия не закрыты, пилот технически запускается, но не даёт обещанного эффекта, и причина лежит на стороне заказчика, а не платформы. Концепт пока не отвечает, как заранее отличить заказчика, у которого Фаза 0 реально закроется, от того, кто формально подпишет условия и не выполнит.
:::
:::caution[Модель совместной эксплуатации несёт коммерческое напряжение]
Разделение ролей между Glowbyte и ИТ-командой заказчика к шестому-двенадцатому месяцу намечено, но не детализировано. За этой передачей стоит коммерческий конфликт. Где проходит граница между «архитектурным партнёрством» Glowbyte и операционной самостоятельностью заказчика и как устроена экономика поддержки после неё. Если передать слишком рано, страдает качество, а если слишком поздно, это выглядит как удержание заказчика на сопровождении.
:::
:::caution[Пилот показывает не то, чем платформа отличается]
В пилот мы сознательно берём аналитические сценарии на зрелых данных, а проактивность, операционные действия и межнапарниковую коммуникацию переносим на Фазы 2–3. Но именно отложенные возможности и составляют отличие Эпохи 4 от уже знакомых заказчику BI и функциональных агентов. Получается, что в первой фазе заказчик видит как раз самую слабую часть дифференциации, и скептичный заказчик вправе спросить, чем разбор падения продаж принципиально лучше связки «BI плюс [text2SQL](/03-agents/#5-text2sql)», которая у него, возможно, уже есть. Как доказать ценность именно платформенного слоя на узком аналитическом пилоте, не дожидаясь поздних фаз, концепт пока не формулирует.
:::