Документ описывает логическую архитектуру платформы. Из каких блоков она состоит, как агенты взаимодействуют друг с другом, как устроена память и контекст, где проходят границы доверия и как организованы управление, аудит и наблюдаемость.
Платформу удобно представлять как несколько блоков с разной природой и ролью. Наверху находятся сотрудники, которые разговаривают со своими ИИ-Напарниками через корпоративный мессенджер. Под ними работают агенты. Персональные Напарники координируют работу, а функциональные агенты её выполняют, а у каждого агента свой набор инструментов и своя область данных, а права доступа ограничивают, что именно он может с ними делать. Агенты оснащены инструментами, скиллами и памятью и дотягиваются до корпоративных данных через управляемые коннекторы, не перенося данные в свой периметр. Всё это пронизывает сквозной контур безопасности, аудита и управления, который работает на уровне платформы, а не на уровне инструкций модели.
Главная идея архитектуры в том, что безопасность и контроль встроены в саму конструкцию платформы. Агент получает только те инструменты, которые ему явно выданы. Данные менеджера A недоступны Напарнику менеджера B. Критические действия проходят через подтверждение человека. Платформа логирует и аудирует каждое действие каждого агента. Эти свойства не зависят от того, что написано в инструкциях модели, потому что они реализованы на уровне платформы.
Эти принципы прошиты в саму конструкцию платформы. Они работают как ограничения при проектировании новых агентов, интеграций и сценариев. Если конкретное архитектурное решение противоречит любому из них, нужно либо найти другой способ, либо сознательно зафиксировать исключение и его обоснование.
Безопасность по умолчанию
Новый агент по умолчанию не умеет ничего. Каждое право (чтение данных, запись, отправка сообщений, обращение к другим агентам) выдаётся явно. Это принцип наименьших привилегий. Агент видит только то, что ему нужно для работы, и ничего больше.
Изоляция контекстов
Данные одного сотрудника недоступны Напарнику другого, кроме случаев явной межагентской коммуникации по управляемой политике. Сессии, память, файлы и учётные данные изолированы на уровне агента и сессии.
Платформенный контроль
Инструментальные политики (какие инструменты доступны агенту), Tier-модель автономии (какие действия требуют подтверждения человека) и правила межагентского взаимодействия (кто кому может писать) работают на уровне платформы. Никакая модификация промпта не может их обойти.
Аудируемость
Платформа логирует каждый ход (turn) каждого агента. Каждое обращение к данным несёт ссылку на источник. Любое действие любого агента можно воспроизвести по журналу. Журнал аудита встроен в архитектуру и ведётся всегда.
Независимость от вендора
LLM-провайдер, агентный runtime, мессенджер, хранилище данных, MCP-коннекторы рассматриваются как заменяемые компоненты. Конкретные компоненты выбирают под ИТ-политику и инфраструктуру заказчика. Архитектура не завязана на единственного вендора.
Постепенное наращивание
Платформа проектируется так, чтобы можно было начать с минимального контура (один Напарник, два-три функциональных агента, одна интеграция) и наращивать без перестройки. Добавление нового агента, нового коннектора или нового Напарника это операция конфигурации, а не проект архитектурной переработки.
Платформа собирается из нескольких блоков.
Люди и канал. Сотрудник общается с платформой через корпоративный мессенджер с мобильной и десктопной версиями (Telegram, MAX, eXpress, Mattermost или другой инструмент, допустимый ИТ-политикой заказчика). Мессенджер остаётся основным каналом, потому что менеджер и без платформы проводит в нём значительную часть дня, и порог входа стремится к нулю. Через тот же канал приходят уведомления о действиях, инициированных Напарником и другими агентами. Когда Напарник коллеги попросил собрать статусы по промо или согласовал слот для встречи, в мессенджере появляется короткое сообщение о том, что произошло и где требуется явное подтверждение сотрудника. У каждого сотрудника свой бот (или DM-канал), и все сообщения из него маршрутизируются к его персональному Напарнику. Веб-интерфейс и дашборды добавляются позже, под сценарии с длинными аналитическими артефактами, а голосовой канал рассматривается отдельно в 04-usecases. Конкретный механизм маршрутизации собирается под заказчика и вынесен в Backlog как routing topology.
Агенты. Напарник и функциональный агент образуют две роли одной и той же архитектурной сущности. Напарник персональный и координирует работу, функциональный агент же специализирован на исполнении узкого класса задач. Оркестрация описывает, как Напарник вызывает функциональных агентов и связывается с Напарниками коллег, и подробно разобрана в разделах «Модель взаимодействия агентов» и «Оркестрация задач».
Оснащение агентов. Помимо генерации текста агент пользуется инструментами (поверхность действий), скиллами (инструкции, как этими инструментами пользоваться), памятью (личная, корпоративная, коллективная) и командами с workflow. Это экипировка агента, и она разобрана в разделах «Инструменты агентов», «Скиллы», «Команды и workflow» и «Память и контекст».
Данные и путь к ним. Корпоративные системы (DWH, BI, ERP, WMS, CRM, почта, календарь, внешние источники) остаются на месте, а агенты дотягиваются до них через интеграционный контур из MCP-коннекторов, API, RAG и event-шин. Данные не покидают периметр, в котором они были. Эта часть разобрана в разделах «Данные», «Семантический слой данных», «Интеграции» и подробно в 06-integrations.
Контур безопасности и контроля пронизывает все остальные блоки и работает на уровне платформы, а не инструкций модели. В него входят инструментальные политики, Tier-модель автономии, аудит, управление и наблюдаемость. Разобран в разделах «Безопасность и права доступа» и «Управление мультиагентной средой».
Каждый сотрудник работает с одним персональным Напарником. Это полноценный изолированный агент со своей рабочей директорией, своей памятью, своими учётными данными и своей историей сессий. С точки зрения архитектуры у Напарника есть рабочая директория с файлами личности (инструкции по роли и зоне ответственности, профиль сотрудника, стиль коммуникации, оперативная память), хранилище сессий, изолированные учётные данные (профили доступа к корпоративным системам в рамках прав конкретного сотрудника) и набор инструментов для оркестрации, межагентской коммуникации, работы с памятью, уведомлений и расписания. Пользовательская модель Напарника подробно описана в 02-partner.
Напарник не имеет прямого доступа к корпоративному хранилищу. Все обращения к данным идут через функциональных агентов, у каждого из которых свои ограничения. Так устроена граница безопасности. Раз у Напарника нет инструмента для прямого запроса, он оркеструет, но сам по себе не может написать произвольный SQL или прочитать произвольную таблицу.
Функциональный агент это специализированный исполнитель, и каждый закрывает свой класс задач, будь то факторный анализ, Text2SQL, поиск по регламентам, подготовка досье на поставщика или мониторинг аномалий. В архитектурном плане это отдельная сущность со своей рабочей директорией, своей инструментальной политикой и своим набором доступных данных. Один экземпляр функционального агента используется всеми Напарниками в системе, но каждый вызов изолирован в отдельной сессии, и контексты разных вызовов не пересекаются. Подробный каталог агентов и принципы их проектирования описаны в 03-agents.
Агенты в платформе взаимодействуют по нескольким типовым паттернам. Каждый паттерн решает свой класс задач и имеет свои правила безопасности.
Основной паттерн. К Напарнику приходит ситуация от сотрудника, и он делегирует её функциональному агенту (или нескольким). Каждую делегированную задачу Напарник запускает в изолированной сессии. Агент берёт конкретное задание с параметрами, работает асинхронно, возвращает результат.
Когда ситуация требует нескольких агентов, Напарник запускает их параллельно и затем дожидается результатов от всех запущенных задач, прежде чем продолжить. После получения всех ответов Напарник синтезирует итог для сотрудника.
Сотрудник: *«Почему упала молочка в Сибири?»* │Напарник │ ├── → Агент факторного анализа (период, регион, категория) ── параллельно ├── → Агент OOS (SLA, поставки) ── параллельно │ [ждём оба результата] └── ← Результаты: факторная карточка + данные по SLA │ └── → Синтез + следующий шаг → сотрудникуДля подготовки к переговорам Напарник может запустить четыре-пять агентов одновременно.
Напарник (подготовка к переговорам) │ ├── → Агент переговоров (досье поставщика) ── параллельно ├── → Агент финансового эффекта (сценарии) ── параллельно ├── → Агент OOS (SLA и недопоставки) ── параллельно ├── → Агент базы знаний (прецеденты) ── параллельно │ [ждём все четыре результата] └── ← Четыре результата → синтез → сотрудникуПлатформа ограничивает максимальное количество параллельных задач на одного Напарника и глобально. Обычно это до пяти задач на одного Напарника и до десяти глобально. Благодаря этому лимиту платформа удерживает число задач от неконтролируемого роста и бережёт бюджет токенов.
Ключевое свойство делегирования это изоляция контекстов вызовов. Агент факторного анализа, вызванный Напарником менеджера A, не видит контекст вызова от Напарника менеджера B. Это обеспечивается тем, что каждый вызов порождает отдельную сессию со своим ключом.
Напарник может задействовать функционального агента двумя способами. Способ выбирают архитектурно при проектировании конкретного агента, а не на каждом вызове.
Вариант A. Субагент. Субагент это технический способ запустить агента в одноразовой изолированной сессии. Это механизм исполнения, а не отдельный класс сущностей рядом с Напарником и функциональными агентами. Когда Напарнику нужен функциональный агент для разовой задачи (факторный разбор, подготовка досье, расчёт финансового эффекта), платформа порождает субагент с профилем нужного агента. Ему дают ту же инструментальную политику и тот же набор инструкций, что и постоянному экземпляру, но живёт он ровно столько, сколько нужно для одного задания, а после завершения возвращает результат инициатору и автоматически архивируется.
Субагент работает в урезанном контексте. Он не наследует личность инициатора и историю его диалогов, только задание и рабочие инструкции. Это намеренное ограничение. Субагент должен качественно закрыть свою предметную задачу, а не вести диалог. Форма удобна там, где важны изоляция и предсказуемая стоимость. Каждый разовый разбор это отдельный контекст, и он не загрязняет историю предыдущих вызовов. Параллельная оркестрация (Напарник запускает несколько субагентов одновременно для разных частей одной ситуации) тоже хорошо ложится на эту форму. Для субагентов как правило используется более экономичная языковая модель, поскольку их задачи обычно хорошо определены и не требуют сложных рассуждений.
Вариант B. Постоянный агент. Напарник отправляет сообщение в постоянную сессию функционального агента, и тот отвечает в контексте своей накопленной истории. Этот вариант нужен агентам с собственным состоянием. Например, агент алертов хранит историю аномалий, а агент коллективной памяти накапливает знания команды. Их важно вызывать как постоянные сессии, а не пересоздавать при каждом обращении.
Для сложных задач платформа поддерживает иерархию глубиной два. Напарник порождает агента-оркестратора, который сам может запускать агентов-исполнителей. Результаты поднимаются обратно по цепочке. Исполнитель передаёт оркестратору, оркестратор Напарнику, а Напарник сотруднику.
Глубина вложенности ограничена платформой (типично максимум два уровня). Это сознательное решение. Глубокая иерархия создаёт проблемы с наблюдаемостью и контролем бюджета, а на практике двух уровней хватает для подавляющего большинства задач.
Напарники разных сотрудников могут обращаться друг к другу с конкретными запросами. Это управляется через явный белый список на уровне платформы.
Напарник менеджера A: *«Собери статусы по промо у коллег»* │ ├── → Напарник менеджера B: *«Статус промо Q2 по кондитерке?»* ├── → Напарник менеджера C: *«Статус промо Q2 по молочке?»* │ ├── ← Напарник B: *«Акция запущена, ROI +12%, каннибализация 8%»* ├── ← Напарник C: *«Акция перенесена на июль, бюджет утверждён»* │ └── Синтез → менеджеру AA2A-коммуникация по умолчанию выключена. Включается явно и содержит белый список допустимых пар. Функциональные агенты в A2A-список не входят. Они работают только через делегирование от Напарника.
Та же механика используется для согласования совместных действий, а не только для запроса данных. Например, при постановке межфункциональной встречи Напарник инициатора обращается к Напарникам приглашённых, те проверяют у своих сотрудников предпочтения по слотам и накладывают свободные окна в календаре, между собой согласуют общий слот, ставят встречу и каждый готовит своему сотруднику бриф под её повестку. Со стороны людей это выглядит как одно сообщение «договорились на четверг 15:00», без переписки на троих и без человеческой обвязки. Подробный сюжет такого сценария разобран в 04-usecases, раздел «Межфункциональная встреча через Напарников». Архитектурно он реализуется на тех же механизмах, что описаны выше. A2A работает по белому списку допустимых пар, календарь подключён как инструмент с правом на чтение и бронирование, а постановку встречи в свой календарь каждый сотрудник подтверждает явно.
Часть работы выполняется без запроса от сотрудника. Планировщик по расписанию запускает агентов мониторинга. В их числе агенты алертов, аномалий и контроля договорённостей. При обнаружении значимого события агент передаёт результат Напарнику соответствующего сотрудника, и тот формулирует уведомление.
[Планировщик, каждые 2 часа] │Агент алертов ├── Запрос аномалий в хранилище ├── Проверка входящей почты │ ├── Обнаружена аномалия: -15% по кондитерке │ └── → Напарник менеджера: *«⚠️ Аномалия: ...»* │ └── Обнаружено письмо: срыв поставки └── → Напарник менеджера: *«🔴 Критично: ...»*Поддерживаются одноразовые запуски (по абсолютному времени), периодические (через интервал) и классические календарные расписания (день недели, число месяца, время).
Сессия в контексте работы агента это контейнер для одного диалога, аналог ветки переписки. Напарник всегда работает в своей основной сессии, и это его «домашний» диалог с сотрудником. Задачи, запущенные по расписанию, могут выполняться в новых изолированных сессиях или передавать результаты прямо в основную сессию Напарника, в зависимости от настройки.
Каждый порождённый агент работает в изолированной сессии. Он получает конкретное задание с параметрами, доступ к инструментам в рамках своей инструментальной политики и рабочие инструкции (роль, специализация, формат ответа).
Он не получает историю диалога сотрудника с Напарником, данные других сотрудников, инструменты не предусмотренные его политикой и возможность порождать собственных агентов (кроме случаев многоуровневой оркестрации с явным разрешением).
Это свойство критично для безопасности. Функциональный агент не видит ничего лишнего, даже если модель, стоящая за ним, теоретически может интерпретировать более широкий контекст.
Любая задача в платформе проходит через стандартный жизненный цикл.
Инициация. Сотрудник формулирует ситуацию, или триггер (алерт, расписание, событие) запускает задачу автоматически.
Маршрутизация. Напарник определяет, какие функциональные агенты нужны, формулирует задание для каждого с конкретными параметрами.
Делегирование. Напарник порождает изолированные сессии для функциональных агентов. Агенты работают параллельно или последовательно, в зависимости от зависимостей между задачами.
Исполнение. Каждый функциональный агент выполняет свою работу. Он обращается к данным, считает, ищет, формирует структурированный ответ.
Синтез. Напарник получает результаты всех агентов и собирает единый ответ для сотрудника. Это именно синтез. Один главный вывод с доказательной базой под ним, и завершается он предложением следующего шага, но не склейкой отдельных отчётов.
Доставка. Результат возвращается сотруднику в мессенджер. Если требуется действие (отправка письма, постановка задачи), Напарник предлагает его и ждёт подтверждения.
Обратная связь. Сотрудник может пометить результат как верный или неверный, уточнить или дополнить. Напарник запоминает поправку и учитывает её в следующий раз.
Инструменты охватывают всё, что агент может делать помимо генерации текста. Каждый инструмент соответствует конкретному действию (прочитать файл, выполнить запрос к базе данных, отправить сообщение, запустить субагента). Агент получает только те инструменты, которые ему разрешены через инструментальную политику.
Инструменты делятся на встроенные (доступны сразу при создании агента) и плагинные (устанавливаются дополнительно под конкретные задачи).
В контексте retail-платформы инструменты делятся на следующие группы.
Каждый агент в каталоге (03-agents) получает строго ограниченный набор инструментов. Аналитический агент работает только с инструментами чтения данных. Напарник добавляет к ним оркестрацию и память, но не получает прямого доступа к DWH.
Скилл (skill) это файл с инструкциями, который платформа автоматически добавляет в системный контекст агента. Скиллы учат агента когда и как использовать инструменты и сервисных агентов, какие форматы ответов предпочтительны в конкретных ситуациях, как интерпретировать специфические данные или ситуации.
В retail-платформе скиллы быстро становятся одним из главных способов передачи знания между агентами и сотрудниками. Несколько примеров, которые уже работают в демо-контуре Напарника.
Скилл переговоров
Напарник готовит досье к переговорам, оркеструя сразу несколько сервисных агентов. Text2SQL отвечает за коммерческие срезы поставщика, агент базы знаний за прецеденты, агент финансового эффекта за сценарии уступок. Ответы складываются в стандартное досье. По сути это и есть бизнес-агент, у которого нет собственного цикла рассуждений, а есть устойчивый порядок вызова сервисных агентов.
Скилл досье на контрагентов и коллег
Напарник ведёт и по запросу собирает карточки поставщиков, контактных лиц и коллег. В карточку входят доля в категории, история контрактов и поставок, контактные лица, чувствительные темы и предпочитаемый формат общения. Удобно при подготовке к встрече или передаче ведения переговоров другому менеджеру.
Скилл почты и календаря
Напарник разбирает входящую почту, готовит черновики ответов, ищет свободный слот и ставит встречу. Отправка письма и постановка встречи с внешним участником идут под Tier 2, то есть с явным подтверждением сотрудника.
Скилл методологии промо
Скилл «Как считать каннибализацию промо» фиксирует формулу, перечень источников и правила интерпретации. Один и тот же скилл использует и агент промо, и агент финансового эффекта. Раньше методология жила в головах двух-трёх аналитиков, после оформления в скилл стала общей.
Скилл нисходящего разбора аномалий
Задаёт агенту мониторинга порядок обхода категории сверху вниз по множеству разрезов (регион, формат, поставщик, ценовой сегмент), правила отбора значимых отклонений и формат итоговой карточки с графиками. Благодаря этому скиллу разбор воспроизводим от запуска к запуску.
Жизненный цикл скилла напоминает жизненный цикл агента. Сначала паттерн появляется в работе одного агента или Напарника как удачное решение. Дальше его описывают и оформляют как скилл, а если он воспроизводим и применим шире, после валидации куратора его делают доступным всему каталогу. Это один из главных механизмов накопления коллективной экспертизы, и он подробно разобран в разделе «Память и контекст».
Отдельный методологический вопрос, где проходит граница «агент или скилл» разобран в 03-agents, раздел «Когда агент, а когда скилл Напарника».
Основная модель взаимодействия с Напарником остаётся диалоговой. Сотрудник пишет обычным языком, Напарник распознаёт ситуацию и собирает ответ. Так живут все сценарии в 04-usecases и пользовательская модель в 02-partner. Поверх диалога платформа поддерживает два дополнительных механизма для повторяющихся операций, у которых уже сложилась устойчивая форма.
Текстовые команды начинаются с / и обрабатываются платформой напрямую, минуя языковую модель. Они работают мгновенно и не расходуют токены. Например, /статус показывает активные задачи Напарника, /брифинг генерирует утренний обзор, /переговоры Saverio запускает сбор досье по конкретному поставщику. Это удобно для операций, которые менеджер делает каждое утро или несколько раз в день. Команды никогда не заменяют диалог. Если у сотрудника есть нестандартный вопрос, он формулирует его обычным языком, как и раньше.
Программируемые workflow позволяют описать многошаговый процесс как детерминированную последовательность с контрольными точками. Модель здесь идёт по заранее заданному сценарию, свободного диалога с ней нет. Агент выполняет шаги по порядку, в нужных местах останавливается и ждёт подтверждения от сотрудника. Workflow хорошо подходят для стандартных операций, где важна предсказуемость. Например, процедура подготовки к квартальным переговорам включает сбор данных, проверку досье, формирование повестки и финальное согласование с менеджером. Workflow также удобны там, где конкретный сценарий должен исполняться одинаково у всех менеджеров (например, чтобы методология подготовки к ассортиментному комитету не расползалась по людям).
Память платформы устроена в три слоя с разными правилами доступа, наполнения и жизненного цикла. Корпоративная база знаний хранит формализованное организационное знание под присмотром людей. Личная память Напарника накапливает контекст конкретного сотрудника. Коллективная память сохраняет проверенные паттерны и переносит их между людьми, чтобы опыт сильного менеджера не пропадал с его уходом. Так память закрывает сразу три задачи. Сотрудник получает Напарника, который помнит его контекст, организация получает общий доступ к формализованному знанию, а удачный опыт остаётся в команде даже после ухода человека.
Профили контрагентов и коллег стоят особняком. Они не образуют отдельный слой, а живут сразу в личной и коллективной памяти, поэтому ниже разобраны своим разделом.
Пользовательскую сторону, то есть что из этой памяти видит сам сотрудник, описываем в 02-partner, раздел «Персональный контекст пользователя».
Курируемое людьми хранилище формализованного знания. Сюда входят регламенты, стандарты, переговорные прецеденты, аналитические отчёты и нормативные документы. Этот слой доступен агентам только для чтения. Они могут искать и читать, но не могут вносить изменения напрямую.
Обновления в корпоративную базу знаний вносят ответственные сотрудники. Агент базы знаний обеспечивает поиск по ней (через RAG, семантический поиск или полнотекстовый индекс).
У каждого Напарника есть собственное хранилище, в котором накапливается контекст конкретного сотрудника. Сюда попадают оперативные заметки (что на столе, какие дедлайны, какие переговоры активны), история решений (что делал в похожих ситуациях, какие поправки вносил к результатам агентов), профили контрагентов и коллег (стиль, чувствительные темы, прецеденты встреч) и предпочтения по коммуникации (как формулирует письма, какую длину ответов предпочитает).
Этот слой привязан к конкретному Напарнику и изолирован от других сотрудников. Когда Напарнику менеджера B нужны данные из контекста менеджера A, это идёт через межнапарниковую коммуникацию (A2A) с явным разрешением и видимым обменом.
Личная память подчиняется политике хранения. Данные, которые больше не нужны, архивируются или удаляются по расписанию. Политика согласовывается с комплаенсом и зависит от типа данных. Оперативные заметки могут жить 90 дней, история решений хранится год, а профили контрагентов живут, пока существует рабочее отношение.
Обезличенные паттерны успешных решений, выявленные на масштабе команды. Сюда попадают проверенные тактики переговоров и удачные диагностики типовых ситуаций. Этот слой не содержит персональных данных и не привязан к конкретному Напарнику.
Наполнение коллективной памяти - деликатная и нетривиальная задача, требующая внимания. Платформа поддерживает три механизма, применимых в зависимости от зрелости организации и чувствительности данных.
Для низкорисковых операционных паттернов (типовые диагностики, форматы отчётов) агент коллективной памяти может искать повторяющиеся паттерны в сессиях разных Напарников, оценивать их по частоте и устойчивости и автоматически выносить в общий слой. Применимо там, где ошибочная публикация паттерна не создаёт коммерческого риска.
Для коммерчески значимых паттернов (тактики переговоров, нестандартные ходы). Агент предлагает кандидатов, человек-куратор валидирует. Куратор здесь есть роль в организации (например, руководитель направления), формально ответственный за качество коллективной памяти. Этот механизм уже работает в сценариях 04-usecases. Например, успешная переговорная тактика попадает в коллективную память после валидации куратора.
Для регламентов, стратегических решений и прецедентов. Полностью ручное ведение, аналогично корпоративной базе знаний, но с фокусом на паттерны и уроки, а не на формальные документы.
Как уже сказано, профили поставщиков, контактных лиц и коллег не образуют отдельный слой памяти. Они лежат в личной памяти Напарника и частично выносятся в коллективную. Менеджер A видит поставщика через свои переговоры и свой контекст, менеджер B видит того же поставщика через свои. Склеивать эти наблюдения автоматически было бы ошибкой, потому что у разных менеджеров разный фокус и разный уровень отношений с поставщиком.
Менеджеры могут также строить и поддерживать собственные профили менеджеров, которые становятся доступны Напарникам коллег через механизм A2A. Так сотрудники видят зону ответственности друг друга, текущие приоритеты и предпочитаемые форматы коммуникации. Полезно при подготовке совместных переговоров или при передаче ведения переговоров другому менеджеру.
По мере зрелости платформы становится разумно наводить мост между личным и коллективным. Общие факты (fill rate, история контрактов, публичные данные) выносятся в коллективную память, а субъективные наблюдения (стиль переговоров, эмоциональные триггеры) остаются в личном слое. Этот мост требует отдельной проработки под конкретного заказчика и не включается автоматически.
Корпоративные данные остаются в корпоративных системах. Платформа не дублирует хранилище, не создаёт собственный Data Lake и не перемещает данные в свой периметр. Вместо этого агенты обращаются к данным через инструменты (MCP-коннекторы, API, RAG), и каждое такое обращение проходит через инструментальную политику.
Это архитектурное решение важно для комплаенса. Данные не покидают тот периметр, в котором они были до появления платформы. Если хранилище стоит on-premise, то и запросы к нему идут on-premise. Если доступ к хранилищу идёт через VPN или корпоративный шлюз, платформа использует тот же маршрут.
Источники данных удобно разделить на четыре группы. У каждой свой темп обновления, свои паттерны доступа и своя роль в работе агентов.
Аналитический слой
DWH, BI, аналитические витрины, семантические модели. Источник аналитической фактуры. К нему обращаются Text2SQL, агент факторного анализа, агент промо, агент финансового эффекта. Доступ как правило только для чтения, через коннекторы и семантические модели.
Операционные системы
ERP, WMS, TMS, системы ценообразования, промо-планирования, документооборота. Здесь живут поставки, остатки, договоры, цены и фактические даты прихода. На практике агенты редко читают из этих систем напрямую, потому что они бизнес-критичные и к нагрузке на них владельцы относятся ревностно. Основной маршрут идёт через DWH, куда операционные данные регулярно выгружаются. Прямое подключение возможно как исключение под конкретный сценарий, где нужна большая свежесть. Запись в эти системы по умолчанию закрыта и идёт только под Tier 2.
Коммуникационный контекст
Корпоративный мессенджер, почта, календарь, таск-трекер. Источник того, что происходит вокруг сотрудника прямо сейчас. К ним обращаются Напарник и агент встреч и сопровождения договорённостей. Чувствительная зона по комплаенсу, потому что здесь часто лежат персональные данные и переписка с внешними контрагентами.
Документы и регламенты
Корпоративная база знаний, регламенты, стандарты, прецеденты, аналитические отчёты, инструкции. Подключаются через RAG-индекс или семантический поиск. К ним обращаются агент базы знаний, агент регламентов, агент переговоров (за прецедентами). Сюда же относятся внешние источники, такие как индексы цен и публичные отчёты.
В реальном внедрении эти группы редко покрываются одинаково. Аналитический слой обычно зрелый, а семантический ещё нет. Операционные системы хорошо описаны, но сложные по правам. Коммуникационный контекст требует отдельной проработки комплаенса. Документы и регламенты часто разбросаны по нескольким системам, и RAG приходится собирать поверх неоднородного хранения. На пресейле от стартовой зрелости конкретной группы зависит, какие сценарии и какие агенты входят в первый этап пилота. Подробный список систем, протоколов и интеграционных паттернов разобран в 06-integrations.
Сырые данные из хранилища сами по себе мало полезны агентам без понимания их бизнес-смысла. Агент, который не знает, что avg_fill_rate_30d означает средний уровень выполнения заявок за 30 дней в разрезе поставщика, не сможет правильно интерпретировать аномалию в этой метрике.
Семантический слой собирает сразу несколько вещей. Прежде всего это дата-каталог: описание витрин, того, что в них хранится, как связаны таблицы и какие поля для каких задач актуальны. Если такой каталог уже ведётся в хранилище, агенты ходят прямо в него, если нет, платформа держит собственный реестр семантических моделей. Рядом лежит корпоративный словарь. Он закрепляет, что в этой компании понимают под «выполнением заявок», «промо-акцией», «каннибализацией» или «чистым приростом», иначе агенты толкуют одни и те же термины вразнобой. И отдельно прописано, как именно считается каждый основной показатель, с источниками, периодами и правилами отбора, что критично для факторного анализа и Text2SQL.
На практике поддержание семантического слоя в актуальном состоянии вырастает в отдельную операционную задачу. Платформа поддерживает служебных агентов, которые берут эту работу на себя. Агент семантического слоя следит за изменениями в структуре хранилища и обновляет описания витрин. Агент корпоративного словаря помогает вести и пополнять глоссарий. Оба работают как фоновые сервисы и не требуют ручного участия при каждом изменении схемы.
Семантический слой не существует сам по себе, он подключается через тот же интеграционный контур, через который агенты ходят в DWH и BI. На практике это либо отдельный коннектор к корпоративному дата-каталогу (например, DataHub, Amundsen, Atlan), либо собственный реестр платформы, синхронизируемый с источниками. Конкретные интеграционные паттерны и приоритеты подключения семантического слоя в MVP разбираются в 06-integrations.
Через интеграционный контур платформа подключается к корпоративным системам по MCP-коннекторам, API и event-шинам. Каждый коннектор подключается один раз и переиспользуется всеми агентами в рамках их инструментальных политик. Например, новый коннектор к WMS добавляют один раз, и все агенты, которым он нужен, получают к нему доступ, без переделки самих агентов. Так каталог интеграций растёт без перестройки платформы. Как этот контур собирается, переиспользуется и эволюционирует, какие протоколы и паттерны применяются и какой минимальный набор интеграций имеет смысл собирать на старте, подробно разобрано в 06-integrations.
Граница автономии агентов определяет, какие действия агент выполняет сам, какие требуют подтверждения человека и какие допускаются только после явного разрешения с отдельной санкцией.
Tier 1. Чтение и подготовка
Сбор данных, анализ, факторный разбор, подготовка черновиков писем, презентаций, досье. Разрешено по умолчанию. Всё, что делается на Tier 1, остаётся внутри платформы и не покидает её.
Tier 2. Действие после разрешения
Отправка черновика по почте, изменение в учётной системе, бронирование встречи с внешним участником, постановка задачи коллеге. Каждое такое действие требует явного подтверждения сотрудника.
Tier 3. Автономные действия по правилам
Стандартные операции по расписанию или триггеру в заранее согласованных границах. Сюда входят утренние брифинги, контроль договорённостей, рутинные напоминания и стандартное переключение между РЦ при OOS ниже порога. Включается точечно, после периода доверия и согласования с комплаенсом.
| Действие | 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-агента, который запускает SQL во внешнем процессе. Sandbox обрезает сетевые вызовы за пределы разрешённого и ограничивает файловую систему рабочей директорией.
| Уровень политики | Кто настраивает | Что задаёт | |---|---|---| | Глобальная | Администратор платформы | Базовые ограничения, единые для всех агентов | | Провайдер модели | Администратор платформы | Уточнения под конкретного LLM-провайдера | | Агент | Команда внедрения | Рабочий минимум прав конкретного агента | | Субагент | Платформа автоматически | Подмножество прав агента под задачу | | Sandbox | Команда внедрения | Изоляция исполнения произвольного кода |
Как эта иерархия проявляется при подключении конкретных коннекторов, разобрано в 06-integrations, раздел «Управление доступом к инструментам».
Типичные политики для разных типов агентов
| Тип агента | Разрешено | Запрещено | |---|---|---| | Напарник | Оркестрация, межагентская коммуникация, память, уведомления, расписание | Прямой доступ к DWH, запись в системы, системное администрирование | | Аналитический агент | Чтение данных (DWH, Text2SQL) | Запись, отправка сообщений, межагентская коммуникация, браузер | | Агент переговоров | Чтение данных, поиск по базе знаний | Запись, отправка сообщений, администрирование | | Агент алертов | Чтение данных, отправка уведомлений Напарнику | Запись в системы, браузер, администрирование |
Для функциональных агентов, которые выполняют произвольный код (например, Text2SQL с запуском SQL), платформа поддерживает исполнение в изолированном контейнере. Песочница ограничивает среду выполнения. Агент не может выйти за пределы своего контейнера, прочитать файлы других агентов или обратиться к сервисам, не предусмотренным его политикой.
Режим песочницы настраивается по агенту и по сессии. Типичная конфигурация такова, что Напарники работают без песочницы (им нужен доступ к файлам личности и памяти), а функциональные агенты работают в песочнице.
Внешний контент (письма, ответы API, содержимое веб-страниц) оборачивается в XML-теги с пометкой «внешний контент» и предупреждением для модели. Это рекомендательная мера. Она снижает вероятность того, что модель выполнит инструкцию из внешнего содержимого, но не гарантирует этого на 100%.
Основная защита от prompt injection имеет архитектурную природу. Даже если модель интерпретирует внешние данные как инструкцию, инструментальные политики не позволят ей выполнить запрещённое действие. Агент, у которого нет права на запись, не сможет записать, что бы ни стояло во внешнем содержимом.
Платформа полностью логирует каждый ход каждого агента. В журнале фиксируются входящее сообщение (от сотрудника, от другого агента, от планировщика), системный контекст (какие файлы личности были загружены, какие инструменты доступны), каждый вызов инструмента с параметрами и результатом, ответ модели (включая reasoning, если включён) и метрики выполнения (токены, стоимость, время).
Журналы хранятся в структурированном формате (JSONL). Доступ к ним имеет только комплаенс-офицер и администратор платформы. Агенты могут читать историю своих собственных сессий, но не сырые журналы.
Любая цифра, которую возвращает агент, содержит ссылку на источник в корпоративном хранилище. Указываются таблица, период, набор фильтров. Сотрудник может провалиться в источник и проверить. За счёт этого растёт доверие к выводам, и у каждого аналитического вывода есть проверяемая цепочка до источника.
Платформа поддерживает несколько уровней наблюдаемости.
Здоровье платформы
Статус шлюза платформы (gateway), подключённых каналов, активных агентов, очередей задач. Шлюз платформы работает как центральный серверный процесс, который принимает входящие сообщения, маршрутизирует их к агентам, управляет сессиями и контролирует исполнение инструментов. Мониторинг ресурсов охватывает CPU, память, диск и сетевые подключения. Автоматические алерты при сбоях.
Активность агентов
Платформа считает по каждому агенту и в агрегате количество ходов, среднее время ответа, число ошибок и расход токенов. Так видно, кто из агентов перегружен, кто простаивает и где растёт стоимость.
Качество работы
Оценки менеджеров по диагностикам (5-балльная шкала), доля уточняющих вопросов, доля результатов, которые менеджер принял без изменений. Это метрики зрелости, по ним калибруется качество каждого агента.
Безопасность
Попытки доступа за пределами разрешённого, нетипичные запросы, аномалии в использовании инструментов. Автоматический мониторинг плюс ручной аудит по расписанию.
Управление платформой отвечает на вопрос о том, кто и как руководит платформой, агентами и правилами их работы.
Администратор платформы
Управляет конфигурацией. Добавляет агентов, настраивает инструментальные политики, маршрутизацию, интеграции. Обычно это ИТ-команда заказчика совместно с командой внедрения.
Куратор организационной памяти
Валидирует паттерны перед публикацией в коллективную память. Обычно это руководитель направления или эксперт, ответственный за методологическое качество базы знаний.
Комплаенс-офицер
Согласует Tier 3 сценарии (автономные действия по правилам), проверяет политики хранения данных, контролирует доступ к журналу аудита. Обычно это ИТ-безопасность или внутренний аудит.
Владелец бизнес-сценария
Определяет, какие сценарии приоритетны, какие метрики отслеживать, какие пороги чувствительности настроить для алертов. Обычно это руководитель функции (коммерческий директор, директор по категориям).
Каждый новый агент в каталоге проходит стандартный цикл, который включает проектирование, разработку, тестирование, пилотирование и вывод в промышленную эксплуатацию.
Проектирование. Формулировка назначения, определение инструментальной политики, выбор модели, описание формата ответа. Главный артефакт этапа это заполненная карточка агента по шаблону из 03-agents, раздел «Шаблон карточки агента». Поля карточки агента одновременно задают и основу технического задания на разработку, и контрольный список для приёмки на следующих этапах.
Разработка. Создание рабочей директории, написание инструкций, настройка инструментов и коннекторов. Тестирование на исторических данных.
Пилотирование. Ограниченное внедрение у нескольких Напарников. Обратная связь от менеджеров, калибровка качества.
Промышленная эксплуатация. Добавление в общий каталог, доступ для всех Напарников. Мониторинг метрик качества, регулярный пересмотр инструментальной политики.
Эволюция. Обновление по обратной связи, расширение источников данных, уточнение инструкций. Агент живёт и развивается, а не остаётся в первоначальной конфигурации.
Правила A2A-коммуникации (кто кому может писать и по каким поводам) настраиваются на уровне платформы и пересматриваются при изменении организационной структуры. Например, Напарники менеджеров одного направления могут обращаться друг к другу; Напарник руководителя может запрашивать данные у Напарников его подчинённых; функциональные агенты не участвуют в A2A, только принимают делегирование; агент алертов может отправлять уведомления Напарникам, но не может запрашивать у них информацию.
Каждый ход агента означает расход токенов LLM. Ход это один полный цикл работы агента. Он включает получение входящего сообщения, его обработку, вызов нужных инструментов и формирование ответа. Платформа поддерживает несколько механизмов контроля стоимости.
Разные модели для разных ролей снижают стоимость без потери качества. Напарники работают на сильной модели, от неё нужны суждение и синтез под конкретного сотрудника, а функциональные агенты и субагенты могут работать на более экономичной, там нужна надёжность исполнения, а не креативность.
Тайм-ауты ограничивают каждую делегированную задачу по времени. Если агент не вернул результат за отведённое время, задача прерывается.
Лимиты параллелизма ограничивают количество одновременных задач и предотвращают неконтролируемый расход.
Бюджеты задают квоты на агента, на Напарника или на отдел. Опциональная мера, но полезная при масштабировании.
Обнаружение зацикливания. Платформа отслеживает повторяющиеся вызовы инструментов без прогресса и при отсутствии движения к результату предупреждает или останавливает агента, чтобы не расходовать токены впустую.
На уровне концепта рассматриваются три модели развёртывания. Модель выбирают под конкретного заказчика, она зависит от ИТ-политики, комплаенс-требований, бюджета и стратегических предпочтений.
Данные on-premise, LLM через корпоративный шлюз.
Шлюз платформы (gateway, внутренний серверный процесс) и все данные размещаются на инфраструктуре заказчика (on-premise или в корпоративном облаке). Обращения к LLM-провайдеру идут через корпоративный LLM-шлюз (API-шлюз к внешнему провайдеру) с шифрованием, аутентификацией и логированием.
Данные не покидают периметр. Лучшее качество моделей (доступ к ведущим LLM) и быстрый старт без развёртывания локальных моделей. Ограничения связаны с зависимостью от внешнего LLM-провайдера, потому что промпты и ответы проходят через внешний API (хотя данные остаются в запросах агентов, а не передаются напрямую).
Подходит там, где заказчик допускает использование внешних LLM-сервисов через корпоративный шлюз и комплаенс разрешает передачу промптов наружу при условии шифрования и обезличивания.
Всё на инфраструктуре заказчика, включая модели.
Шлюз, данные и LLM-модели размещаются внутри корпоративного периметра. Модели запускаются на собственном оборудовании или на выделенных серверах в корпоративном ЦОД.
Полный контроль. Ничего не покидает периметр. Соответствие самым строгим комплаенс-требованиям. Но требуются вычислительные ресурсы для LLM (GPU-серверы), качество локальных моделей может уступать ведущим провайдерам, и эксплуатация обходится дороже.
Подходит там, где заказчик категорически не допускает передачу любых данных наружу и у него есть собственные GPU-ресурсы или готовность их приобрести.
Данные и модели в российском облачном сервисе.
Использование российских LLM-провайдеров (например, YandexGPT или GigaChat) и российской облачной инфраструктуры. Данные остаются в российской юрисдикции.
Вариант обеспечивает соответствие требованиям по локализации данных и снимает зависимость от зарубежных провайдеров. Качество моделей пока отличается от ведущих провайдеров, хотя разрыв сокращается, а выбор инструментов экосистемы ограничен.
Подходит там, где заказчик обязан хранить и обрабатывать данные на территории РФ или отдаёт стратегическое предпочтение отечественным решениям.
У реального внедрения есть ограничения и риски.
| Ограничение | Описание | Рекомендация | |---|---|---| | Качество LLM | Модели ошибаются. Качество факторного анализа, Text2SQL и интерпретации ситуации полностью зависит от качества модели. Галлюцинации остаются проблемой. | Ссылка на источник в каждом факте. Обратная связь от менеджера. Проверка критических выводов человеком. | | Prompt injection | Внешний контент (письма, URL) может содержать инструкции для модели. | Архитектурная защита (инструментальные политики, Tier-модель). XML-обёртки как дополнительная мера. Tier 2 для чувствительных действий. | | Стоимость токенов | Каждый ход агента расходует токены. На масштабе сотни Напарников стоимость может быть значительной, а проработанной модели стоимости с цифрами пока нет. | Механизмы контроля описаны в «Управлении стоимостью». | | Латентность | Параллельная оркестрация нескольких агентов плюс обращения к DWH могут занимать десятки секунд. | Кэширование частых запросов. Упреждающая подготовка (досье готовится до запроса). Прогрев данных. | | Зависимость от данных | Если DWH содержит некачественные или неполные данные, агенты вернут некачественные результаты. | Агент качества данных в каталоге (03-agents). Проверка целостности данных перед каждым аналитическим запросом. | | Масштабирование | Один шлюз платформы обрабатывает все запросы. На масштабе сотен одновременных пользователей нужна горизонтальная масштабируемость. | Архитектурная готовность к горизонтальному масштабированию. На пилоте не блокер. | | Зрелость организации | Платформа требует готовности к изменениям, а именно формализации процессов, назначения куратора памяти, согласования Tier-модели. Без организационной поддержки техническое внедрение не даёт полного эффекта. | Организационные условия описаны в 07-roadmap. Включаются с Фазы 0. |
Темы, которые можно вынести в отдельные технические замечания по мере необходимости. На первой версии концепта они не требуют полного описания.
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
📄 Скачать эту страницу в Markdown (.mdx) — для ИИ-агентов и оффлайн-чтения