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

Документ описывает функциональных агентов как специализированных ИИ-исполнителей, которые решают узкие классы задач и работают под координацией ИИ-Напарника. Здесь сведены принципы проектирования, классификация, шаблон карточки и подробный разбор пяти агентов, с которых имеет смысл начинать пилот. Пользовательская модель ИИ-Напарника описана в 02-partner, бизнес-сценарии лежат в 04-usecases, а архитектура и инструментальные политики разобраны в 05-architecture.

Коротко

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

В обычном рабочем дне сотрудник этих агентов как правило не видит. Запросы к ним отправляет ИИ-Напарник, он же собирает результаты в один ответ и приносит сотруднику. Так выглядит правильное разделение ответственности. Напарник держит контекст человека и оркеструет работу, функциональный агент качественно и предсказуемо закрывает свою предметную область.

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

Что такое функциональный агент

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

Во-первых, у него один класс задач. Агент факторного анализа разбирает отклонения в продажах. Агент переговоров готовит досье на поставщика. Агент алертов следит за аномалиями. Размывать специализацию плохая идея, так как универсальный агент тяжелее настраивать, его сложнее аудировать и сложнее улучшать по обратной связи. Лучше иметь пять агентов с понятными границами, чем один, который умеет всё подряд.
Во-вторых, у него узкая инструментальная политика. Агент видит только те данные и инструменты, которые ему нужны для работы. Агент Text2SQL имеет read-only-доступ к корпоративному хранилищу и не имеет ничего больше. Агент алертов читает данные и имеет канал отправки сообщения Напарнику, но не может писать в системы или гулять по вебу. Эта политика управляется на уровне платформы, а не на уровне инструкций модели, и тогда никакой prompt injection её не обойдёт.
В-третьих, функциональный агент стоит на одну роль выше слоя данных и на одну ниже Напарника. К нему обращается не сотрудник, а Напарник от имени сотрудника. Это важная деталь, потому что на функциональный агент вешается качество исполнения предметной задачи, а не работа с контекстом конкретного человека. Контекст лежит на уровне Напарника. У одного функционального агента в сети живёт один экземпляр, и им пользуются все Напарники в рамках своих прав.

Роль функциональных агентов в платформе

Функциональные агенты дают платформе предметную глубину. Напарник без них умеет вести диалог, держать контекст и принимать решения о маршрутизации, но сам по себе не сделает качественно факторный анализ и не напишет SQL. Каждый такой навык приходит через подключение нового функционального агента.

С точки зрения внедрения это достаточно удобно. Каталог агентов растёт постепенно. Сначала закрываются самые болезненные сценарии (на пилоте, например, разбор отклонений и подготовка к переговорам), остальное добавляется по мере того, как заказчик видит ценность и подтягиваются интеграции с источниками данных. Каждый новый агент представляет собой отдельную единицу поставки, у неё понятные границы, понятные тесты и измеримый эффект.

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

Это свойство и даёт четвёртой эпохе главное преимущество перед третьей. В третьей эпохе агенты подключаются к менеджеру напрямую, и каждый новый агент это ещё одна вкладка, приложение или отчёт, которые нужно держать в голове. В четвёртой эпохе все они стоят за Напарником, и сотруднику этот рост не виден.

Отличие функционального агента от ИИ-Напарника

На словах эти сущности легко путаются, поэтому стоит держать в голове простой тест границы. У Напарника есть личный контекст конкретного сотрудника, его приоритеты и история решений, и он закреплён за человеком, поэтому сотрудник работает с ним напрямую. У функционального агента личного контекста нет, он закреплён за классом задач и работает «под капотом», и его вызывает скорее Напарник, а не сотрудник.

Если у сущности есть личный контекст конкретного сотрудника, то это часть Напарника. Если у сущности есть узкая инструментальная политика и она работает «под капотом», то это функциональный агент. Когда границы соблюдаются, платформу проще аудировать и развивать.

Полная таблица отличий по семи критериям (за кем закреплён, кто вызывает, что знает, что возвращает, доступ к данным и т.д.) лежит в 02-partner, раздел «Отличие ИИ-Напарника от функционального агента».

Принципы проектирования агентов

Эти принципы прошиты в архитектуру и должны выполняться для каждого нового агента в каталоге. Подробное архитектурное обоснование лежит в 05-architecture, раздел «Архитектурные принципы», здесь же компактная сборка, на которую можно опираться при разговоре с заказчиком.

Узкая специализация

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

Минимальные права

Агент получает только те инструменты, которые ему нужны для работы. По умолчанию права read-only. Запись, отправка и обращения к другим агентам как правило выдаются отдельно, под явное разрешение.

Ссылка на источник

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

Структурированный ответ

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

Обратная связь

Агент умеет принимать поправки от сотрудника. Реплика «это был не OOS, а списание по сроку годности» сохраняется как сигнал и учитывается в следующих похожих разборах. Без этой петли агент быстро упирается в потолок качества.

Изоляция

Несколько Напарников вызывают один и тот же агент параллельно, и контексты их вызовов не пересекаются. Технически это решается на уровне сессий и описано в 05-architecture, раздел «Модель взаимодействия агентов».

Ещё один принцип не вписался в карточки, но играет роль на практике. Агенты не разговаривают с внешним миром от имени сотрудника. Внешние коммуникации, изменения в учётных системах, листинг и делистинг проходят через Напарника и через явное подтверждение человека. Эта граница описывается через Tier-модель автономии и подробно разбирается в 02-partner и 05-architecture.

Удачные паттерны работы агента полезно отчуждать в скиллы. Когда у конкретного агента закрепляется хорошо работающий подход (например, формат диагностической карточки факторного анализа или способ считать каннибализацию промо), его описывают как платформенный скилл и делают доступным всему каталогу. Это часть жизненного цикла агента и один из главных механизмов накопления коллективной экспертизы. Платформенный механизм скиллов и retail-примеры разобраны в 05-architecture, раздел «Скиллы».

Классификация функциональных агентов

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

Коммерческие агенты

Эта группа закрывает повседневную работу категорийного менеджера и коммерческого блока. Сюда входят анализ продаж и маржи, разбор промо, подготовка к переговорам, ассортиментные решения, ценообразование. Это самая богатая группа в каталоге и обычно самая первая по приоритету при пилоте. Здесь P&L-эффект виден быстрее всего.

Операционные агенты

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

Клиентские агенты

Эта группа отвечает за сегментацию клиентов, поведенческие паттерны, отклик на промо и удержание. Полезна там, где у сети есть собственная программа лояльности и сильная аналитика клиентского поведения. На первой версии концепта эти агенты обычно идут в backlog, потому что сначала важнее закрыть коммерческий контур.

Аналитические агенты

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

Коммуникационные агенты

Эта группа работает со встречами и текстами. Сюда входят запись встреч, разбор и суммаризация транскриптов, формирование follow-up, профили контактов, помощь с написанием писем и презентаций, realtime помощь в переговорах. Эта группа особенно сильно греет сотрудников на пилоте, так как экономия времени видна практически сразу.

Организационные агенты

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

Приоритетные агенты для MVP и пилота

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

Агент промо

Пост-анализ эффективности промо-акций, каннибализация, эффект на маржу. Помогает разбираться, почему одна акция сработала, а соседняя нет. Подробная карточка лежит в разделе «Агент промо».

Агент переговоров

Готовит досье на поставщика и аргументацию к встрече. Это могут быть индексы цен, история уступок, недопоставки, доля в категории. Подробная карточка лежит в разделе «Агент переговоров и поставщика».

Агент OOS и запасов

Агент следит за доступностью товара, разбирает причины out-of-stock, предлагает действия. Предполагается, что агент проактивно ловит проблему до того, как она превратилась в потерю выручки. Подробная карточка лежит в разделе «Агент OOS и запасов».

Агент финансового эффекта

Оценивает влияние решений на маржу, выручку, оборачиваемость и списания. Работает как кросс-функциональный калькулятор последствий. Подробная карточка лежит в разделе «Агент финансового эффекта».

Агент встреч и follow-up

Разбирает транскрипты, формулирует договорённости, ставит напоминания, контролирует исполнение. Снимает с менеджера роль «контролёра по встречам». Подробная карточка лежит в разделе «Агент встреч и follow-up».

Агенты промо, переговоров и OOS закрывают три самые громкие категории боли категорийного менеджера. Агент финансового эффекта работает как «общий знаменатель», он подсчитывает последствия любого коммерческого решения и встраивается в работу остальных агентов. Агент встреч и follow-up даёт быстрый видимый эффект на любом сотруднике, у которого есть встречи в календаре, и хорошо демонстрирует ценность платформы за пределами аналитики.

Шаблон карточки агента

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

Назначение. Одна-две строки про то, какой класс задач закрывает агент. Если объяснить сложно, стоит вернуться к принципам проектирования.
Пользователи. Кто из сотрудников будет ожидаемым или самым частым бенефициаром. Как правило, это не Напарник, а человек за ним. Например, категорийный менеджер коммерческой дирекции, логист направления, руководитель промо.
Типовые вопросы. Список реальных формулировок, с которыми сотрудник приходит к Напарнику и которые в итоге попадают этому агенту. Это полезно для тренировки, для тестов и для разговора с заказчиком.
Используемые данные. Источники, к которым агент обращается. Желательно с пометкой режима, например read-only, read+draft, read+write.
Доступные действия. Что агент умеет делать. Например, чтение, расчёты, формирование документа, отправка сообщения Напарнику, постановка задачи. Записи и внешних коммуникаций по умолчанию нет.
Взаимодействие с другими агентами. Кого вызывает или с кем работает в паре. Например, агент переговоров подтягивает Text2SQL для индексов цен и агент базы знаний для прецедентов.
Ограничения. Что агент сознательно не делает. Хорошо очерченные ограничения на практике экономят много времени на спорах на внедрении.
Бизнес-эффект. Какой эффект ожидается на цифрах. Достаточно одного-двух осмысленных тезисов, без мнимой точности «+12% к марже».
Метрики эффективности. Как мы поймём, что агент работает. Например, время до ответа, точность диагностик, доля сценариев с использованием и так далее.

Карточки приоритетных агентов

Агент промо

Назначение. Разбирает эффективность промо-акций. Что окупилось, что нет, где была каннибализация, где промо просто перенесло продажи во времени без прироста.
Пользователи. Категорийный менеджер, руководитель промо, коммерческий директор.
Типовые вопросы. «Почему акция на молочку не дала ожидаемого роста?», «Сравни эффективность февральских акций по кондитерке», «Где в апреле была каннибализация между промо?», «Готовь разбор летней промо-кампании к комитету».
Используемые данные. Из корпоративного хранилища приходят продажи, маржа, остатки, цены до и после. Из систем промо-планирования берутся параметры акции и план. Данные о конкурентах подтягиваются из внешних источников, если подключены.
Доступные действия. Чтение данных, факторный анализ отклонений, оценка чистого эффекта промо, проверка гипотез о каннибализации, формирование диагностической карточки.
Взаимодействие с другими агентами. Внутри обычно работает связкой с агентом финансового эффекта (тот считает влияние на маржу) и Text2SQL (вытаскивает нужные срезы). По запросу подтягивает агент базы знаний, например, чтобы найти прецеденты похожих акций.
Ограничения. Не запускает и не отменяет промо, не меняет параметры в системе планирования. Готовит разбор прошедших акций и (опционально) готовит рекомендацию для планируемой акции. Дальнейшие действия идут через Напарника и подтверждение менеджера.
Бизнес-эффект. Меньше промо, которые повторяются «по инерции». Раньше виден провал плохой акции, и есть шанс закрыть её или переформатировать на ходу. На горизонте квартала ожидается снижение доли неэффективных промо.
Метрики эффективности. Доля неэффективных промо.

Агент переговоров и поставщика

Назначение. Готовит досье на поставщика и аргументацию к встрече. Подсвечивает сильные и слабые позиции, прецеденты, цифры, которые должны лежать перед менеджером во время разговора.
Пользователи. Категорийный менеджер, руководитель направления, директор по закупкам.
Типовые вопросы. «Поставщик X просит +5% к закупочной цене, встреча завтра», «Подготовь досье на Saverio к четвергу», «Что у нас в прецедентах по делистингу мелких поставщиков», «Что предъявить Danone по SLA за квартал».
Используемые данные. Из корпоративного хранилища берутся закупки, продажи, маржа, доля в категории. Информация о SLA включает фактические fill rate, недопоставки, штрафы. Дополняют картину внешние индексы цен на сырьё и упаковку, а также корпоративная база знаний со стандартами переговоров, прецедентами прошлых уступок и историей переписки с поставщиком.
Доступные действия. Сборка досье, расчёт ключевых индикаторов поставщика, поиск прецедентов, формирование аргументационного пакета, подготовка слайдов по корпоративному шаблону.
Взаимодействие с другими агентами. Вызывает Text2SQL для коммерческих срезов, агент финансового эффекта для оценки последствий уступок, агент базы знаний для прецедентов и регламентов. Часто работает в паре с агентом OOS, если претензия касается поставок.
Ограничения. Не отправляет письма поставщику, не вносит изменения в условия контрактов, не инициирует штрафные процедуры. Это всё проходит через Напарника и через подтверждение менеджера.
Бизнес-эффект. Доля встреч с подготовленным досье растёт с типичных 20% до подавляющего большинства. На переговорной марже это даёт прямой P&L-эффект, на масштабе крупной сети речь идёт о десятках миллионов рублей в год.
Метрики эффективности. Доля переговоров с готовым досье. Оценка качества досье менеджером после встречи. Эффект на бэк-маржу в когорте подготовленных встреч против неподготовленных.

Агент OOS и запасов

Назначение. Отслеживает доступность товара, разбирает причины out-of-stock и предлагает действия. Агент работает преимущественно в фоне и инициативно сигналит, когда видит проблему. Но может работать и по запросу.
Пользователи. Категорийный менеджер, логист направления, операционный руководитель кластера.
Типовые вопросы. «Почему по этим SKU третий день нулевой остаток?», «Какие SKU сейчас под угрозой OOS на следующей неделе?», «Разбери, что произошло с поставками молочки за март», «Где у нас регулярные сбои по фул-фейс на конкретных РЦ».
Используемые данные. Из хранилища приходят остатки на РЦ и в магазинах, продажи, прогноз спроса. Из WMS берутся поставки, графики, фактические даты прихода. SLA-данные поставщиков включают fill rate, отказы, замены. Календарь промо нужен, чтобы понимать ожидаемый всплеск спроса.
Доступные действия. Расчёт текущего и прогнозного OOS, разбор причин (недопоставка, недостаточный заказ, ошибка прогноза, всплеск спроса и так далее), формирование рекомендаций (переключение на альтернативный РЦ, экстренный заказ, временная замена SKU и так далее).
Взаимодействие с другими агентами. Работает в паре с агентом переговоров, когда речь идёт о систематических сбоях у поставщика. Подтягивает агент финансового эффекта для оценки потерянной выручки. Использует Text2SQL для нестандартных срезов.
Ограничения. Не размещает заказы, не меняет графики поставок, не инициирует возвраты. Агент готовит рекомендацию, а менеджер или логист подтверждают.
Бизнес-эффект. Время от появления проблемы до её обнаружения сокращается с часов и дней до минут. Становятся видны раньше системные проблемы у конкретных поставщиков, и появляется фактура для разговора с ними. На полке становится меньше пустых мест, соответственно становится выше выручка категории.
Метрики эффективности. Время от события OOS до алерта. Доля OOS-инцидентов с предложенным решением до принятия менеджером. Динамика fill rate по проблемным поставщикам.

Агент финансового эффекта

Назначение. Считает последствия коммерческих решений. Трансформирует гипотезы на человеческом языке в количественные метрики (цифры например по марже, выручке, оборачиваемости и списаниям).
Пользователи. Любой сотрудник, принимающий коммерческое решение. Это категорийный менеджер, прайс-менеджер, руководитель промо, директор по категориям.
Типовые вопросы. «Что будет с маржой категории, если согласимся на +5% закупочной цены от Danone?», «Сравни два варианта матрицы по эффекту на оборачиваемость», «Если уберём этот SKU, что произойдёт за квартал?», «Посчитай эффект промо на маржу с учётом каннибализации».
Используемые данные. Из хранилища берутся продажи, закупочные цены и цены продажи, маржа, остатки, списания. Финансовые модели и нормативы включают собственные нормы списаний и целевые показатели по марже. Параметры промо подтягиваются для расчёта чистого эффекта.
Доступные действия. Сценарное моделирование, расчёт чистого эффекта решений, сравнение вариантов, формирование короткого финансового резюме для разговора с руководителем.
Взаимодействие с другими агентами. Этого функционального агента вызывают агент промо (эффект акции), агент переговоров (последствия уступок), агент OOS (стоимость потери), агент ассортимента (последствия делистинга), в общем практически все функциоанльные агенты так или иначе с ним взаимодействуют.
Ограничения. Агент фин.эффекта не вносит изменения в финансовые системы, не корректирует нормативы, не утверждает бюджет. Это фактически калькулятор последствий.
Бизнес-эффект. Управленческие решения принимаются с подкреплённой цифровой фактурой, а не «по ощущению».
Метрики эффективности. Доля значимых решений с предварительной оценкой эффекта. Точность прогноза по факту через квартал. Оценка качества разбора менеджером.

Агент встреч и follow-up

Назначение. Этот агент делает работу со встречами более осмысленной. Помогает найти окна в календаре при создании встречи, до встречи он готовит участникам короткий бриф, во время встречи фиксирует договорённости, после превращает их в задачи, рассылает Напарникам участников встреч и (опционально) сам контролирует исполнение.
Пользователи. Любой сотрудник, у которого встречи занимают значимую часть дня. Это категорийный менеджер, руководитель направления, директор.
Типовые вопросы. «Что было на встрече с поставщиком в прошлый четверг?», «Поставь встречу с Петровой на следующей неделе на 30 минут», «Кто что обещал сделать к среде по итогам комитета», «Напомни, на чём мы остановились с Ивановым по промо».
Используемые данные. Календарь сотрудника и его коллег. Транскрипты и расшифровки встреч. Корпоративный мессенджер для напоминаний и сборов статусов. Таск-трекер для постановки задач.
Доступные действия. Поиск свободных слотов, бронирование встреч, формирование повестки, создание и разбор транскрипта, выделение договорённостей и дедлайнов, постановка задач исполнителям, напоминания и эскалации при пропуске сроков.
Взаимодействие с другими агентами. Часто работает в паре с агентом переговоров и агентом базы знаний. Они готовят содержательное наполнение брифа, агент встреч обеспечивает «обвязку», а именно время, формат и постановку задач после.
Ограничения. Не отправляет внешние письма от имени сотрудника без подтверждения, не подтверждает бюджеты и не обещает никаких результатов от лица менеджера. Все исходящие коммуникации идут через явный клик.
Бизнес-эффект. Сотрудник перестаёт быть контролёром. Договорённости со встреч не теряются, follow-up не превращается в работу самого менеджера. На горизонте месяца это видно по сокращению просроченных задач и по числу встреч, которые начинаются с готовой повестки.
Метрики эффективности. Доля встреч с автоматически сформированной повесткой. Доля договорённостей, превратившихся в задачи в течение часа после встречи. Число просроченных follow-up’ов до и после внедрения.

Развитие каталога агентов

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

Агент ассортимента

Помогает работать с матрицей. Подсвечивает, где избыточные SKU, где, наоборот, не хватает позиций под спрос, какие листинги стоят дороже, чем приносят. Полезен в момент пересмотра матрицы и при подготовке ассортиментного комитета.

Агент ценообразования

Анализирует ценовое позиционирование, сравнивает с конкурентами, оценивает эластичность по категориям и подсказывает, где переоценка даст эффект. Тесно связан с агентом финансового эффекта и агентом конкурентного мониторинга.

Агент маржинальности

Раскладывает маржу категории на компоненты (закупочная цена, бэк-маржа, потери, списания, операционные расходы) и помогает понять, где на самом деле теряются деньги. Часто его выделяют как отдельную сущность от агента финансового эффекта, потому что у него свой взгляд. Не «что будет, если», а «что уже происходит».

Агент списаний

Следит за товарами с истекающим сроком, сравнивает фактические списания с нормативом, ищет источник проблемы (заказ, прогноз, размещение на полке и так далее). Работает в паре с агентом OOS и агентом ассортимента.

Агент конкурентного мониторинга

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

Агент клиентских сегментов

Работает с программой лояльности. Сегментирует клиентов, оценивает отклик на промо, помогает строить точечные кампании. Имеет смысл там, где у сети есть собственная программа лояльности и сильные клиентские данные.

Агент прогнозирования

Прогноз спроса по SKU и категориям. Под капотом обычно стоит ML-модель, задача агента состоит в том, чтобы обернуть её в удобный интерфейс, подтянуть промо-календарь и сезонность, сделать прогноз пригодным для разговора. Часто вызывается агентом OOS и агентом ассортимента.

Агент аномалий

Постоянный фоновый мониторинг KPI. Замечает значимые отклонения раньше, чем они доходят до отчёта. Тесно связан с агентом алертов, иногда их объединяют, но архитектурно правильнее держать отдельно. Один ищет аномалии, другой решает, кому и в каком виде о них сообщить.

Агент качества данных

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

Агент регламентов

Поиск по корпоративным правилам и стандартам. Отвечает на вопросы вроде «по какому шаблону подаётся заявка», «какие сроки согласования промо», «что у нас по делистингу мелких поставщиков». Технически близок к агенту базы знаний, и разделение зависит от того, как в сети организовано хранение регламентов.

Агент организационной памяти

Накапливает паттерны успешных решений всей команды. Сюда попадают разборы кейсов, удачные тактики переговоров, нестандартные диагностики. Подробно его роль описана в 05-architecture. Архитектурно это часть слоя памяти платформы, а не обычный функциональный агент со своей предметной областью.

Backlog каталога агентов

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

Агент категорийного аудита, который раз в квартал готовит health-check категории.
Агент «второго мнения» по матрице, играющий роль оппонента перед ассортиментным комитетом.
Агент работы с возвратами и претензиями.
Агент медиа-эффективности (связь маркетинговых бюджетов с продажами).
Агент оценки новых SKU (поддержка решения о листинге новинки).
Агент работы с private label, отдельный профиль работы с собственными торговыми марками.
Агент SLA, сводный мониторинг исполнения обязательств всех поставщиков с регулярной отчётностью.
Агент онбординга нового сотрудника, который собирает на его Напарника необходимый контекст из коллективной памяти, регламентов и истории решений предшественника.

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

Документ описывает каталог функциональных агентов. Пользовательская модель ИИ-Напарника описана в 02-partner. Бизнес-сценарии лежат в 04-usecases. Архитектура, инструментальные политики и Tier-модель автономии разобраны в 05-architecture. Интеграционные паттерны и доступные источники данных собраны в 06-integrations.