---
title: "Интеграционный слой"
description: "С какими корпоративными и внешними системами интегрируется мультиагентная платформа, какие интеграционные паттерны применимы, какой набор интеграций имеет смысл собирать в первую очередь и как этим слоем безопасно управлять."
sidebar:
order: 7
label: "06. Интеграции"
---
import { Card, CardGrid, Steps, Tabs, TabItem, Badge } from '@astrojs/starlight/components';
Этот документ про интеграционный слой платформы. Какие данные и действия становятся доступны агентам, через какие паттерны это устроено, как платформа подключается к корпоративным и внешним системам и какой минимальный набор интеграций имеет смысл собирать на старте.
## Из этого раздела вы узнаете
- зачем платформе нужен интеграционный слой и какие четыре задачи он решает
- какие принципы прошиты в каждый коннектор и почему один коннектор пишут один раз для всех агентов
- по каким типам и паттернам группируются интеграции и чем платят за каждый из них
- какой минимальный набор интеграций имеет смысл собирать для 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 поверх единого индекса упирается в этот потолок раньше, чем в качество ранжирования, и переход к более сложным схемам (графовое представление, переиндексация прав в реальном времени) меняет стоимость владения контуром на порядок. А на какой зрелости платформы этот переход оправдан, концепт не определяет.
:::