Внутри ИИ‑Напарника:
как работает оркестр агентов в ритейле

Работа делится на два слоя. Первый слой — это сам ИИ‑напарник, персональный помощник, закреплённый за конкретным сотрудником. Представьте очень толкового аналитика уровня McKinsey, который работает на вас круглосуточно, знает ваши приоритеты и помнит всё, что вы обсуждали вчера или полгода назад. У каждого менеджера свой напарник, и живёт он в том же мессенджере, где менеджер и так переписывается с коллегами и поставщиками. Порог входа стремится к нулю, отдельное приложение осваивать не нужно.

Три свойства напарника я подробно разбирал в первой статье, поэтому здесь только напомню. Он персональный, работает единой точкой входа и держит партнёрскую позицию. Своей повестки внутри компании у него нет, поэтому он может прямо сказать: «Здесь цифры не сходятся» или «В прошлый раз похожее решение просадило маржу».

Второй слой — это функциональные агенты, узкие специалисты, рабочие руки платформы. Один переводит любой ваш вопрос в запрос к базе и приносит нужный срез данных, другой знает наизусть все регламенты и прецеденты компании, третий круглыми сутками сканирует продажи в поиске аномалий. Менеджеру не нужно знать этих спецов в лицо и тем более управлять ими вручную — этим занимается напарник. Он и есть дирижёр. Вы ставите задачу на обычном человеческом языке, а напарник сам решает, кого из агентов позвать, какие данные поднять и что в итоге вам принести.

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

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

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

За час до встречи с поставщиком (она у вас в календаре на 14:00) досье уже собрано, хотя вы напарника об этом не просили.

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

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

Кейс 1. Провал маржи
Менеджер спрашивает, почему в марте просела маржа по молоку в Сибири. Напарник в ответ не выгружает таблицу из BI. Он проверяет цены, логистику и промо, поднимает нужные срезы из хранилища и через минуту отвечает: «По молочке в Сибири минус 9,2% к плану. Причины две. Поставщик X поднял закупочные цены на 8%, это дало минус 5,4 пункта. Плюс недопоставки трёх SKU из‑за того, что уровень сервиса у поставщика упал до 91% при норме 95%. Промоактивность и цены конкурентов в норме». Менеджер уточняет: «Покажи в разрезе магазинов». Ещё тридцать секунд, и выясняется, что половина минуса сидит на 12 магазинах из 87, и все они в одном кластере, где как раз шёл ремонт холодильников. А в конце напарник сам предложит: «Готовить досье к пятничным переговорам с поставщиком X?»

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

Кейс 2. Подготовка к жёстким переговорам с поставщиком
Напарник помнит историю. Если вы полгода назад отказались повышать закупочную цену из‑за плохих поставок, он это не забудет. Приходит письмо от поставщика X с просьбой поднять цену на 5%, встреча завтра, и напарник сам собирает досье: «Помнишь, мы их „морозили“ из‑за недопоставок? Вот чем давить. Индекс цен на сырьё за квартал минус 3%. Недопоставки на 17 миллионов из‑за уровня сервиса 87% при норме 95%. В сентябре они уже уступили под угрозой делистинга (исключения). Слабое место у нас одно, их доля в категории 34%, быстро не заменить. Рекомендую заходить с уровня сервиса, это самая сильная позиция, и попробовать договориться о ретро‑бонусе за квартал». Менеджеру остаётся сесть за стол и торговаться. Полдня на ручной сбор этого досье больше не нужны.

Отдельная история начинается, когда в деле участвует не один напарник. Допустим, вы просите собрать встречу с логистикой и финансами по затянувшимся поставкам. Дальше вы не пишете три письма и не сверяете вручную, кто когда свободен. Ваш напарник связывается с напарниками коллег, те сверяют календари своих сотрудников и их предпочтения по времени, между собой согласуют общий слот, ставят встречу и каждый готовит своему менеджеру короткий бриф под повестку. Со стороны это выглядит как одно сообщение: «Договорились на четверг, 15:00».

Такое общение между напарниками в индустрии называют Agent‑to‑Agent, или A2A (агент — агенту). По умолчанию оно выключено и включается по явному белому списку, где записано, кто и к кому может обращаться. Сами функциональные агенты в этот обмен не входят, они работают только по заданиям своего напарника. За счёт этого поле для лишней коммуникации остаётся узким.

Тот же механизм держит под контролем договорённости. Обещал коллега расчёт к среде — значит в среду ваш напарник сам напомнит об этом напарнику коллеги, получит новый срок и принесёт вам результат. Быть контролёром чужих обещаний больше не нужно.

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

Фундамент — это три сервисных агента, которых сотрудник почти никогда не видит напрямую, хотя без них не работает ничего остального.

Агент‑переводчик на язык данных, он же Text2SQL, превращает вопрос на человеческом языке в запрос к хранилищу и возвращает выгрузку данных. Благодаря ему менеджер получает любые цифры, не зная ни строчки SQL и не выстаивая очередь к аналитику. На нём держатся все остальные.

Агент‑калькулятор последствий считает, что будет с маржой, выручкой, оборачиваемостью и списаниями, если принять то или иное решение. Отвечает на вопрос «А что, если», и к нему обращаются почти все прочие агенты.

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

Поверх фундамента встают два бизнес‑агента.

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

Агент‑монитор продаж круглыми сутками сканирует продажи по множеству срезов (от всей сети до отдельного магазина), ловит аномалию и раскладывает её на причины раньше, чем она попадёт в еженедельный отчёт.

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

По той же причине в стартовый набор пока не входят агент наличия на полке и агент ценового мониторинга. Как полноценные исполнители они появляются на следующем шаге, когда собраны нужные интеграции и заказчик увидел первую отдачу. И вся рассмотренная выше пятёрка агентов — это стартовая гипотеза. Под конкретную сеть состав меняется. Если нет своей системы ведения промо, то агент‑разборщик промо уезжает в бэклог, а его место занимает, например, агент анализа цен и конкурентов. Неизменной остаётся логика. Несколько служебных агентов как фундамент, два‑три бизнес‑агента на самой острой боли, а тонкие сценарии поверх закрывает напарник своими навыками.

Каждый новый агент в каталоге не добавляет менеджеру ни одной новой кнопки, и это принципиально. Появился агент по эластичности цен — и для сотрудника меняется ровно одно: у напарника стало на одну возможность больше. В мессенджере всё та же переписка тем же языком, что и вчера. Именно этим четвёртая эпоха, к которой мы ведём, отличается от третьей, где каждый новый агент означал ещё одну вкладку, ещё один логин и ещё одну вещь, которую надо держать в голове. Где именно проходит грань между навыком напарника и отдельным агентом, разберу подробнее в следующих статьях цикла.

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

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

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

Меня часто спрашивают: «А что, если агент сам решит уволить поставщика или обнулить цены?» Отвечаю, что не решит, и вот как это устроено.

Автономию агентов задаёт трёхуровневая модель — мы в GlowByte называем её Tier‑моделью. На первом уровне агент только читает данные и готовит черновики, письма, досье, разборы. Всё это не выходит за пределы платформы, поэтому разрешено по умолчанию.

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

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

Главная защита работает на уровне платформы. Допустим, кто‑то подсунул агенту письмо с вредоносной инструкцией внутри (в индустрии это называют prompt injection, то есть внедрение скрытой команды в запрос к ИИ; и до конца эта проблема нигде не решена). Даже если агент поверит такому письму, платформа всё равно не даст выполнить действие второго уровня без человеческой кнопки, ведь ограничения зашиты в неё саму, а не в инструкции модели. У агента, которому физически не выдано право писать в систему цен, это право не появится, что бы ему ни написали в чате.

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

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

Граница «напарник не ходит в хранилище напрямую» тоже защищает слабее, чем звучит на первый взгляд. Функциональные агенты вместе покрывают почти все данные, а оркестрировать их напарнику разрешено по определению. Скомпрометированный напарник не напишет SQL сам, зато может вытянуть нужные срезы через своих агентов, шаг за шагом. Мы ограничиваем произвольный прямой запрос, но не суммарную досягаемость данных, и где здесь настоящий периметр, я пока честно оставляю открытым вопросом.

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

Если подытожить, эффект для бизнеса от такой корпоративной мультиагентной платформы — с агентом‑напарником и командой функциональных агентов — появляется с нескольких сторон. Время от вопроса менеджера до обоснованного ответа падает с дней до минут. Менеджер перестаёт работать диспетчером между десятком систем и возвращает внимание туда, где создаёт стоимость, — к решениям. Переговоры, к которым раньше приходили с готовым досье примерно в одном случае из пяти, теперь подготовлены почти всегда, а выигрыш на переговорной марже на масштабе крупной сети — это десятки миллионов рублей в год. Эти цифры я подробнее разбирал в первой статье, поэтому здесь на них не задерживаюсь.

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

Мы строим среду, где опыт лучших сотрудников остаётся внутри компании. Раньше человек работал как живой интерфейс между базами данных, вручную сшивая цифры из пяти систем. Теперь эту черновую работу берёт на себя напарник, а за человеком остаётся то, ради чего он и нужен, — принятие решений.

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