Доступ к данным
Агенты читают из корпоративных систем нужные им аналитические витрины, операционные системы, документы, почту, календарь и внешние индексы. Каждое обращение проходит через инструментальную политику.
Интеграционный слой
Статус: рабочая версия — можно использовать
Этот документ про интеграционный слой платформы. Какие данные и действия становятся доступны агентам, через какие паттерны это устроено, как платформа подключается к корпоративным и внешним системам и какой минимальный набор интеграций имеет смысл собирать на старте.
Из этого раздела вы узнаете
Заголовок раздела «Из этого раздела вы узнаете»- зачем платформе нужен интеграционный слой и какие четыре задачи он решает
- какие принципы прошиты в каждый коннектор и почему один коннектор пишут один раз для всех агентов
- по каким типам и паттернам группируются интеграции и чем платят за каждый из них
- какой минимальный набор интеграций имеет смысл собирать для MVP и какие системы лежат в справочнике на вырост
Коротко
Заголовок раздела «Коротко»Главная ценность интеграционного слоя в том, что один коннектор пишут один раз, и пользуются им все агенты в рамках своих прав. Количество подключённых систем тут вторично. За счёт этого разрастание каталога агентов превращается в операцию конфигурации.
Платформа сознательно не дублирует корпоративное хранилище и не строит собственный Data Lake поверх корпоративного. Данные остаются в тех системах, где они уже живут, а агенты обращаются к ним через управляемые коннекторы. Это решение продиктовано комплаенсом и эксплуатацией, и подробно разобрано в 05-architecture, раздел «Данные».
Для первой версии концепта список конкретных систем менее важен, чем понимание интеграционных паттернов и их компромиссов. Один и тот же DWH в разных сетях подключается по-разному, и универсальной таблицы коннекторов здесь не получится. Зато паттерны переносимы. Поэтому в этом документе сначала разбираются типы и паттерны интеграций, потом приоритетный набор для MVP, и только в конце справочник возможных систем как опорный материал для разговора с конкретным заказчиком.
Роль интеграционного слоя
Заголовок раздела «Роль интеграционного слоя»Без интеграций мультиагентная платформа превращается в обособленный диалоговый интерфейс. Сотрудник по-прежнему сам идёт за цифрой в BI и за письмом в почту, а статус поставки ему приходится отдельно выяснять в WMS. Ценность Напарника и функциональных агентов раскрывается ровно в той мере, в какой они дотягиваются до корпоративных данных и действий.
Через интеграционный слой агенты закрывают четыре задачи одновременно.
Действия в системах
Помимо чтения, агенты могут исполнять действия (отправить письмо, поставить задачу, обновить статус, забронировать слот). Все действия с внешним эффектом проходят через Tier-модель и явное подтверждение человека. Подробности лежат в 05-architecture, раздел «Human-in-the-loop».
Реакция на события
Платформа сама запрашивает данные и вдобавок получает уведомления от внешних систем о сорванных поставках, аномалиях в продажах, входящих письмах от поставщиков и изменениях статуса в трекере. Каждое такое событие превращается в задачу для агентов мониторинга.
Унификация
Система, подключённая под один сценарий, остаётся доступной для всех следующих агентов. Сотрудник получает нового агента с уже доступными ему данными, без ожидания отдельной интеграции под этот сценарий.
В архитектуре платформы интеграционный контур стоит между инструментами агентов и корпоративными данными. Агенты обращаются к данным через инструменты, а инструменты к системам через коннекторы. Подробное место этого контура в общей картине лежит в 05-architecture, раздел «Карта архитектуры».
Принципы интеграции
Заголовок раздела «Принципы интеграции»Эти принципы прошиты в каждый коннектор и каждую инструментальную политику. Они работают как ограничения при подключении новой системы и как чек-лист при пресейле, когда нужно быстро понять, какие риски и сложности возникнут в конкретном ИТ-окружении заказчика.
Один коннектор для всех агентов
Систему подключают один раз на уровне платформы. Дальше любой агент, у которого в инструментальной политике стоит право пользоваться этим коннектором, получает доступ. Команде внедрения дублировать интеграцию под каждого агента нельзя. Почему именно так, разобрано ниже.
Read-only по умолчанию
Любой новый коннектор подключается в режиме только чтения. Запись добавляется отдельно, под явное обоснование и с явным расширением инструментальной политики. Это снижает класс возможных ошибок и упрощает согласование с информационной безопасностью.
Права сотрудника не расширяются
Когда Напарник идёт за данными, у него доступ ровно такой, какой есть у его сотрудника. Если у менеджера нет доступа к данным соседнего подразделения, у Напарника тоже нет. Подробности механизма лежат в 05-architecture, раздел «Безопасность и права доступа».
Данные не покидают периметр
Платформа не дублирует и не перемещает данные. Запросы исполняются там, где данные физически живут, и в том же сетевом контуре. Если хранилище стоит on-premise, обращение к нему идёт on-premise.
Каждое обращение аудируется
Любой вызов коннектора попадает в журнал. В журнале фиксируется агент-инициатор, инструмент, параметры запроса и сжатый результат. Сотрудник может в один клик провалиться в источник, а комплаенс-офицер может разобрать любой случай по записи.
Стандартный протокол вместо точечных скриптов
По возможности интеграция строится на стандартном протоколе (MCP-подобный коннектор, REST, событийная шина), а не на одноразовых скриптах. Это проще тестировать, проще менять провайдера и проще передавать в эксплуатацию заказчику.
Типы интеграций
Заголовок раздела «Типы интеграций»Интеграции удобно сгруппировать по тому, что именно агент делает с системой. У каждой группы свои паттерны, свои комплаенс-нюансы и свой темп подключения.
Чтение аналитики
Запросы к DWH, BI и семантическим витринам. Сюда же относятся Text2SQL поверх корпоративного хранилища и обращения к семантическому слою. Чаще всего самая зрелая группа в крупной сети.
Чтение операционных данных
Текущая операционная картина (SLA поставщиков, фактические даты прихода, остатки, договоры, цены) на практике берётся из хранилища, куда эти данные регулярно выгружаются из ERP, WMS, TMS и систем ценообразования. Прямое обращение в сами бизнес-критичные системы остаётся исключением (см. ниже про прямое чтение).
Поиск по документам
RAG-контур поверх корпоративных регламентов, прецедентов, аналитических отчётов и стандартов. Может включать также общие папки, корпоративный портал и базы знаний. Подробнее эта группа разобрана в разделе «RAG по корпоративным документам».
Коммуникации
Корпоративный мессенджер, почта, календарь, таск-трекер. Это и пользовательский интерфейс платформы, и источник того, что происходит вокруг сотрудника прямо сейчас. Чувствительная зона по комплаенсу, потому что здесь часто лежат персональные данные и переписка с внешними контрагентами.
Действия в системах
Запись в учётные системы, отправка писем, постановка задач, бронирование слотов в календаре. Все такие интеграции подключаются под Tier 2 как минимум. Подробности подтверждения человеком собраны в 05-architecture, раздел «Human-in-the-loop».
Внешние источники
Индексы цен на сырьё, публичные отчёты, рыночные данные, мониторинг конкурентов. Внешний контент по умолчанию недоверенный и оборачивается специальной разметкой, чтобы агент не выполнил инструкции, спрятанные в письме или на странице. Механизм описан в 05-architecture, раздел «Защита от prompt injection».
В реальном внедрении эти группы редко покрываются одинаково и одновременно. Аналитика обычно зрелая, операционные системы хорошо описаны, но сложные по правам, документы разбросаны по нескольким источникам. От стартовой зрелости каждой группы зависит, какие сценарии и какие агенты войдут в первую фазу пилота. Эта картина важна на пресейле, и подробный разбор лежит в 07-roadmap.
Интеграционные паттерны
Заголовок раздела «Интеграционные паттерны»Один и тот же DWH разные заказчики подключают к платформе через разные паттерны. Иногда выбирают MCP-подобный коннектор, иногда обычный REST-API, иногда выгрузку на S3 раз в сутки. Универсального правильного ответа здесь нет, но есть несколько устойчивых паттернов, и каждый применим в своих условиях.
| Паттерн | Когда подходит | Чем платим | |---|---|---| | API-интеграция | У системы есть аккуратное REST/GraphQL/gRPC API с понятной аутентификацией и нагрузочными ограничениями. | Каждый запрос идёт в систему-источник в реальном времени. Это требует доступности этой системы. | | Event-driven | Система должна реагировать на события сама, не дожидаясь запроса по требованию. Агент отслеживает сорванную поставку, новое письмо или аномалию. | Сложнее наладить надёжную доставку и идемпотентность. Требуется событийная инфраструктура у заказчика. | | Batch | Большие объёмы исторических данных, ночные витрины, тяжёлые отчёты. | Данные в платформе будут отставать на интервал выгрузки. Не подходит для оперативной картины. | | RAG поверх документов | Когда нужно искать смысл в неструктурированных текстах (регламенты, прецеденты, отчёты). | Качество зависит от качества индекса и обновлений. Нужна отдельная процедура переиндексации. | | Tool calling | Любая интеграция, которую агент должен вызывать сам, через стандартизованные функции. | Накладные расходы на проектирование функций и их версионирование. | | MCP-подобный коннектор | Когда нужна управляемая интеграция со стандартным интерфейсом, общая для всех агентов. | Требуется поддержка платформой и провайдером. Выгода видна на масштабе нескольких систем. |
Паттерны можно и нужно комбинировать. Один и тот же DWH может быть подключён через MCP-коннектор для горячих запросов и через batch-выгрузку для тяжёлых аналитических задач. Один и тот же мессенджер может одновременно отдавать события об упоминаниях и принимать команды через API.
API-интеграции
Заголовок раздела «API-интеграции»Это базовый паттерн для большинства корпоративных систем с современным интерфейсом. Платформа делает запрос в систему-источник и возвращает агенту полученный ответ. Преимущество в простоте и в том, что данные приходят свежими, ровно в момент запроса.
В аккуратной API-интеграции аутентификация идёт через сервисную учётную запись с минимальным набором прав, а не через персональный токен сотрудника. Лимиты вызова платформа отслеживает у себя, чтобы один пытливый агент не перегрузил систему-источник, а ошибки и тайм-ауты обрабатывает явно, не превращая их в зависший шаг агента. Версию API при этом закрепляют явно, чтобы обновление на стороне поставщика не сломало работу платформы.
Event-driven интеграции
Заголовок раздела «Event-driven интеграции»Этот паттерн нужен там, где работа агентов начинается не с вопроса сотрудника, а с события в корпоративной среде. Это может быть сорванная поставка, аномалия в продажах, входящее письмо от поставщика или изменение статуса в трекере. Платформа подписывается на поток событий и превращает их в задачи для агентов мониторинга.
Технически это может быть Kafka, Rabbit, Event Hub, Redis Streams или другая событийная шина заказчика. В этом сюжете платформа - один из потребителей. На стороне платформы сидит агент мониторинга или планировщика, который читает поток, фильтрует события по релевантности и доставляет их подходящему Напарнику.
При event-driven интеграциях доставка событий должна быть как минимум at-least-once, иначе часть оповещений будет теряться. Идемпотентность обязательна, потому что одно и то же событие может прийти дважды. Задержка от события до агента считается на этапе проектирования. Полчаса для аналитического оповещения обычно нормально, для срыва поставки уже долго.
Batch-интеграции
Заголовок раздела «Batch-интеграции»Этот паттерн подходит для тяжёлых витрин, исторических массивов и для систем, у которых нет нормального API. Выгрузка идёт по расписанию (раз в сутки, раз в час), результат складывается в стандартное место (S3, локальная папка, внутренняя витрина), и агенты обращаются уже к ней.
Главный компромисс в актуальности. Если данные обновляются раз в сутки, утренний брифинг строится на вчерашней картине. Это терпимо для долгих аналитических разборов и непригодно для оперативной коммуникации. Поэтому batch-интеграции обычно дополняют API-интеграции, а не заменяют их.
RAG по корпоративным документам
Заголовок раздела «RAG по корпоративным документам»Через RAG (Retrieval-Augmented Generation) к платформе подключают всё, что не лежит в реляционной модели: регламенты, стандарты, переговорные прецеденты, аналитические отчёты, инструкции, шаблоны писем и методологии. Агент задаёт семантический поиск по индексу, получает релевантные фрагменты и опирается на них при формировании ответа.
В крупной сети документы редко лежат в одном месте. Часть в SharePoint, часть в Confluence, часть в общих папках, часть в корпоративном портале, часть в почтовых архивах. Поэтому в RAG-контуре обычно работает не один коннектор, а сборщик, который ходит по нескольким источникам, нормализует контент, разбивает его на фрагменты и поддерживает индекс актуальным.
Четыре приёма экономят время на пилоте RAG:
-
Не индексируйте всё подряд. Сначала закрываются конкретные сценарии: регламенты переговоров, прецеденты по поставщикам, шаблоны коммерческих писем, антикризисные протоколы. Индекс «вообще все документы компании» обычно не работает.
-
Контролируйте права доступа: индекс должен помнить, к какому фрагменту у какого сотрудника есть доступ, иначе агент случайно покажет менеджеру коммерческой дирекции содержимое HR-документов. Подробнее эта тема разобрана в 05-architecture, раздел «Безопасность и права доступа».
-
Поддерживайте свежесть индекса. Регламенты обновляются, и устаревший фрагмент в ответе агента это уже ошибка. Переиндексация по расписанию плюс инкрементальные обновления при появлении новых документов.
-
Фиксируйте источник в каждом ответе. Когда агент опирается на фрагмент из регламента, в ответе должна стоять ссылка на конкретный документ и страницу, иначе сотрудник не сможет проверить и платформа теряет доверие.
Tool calling (вызов функций)
Заголовок раздела «Tool calling (вызов функций)»Это стандартный для современных LLM механизм, в котором модель сама решает, какую функцию вызвать и с какими параметрами, а платформа исполняет вызов и возвращает результат в контекст. На уровне архитектуры это та конструкция, через которую агент превращает желание (получить данные, выполнить действие) в реальный вызов конкретного инструмента.
При проектировании функций для агентов имя и описание пишут для модели, а не для разработчика. Нечёткое описание приводит к тому, что модель применяет функцию не туда. Параметры строго типизированы, потому что свободный JSON быстро превращается в источник ошибок. Возвращаемый результат структурирован одинаково для похожих функций, иначе агент учится вручную пересобирать ответы. Каждая функция атомарна и закрывает одно действие. «Универсальная функция работы с заказами» это плохая идея, по тем же причинам, по которым плохая идея универсальный агент.
Подробнее про инструменты и их группировку можно посмотреть в 05-architecture, раздел «Инструменты агентов».
MCP-подобные подходы
Заголовок раздела «MCP-подобные подходы»Model Context Protocol и его аналоги стали в 2025 году стандартом для подключения корпоративных систем к LLM-приложениям. К концу 2025 и началу 2026 MCP поддерживается всеми крупными провайдерами моделей, и для большинства распространённых корпоративных систем уже есть готовые серверы.
Для платформы это удобно по нескольким причинам. Один коннектор подключается один раз, а пользоваться им могут все агенты в рамках своих прав. Авторизация и квоты управляются на уровне сервера, а не вшиваются в каждого агента. Замена провайдера модели не ломает интеграцию, потому что протокол стандартизованный.
В контексте retail это работает так. У сети есть DWH, BI, ERP и WMS. Платформа поднимает четыре MCP-сервера (или использует готовые от поставщика). Дальше агент Text2SQL получает право обращаться к серверу DWH в режиме read, агент OOS получает право обращаться к серверу WMS, агент переговоров читает из DWH через тот же сервер. Когда в каталоге появляется новый агент, он получает доступ к нужным серверам через инструментальную политику, и подключение готово.
Управление доступом к инструментам
Заголовок раздела «Управление доступом к инструментам»Право пользоваться коннектором ещё не значит пользоваться им без ограничений. Доступ к каждой интеграции проходит через ту же иерархию инструментальных политик, что и любой другой инструмент агента. На каждом уровне (платформа, провайдер модели, агент, субагент, песочница) разрешения можно только сузить, но не расширить. Полное устройство этой иерархии с разбором каждого уровня и таблицей политик разобрано в 05-architecture, раздел «Инструментальные политики».
На практике это значит, что один коннектор к DWH подключают на уровне платформы, а право обращаться к нему получают только те агенты, которым он нужен для задачи. Text2SQL читает из хранилища, а агенту OOS тот же коннектор недоступен, потому что в его сценарии хранилище не используется. Так одна интеграция обслуживает несколько агентов, и при этом каждый видит ровно тот срез, который ему положен.
Приоритетные интеграции для MVP
Заголовок раздела «Приоритетные интеграции для MVP»Стартовый набор интеграций должен закрывать понятные сценарии и не требовать инфраструктуры, которой у заказчика ещё нет. Для большинства крупных торговых сетей этот набор устроен примерно одинаково и состоит из пяти позиций.
| Интеграция | Что даёт на старте | Связанные агенты и сценарии | |---|---|---| | DWH, Data Lake, Lakehouse | Аналитическая фактура, продажи, маржа, остатки, цены, промо. Без этого не работает ни один аналитический сценарий. | Text2SQL, агент факторного анализа, агент промо, агент финансового эффекта. Сценарии 2 и 3 из 04-usecases. | | Корпоративные документы и регламенты | RAG-контур для прецедентов, регламентов и стандартов. Главный источник «что у нас уже было в похожих ситуациях». | Агент базы знаний, агент регламентов, агент переговоров (за прецедентами). | | Корпоративный мессенджер, почта, календарь | Канал общения сотрудника с Напарником, источник входящих сигналов, возможность бронировать слоты и ставить задачи. | Все Напарники, агент встреч и контроля договорённостей. Сценарий 5 из 04-usecases. | | BI-системы | Готовые расчёты и нормализованные витрины, поверх которых проще делать факторный анализ и формировать презентации. | Аналитические агенты, агент факторного анализа, генерация презентаций. | | Таск-трекер или система поручений | Точка фиксации действий и follow-up. Без неё договорённости теряются между мессенджером и почтой. | Агент встреч и follow-up, контроль договорённостей у Напарника. |
Этот набор сознательно не включает ни ERP, ни WMS, ни систему ценообразования. Они подключаются на следующих фазах под конкретные сценарии. На старте пилота их отсутствие не блокирующее, потому что данные о поставках и SLA как правило уже доступны в DWH через регулярные выгрузки. Подробное соответствие интеграций фазам внедрения собрано в 07-roadmap, раздел «Приоритетные интеграции для старта».
Справочник потенциальных интеграций
Заголовок раздела «Справочник потенциальных интеграций»Этот раздел не нужно полностью заполнять в первой версии концепта. Он работает как каталог возможностей и опорный материал для разговора с заказчиком. Конкретные системы под конкретного заказчика добавляются точечно, и далеко не все интеграции из списка имеет смысл строить.
DWH, Data Lake, Lakehouse
Заголовок раздела «DWH, Data Lake, Lakehouse»Главный источник аналитических данных для платформы. В крупных российских сетях это чаще всего Greenplum, ClickHouse, реже PostgreSQL или Vertica. Постепенно растёт доля решений на базе Lakehouse (Apache Iceberg, Delta Lake) поверх объектного хранилища.
Платформа подключается к DWH в режиме read-only. Через него работают Text2SQL, агент факторного анализа, агент промо, агент финансового эффекта и агент аномалий (канонические названия агентов и их инструментальные политики разобраны в 03-agents). Семантический слой поверх DWH (если он есть) подключается отдельно и используется агентами для интерпретации полей и метрик. Подробнее про семантический слой написано в 05-architecture, раздел «Семантический слой данных».
Уровень нагрузки от агентов на DWH вырастает заметно, особенно с проактивным циклом. Этот рост закладывается в проектирование: выделенная сервисная учётная запись, отдельная очередь ресурсов и кэширование частых запросов на стороне платформы.
Источник договоров, поставок, заказов, контрактных условий и многих корпоративных справочников. В российских сетях это чаще всего 1С в одной из конфигураций, реже SAP S/4HANA, Oracle EBS или собственная разработка.
По общему принципу (см. «Про прямое чтение из бизнес-критичных систем») платформа берёт данные ERP из его регулярных выгрузок в DWH. Прямое подключение к ERP оправдано только там, где задержка в выгрузке принципиально мешает сценарию или где нужна запись (например, обновление статуса заказа). В этих случаях интеграция собирается точечно, под узкий список операций, и согласуется с владельцем системы. Запись в ERP подключается под Tier 2.
CRM и CDP
Заголовок раздела «CRM и CDP»CRM хранит работу с поставщиками и клиентами, а именно историю контактов, контракты и активные сделки. CDP агрегирует поведение покупателей сети, программу лояльности, отклик на промо.
В коммерческой дирекции крупной сети CRM иногда отсутствует как отдельная система, и его роль закрывают почта, Excel и заметки в мессенджере. В таких случаях коннектор к CRM не нужен, а профили поставщиков ведутся в личной памяти Напарника (как Напарник ведёт профили контактов в личной памяти, описано в 02-partner, раздел «Уровень 3. Коммуникационный помощник»). В сетях с зрелой CRM коннектор полезен для агента переговоров, чтобы тянуть историю контактов и контракты.
PIM и MDM
Заголовок раздела «PIM и MDM»PIM хранит атрибуты товаров, MDM хранит мастер-данные по поставщикам, контрагентам, локациям. Эти системы подключаются для сценариев, в которых нужна точная атрибутика. Например, разбор ассортиментной матрицы или подготовка к листингу нового SKU.
На стартовом наборе MVP эти интеграции обычно избыточны. Они подключаются ближе к зрелости платформы, когда коммерческий контур уже работает.
Система управления отношениями с поставщиками. Закрывает профили поставщиков, контракты, KPI поставщика, тендеры. У большинства крупных сетей SRM как отдельной системы нет. Если есть, коннектор к ней полезен для агента переговоров, потому что он перестаёт собирать профиль поставщика по почте и трекерам.
WMS и TMS
Заголовок раздела «WMS и TMS»WMS отвечает за склады, остатки, фактические поставки и SLA по поставщикам. TMS отвечает за транспорт. Остатки, поставки и SLA для агента OOS и агента аномалий чаще всего читаются из DWH, куда WMS их регулярно выгружает.
Прямое подключение к WMS оправдано только там, где сценарию принципиально нужна свежесть, которую выгрузки в DWH не обеспечивают (например, оперативная картина по конкретному РЦ в момент срыва поставки), и собирается точечно по общему принципу (см. «Про прямое чтение из бизнес-критичных систем»). Запись в WMS как правило не подключается вообще. Запросы на изменение поставок идут через стандартные маршруты компании, а не через агентов. Это сознательное архитектурное ограничение, которое снижает риск неоткатываемых ошибок.
BI-системы
Заголовок раздела «BI-системы»BI как правило уже работает в сети и закрывает регулярную аналитику. На платформе BI используется двумя способами. Первый, через прямое чтение тех же витрин, поверх которых строятся дашборды. Это удобно, потому что витрины уже валидированы. Второй способ, через интеграцию с самим BI-инструментом для встраивания готовых отчётов в ответы агентов и для генерации новых дашбордов под конкретные ситуации.
Распространённые BI-инструменты в российских сетях включают PIX BI, Datalens, Apache Superset, реже Tableau и Power BI на отдельных контурах. Подключение к ним идёт через REST-API инструмента или через прямое чтение витрин в DWH.
Системы ценообразования
Заголовок раздела «Системы ценообразования»Системы ценообразования содержат правила переоценки, ценовое позиционирование, эластичность спроса. На пилоте обычно не входят, потому что аналитический агент в первую очередь работает с историческими ценами из DWH. Подключение нужно для сценариев, в которых агент должен предлагать новую цену или объяснять причину изменения.
Системы промо-планирования
Заголовок раздела «Системы промо-планирования»Аналогично системам ценообразования. Параметры промо обычно сначала берутся из DWH, и подключение к самому планировщику нужно только тогда, когда агент должен моделировать новые акции или валидировать план. На MVP это интеграция второго круга.
Документы и регламенты
Заголовок раздела «Документы и регламенты»Через эту интеграцию агенты дотягиваются до корпоративной базы знаний, переговорных прецедентов, аналитических отчётов, инструкций, шаблонов писем и методологий. В крупной сети всё это редко лежит в одном месте, поэтому работа с группой идёт через RAG-паттерн со сборщиком по нескольким источникам, разобранный в разделе «RAG по корпоративным документам».
Через эту интеграцию работают агент базы знаний, агент регламентов и агент переговоров в части прецедентов. На стартовом наборе MVP эта интеграция входит, потому что без прецедентов и регламентов вес коммерческих сценариев заметно проседает.
Системы документооборота
Заголовок раздела «Системы документооборота»ЭДО хранит контракты, дополнительные соглашения, согласования. Подключение нужно для сценариев, где агент должен поднять конкретный контракт или статус согласования. Интеграция чувствительная по правам и обычно идёт после стандартной RAG-интеграции с базой знаний.
Таск-трекеры
Заголовок раздела «Таск-трекеры»Это точка фиксации задач и договорённостей. В сетях это часто Jira, реже Asana, иногда внутренний инструмент или 1С с надстройкой. Коннектор полезен с первой фазы, потому что без него follow-up Напарника не доходит до сотрудников.
Чтение задач подключается сразу. Запись задач (постановка нового задания, обновление статуса) подключается под Tier 2 и проходит через подтверждение человеком.
Корпоративный мессенджер
Заголовок раздела «Корпоративный мессенджер»Главный пользовательский канал платформы. В российских сетях это чаще всего Telegram или MAX, в более закрытых контурах eXpress, Mattermost, корпоративные сборки Rocket.Chat. Архитектурно это коннектор, а не сама парадигма, и он меняется под политику заказчика. Подробности базового решения по каналу лежат в 01-vision, раздел «Базовые допущения концепта».
Источник писем от поставщиков, коллег и систем. Подключается через стандартные протоколы (IMAP, MS Graph, JMAP) или через корпоративную почтовую систему. Чтение почты входит в стартовый набор, потому что без него Напарник не видит входящих сигналов.
Отправка писем от имени сотрудника подключается под Tier 2. Черновик готовит агент, кнопку «отправить» нажимает человек.
Календарь
Заголовок раздела «Календарь»Через календарь работают сценарии встреч, бронирования, напоминаний. Подключение делается на стороне корпоративного провайдера (Microsoft 365, Google Workspace, Яндекс 360, отечественные альтернативы). Чтение слотов входит в стартовый набор, бронирование под Tier 2, согласование между Напарниками разных сотрудников разбирается в 04-usecases, разделе «Сценарий 5. Межфункциональная встреча через Напарников».
Встречи и видеоконференции
Заголовок раздела «Встречи и видеоконференции»Сюда относятся Zoom, Microsoft Teams, Яндекс.Телемост, отечественные альтернативы. Платформа подключается к ним через корпоративный API или через бот-участника. Этот коннектор нужен для сценариев записи встречи, последующего разбора транскрипта и генерации follow-up.
Подсказки в реальном времени на встрече требуют отдельной обвязки и обычно подключаются позже, как продвинутый сценарий. Подробности этой темы собраны в 02-partner, раздел «Уровни зрелости ИИ-Напарника».
Данные конкурентов
Заголовок раздела «Данные конкурентов»Цены, ассортимент, активные акции, наличие в магазинах. В сетях это часто отдельный сервис парсинга или внешний поставщик. Коннектор подключается для агента конкурентного мониторинга, который стоит во втором круге каталога. Подробности про самого агента лежат в 03-agents.
Рыночные данные
Заголовок раздела «Рыночные данные»Сюда входят индексы цен на сырьё и упаковку, отраслевые отчёты, валютные курсы и макроэкономические показатели. Коннектор полезен для агента переговоров, который опирается на эти данные при формировании аргументации. Источники могут быть платными (CRU, ICIS), бесплатными (Росстат, профильные СМИ) или внутренними индексами компании.
Данные поставщиков
Заголовок раздела «Данные поставщиков»Открытые данные конкретных поставщиков: финансовая отчётность, новости, тендерная активность, изменения в собственности. Коннектор полезен для агента переговоров и для оценки рисков по поставщику. На пилоте эта интеграция обычно не нужна, и достаточно того, что агент опирается на корпоративные данные.
Открытые источники
Заголовок раздела «Открытые источники»К открытым источникам относятся веб-поиск, агрегаторы новостей и отраслевые форумы. Они подключаются через стандартные поисковые API и оборачиваются защитной разметкой как источник недоверенного контента.
Ограничения интеграционного слоя
Заголовок раздела «Ограничения интеграционного слоя»Чтобы концепт не выглядел как идеальная сборка, важно явно зафиксировать ограничения, с которыми столкнётся реальное внедрение.
| Ограничение | Описание | Что делать | |---|---|---| | Зрелость API у систем | У части корпоративных систем API ограниченный или его вовсе нет. Особенно у проприетарных российских ERP и специфичных WMS. | На старте идти через DWH-выгрузки. API подключать в момент, когда без него блокируется конкретный сценарий. | | Качество данных | Если в DWH есть пустые поля, расхождения между справочниками или неактуальные витрины, агенты будут возвращать некачественные результаты. | Подключать агента качества данных, фиксировать критичные витрины и согласовывать SLA с владельцами данных. | | Доступ и комплаенс | Часть данных попадает под дополнительные требования (персональные данные клиентов, финансовые детали, переписка с внешними контрагентами). Подключение требует согласований. | Эти интеграции выносятся из MVP и подключаются точечно после согласования с информационной безопасностью. | | Нагрузка на источники | Проактивный цикл и параллельная оркестрация дают заметный рост запросов к DWH и BI. Без подготовки это может ухудшить работу штатной аналитики. | Выделенная сервисная учётная запись, отдельная очередь ресурсов, кэширование частых запросов на стороне платформы. | | Версионирование интерфейсов | Изменение API на стороне поставщика без согласования ломает работу платформы. | Версия API фиксируется явно, обновления проходят через регрессионный прогон агентов на тестовом контуре. | | Устаревание индекса в RAG | Устаревший фрагмент в ответе агента уже ошибка, подробнее в разделе «RAG по корпоративным документам». | Регулярная переиндексация плюс инкрементальные обновления. Фиксация даты документа в каждом ответе агента. |
Открытые вопросы
Заголовок раздела «Открытые вопросы»Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
📄 Скачать эту страницу в Markdown (.mdx) — для ИИ-агентов и оффлайн-чтения