Вы уже умеете работать с ИИ. Разделяете задачи между тредами, подключили нужные MCP, научили агентов ходить в рабочие сервисы. Один разбирает код, другой собирает данные, третий готовит материал. Наконец можно заниматься результатом.
И тут компьютер начинает зависать.
В нашей истории подозрение сначала пало на разросшуюся историю чатов. Но за медленным интерфейсом обнаружилось другое: вместе с параллельными сессиями размножались целые комплекты локальных инструментов. В том числе тех, которыми эти задачи вообще не пользовались.
Именно эта инженерная боль стала отправной точкой intData Bridge.
Сначала мы подозревали память. Не ту.
Когда ИИ-приложение начинает вести себя странно, легко решить, что оно «слишком много помнит». У нас действительно накопились большие история и контексты. Мы проверили базы, журналы и дерево процессов, прежде чем что-либо отключать или переносить.
Проверки структуры баз прошли успешно. Свободное место на диске ещё было. А вот под основным экземпляром приложения жило несколько сотен процессов.
Дальше стало интереснее.
У каждого треда оказался свой технический отдел
В замере 24 октября 2026 года нашли 11 повторяющихся комплектов локальных подключений. По 11 экземпляров было у GetCourse, Vakas, amoCRM, UniSender и нескольких других инструментов. Всё дерево основного экземпляра приложения выросло примерно до 570 процессов.
Это не 570 агентов, занятых полезной работой. За одним подключением могли стоять оболочка запуска, Python или Node, дополнительные обёртки и консоль. Один набор сервисов превращался в десятки процессов, а затем этот набор появлялся снова.
В журнале был прямой след: запуск треда, инициализация MCP, старт полного комплекта. Другие волны совпадали с открытием и возобновлением сессий. При этом в просмотренном интервале истории не было вызовов ряда уже запущенных инструментов.
Мы хотели распараллелить работу. Вместе с ней распараллелили обслуживание инструментов.
Числа относятся к одному обследованному окружению. Не каждый процесс удалось привязать к конкретному чату; утечка памяти этим наблюдением не доказана. Но повторяющиеся комплекты были реальными — и уже сами по себе требовали другого подхода.
Почему «просто поставь плагин» перестало хватать
Готовый плагин удобен: установил, подключил аккаунт, получил инструменты. Для одной задачи это может быть отличным решением. Проблема появляется, когда удобство установки принимают за готовую архитектуру параллельной работы.
У локального MCP через stdio клиент запускает сервер как дочерний процесс. Если приложение создаёт отдельное окружение подключений для каждой сессии, вместе с новой сессией может появиться новая копия серверов. Сам факт установки плагина не означает, что его тяжёлая часть будет общей для всех клиентов.
Важно различать два события: инструмент доступен агенту и инструмент действительно вызван. В нашей связке расходы на запуск возникали уже при подготовке окружения. Пользователь ещё не просил работать с CRM, а её подключение уже занимало ресурсы.
Здесь нет противоречия с MCP. Протокол поддерживает и независимый сервер с несколькими клиентами через Streamable HTTP. Вопрос в том, кто владеет процессом сервера и сколько раз запускается интеграционная часть.
Проблема глубже, чем расход памяти
Допустим, компьютер выдержал. Остаются десятки отдельных точек подключения: где-то обновился токен, где-то изменился путь, где-то нужен второй аккаунт того же сервиса. При смене ИИ-клиента окружение приходится собирать ещё раз.
А если автоматизация вообще не использует LLM? Ежедневной сверке по расписанию тоже нужны CRM, таблицы и сообщения. Было бы странно держать нужные ей связи исключительно внутри конфигурации ИИ-агента.
Мы пришли к простой границе: рабочие подключения должны жить дольше отдельного треда и быть полезны разным исполнителям.
Общий мост вместо копии всего стека
В Bridge мы вынесли интеграционную часть в общее ядро. Клиент обращается к нему, а ядро работает с подключёнными сервисами. Новый тред получает вход к этой системе, вместо того чтобы поднимать собственный полный набор интеграций.
Для клиентов со stdio предусмотрен отдельный адаптер: он передаёт MCP-запросы в уже работающее ядро по HTTP. Адаптер не запускает свою копию ядра. Небольшой процесс на стороне клиента может остаться; принципиально то, что за ним больше не должен размножаться весь интеграционный стек.
Больше тредов.
Один общий мост.
12 копий подключений
Упрощённая модель с тремя подключениями. Это схема размножения, а не замер памяти или производительности.
Общее ядро не означает общую бесконтрольную сессию. Аккаунт, права и конкретное действие всё равно нужно выбирать явно. Смысл Bridge — переиспользовать подключения, сохраняя понятные границы работы.
Теперь можно выбирать исполнителя
В нашей работе постоянно нужны Vakas, GetCourse, amoCRM и UniSender. Вокруг них появляются разные задачи: найти сведения, сопоставить записи, подготовить следующий шаг. Подключения к сервисам — повторяющаяся часть; логика каждого процесса — отдельная.
Если условие однозначно, его удобно описать правилом. Проверить статус по идентификатору, выбрать ветку, подготовить уведомление — для этого не обязательно вызывать модель.
LLM полезна, когда нужно понять свободный текст, собрать смысл из разных источников или подготовить человеческий черновик. Человек нужен там, где требуется оценка и ответственность за решение. Все трое могут использовать один интеграционный слой.
Связи сохраняются.
Исполнитель меняется.
Однозначное условие выбирает заранее заданное действие. Модель в этом процессе не участвует.
Что я предлагаю бизнесу
Эта история началась с эксплуатации агентов, но вывод шире: автоматизация должна убирать повторяющуюся работу и оставаться управляемой, когда задач становится больше.
Я помогаю найти такую работу, разобрать процесс и собрать решение. Сначала определяем исходное событие, нужные данные, действие и признак успеха. Затем выбираем правила, LLM или их сочетание. Иногда лучший результат даёт обычная автоматизация без единого обращения к модели.
Bridge по подписке
Самостоятельный мост между системами по фиксированной стоимости подписки. Без отдельной платы за настройку самого Bridge. Можно использовать и без LLM.
Автоматизация под задачу
От разбора вашего процесса до интеграций и проверки результата. Сценарии с LLM и без — отдельная проектная работа под конкретную задачу.
Если у вас уже есть зоопарк агентов — или процесс, который держится на ручном переносе данных, — напишите мне в Telegram. Разберём, какие связи стоит сделать общими и где автоматизация принесёт пользу.
Материалы к инженерной части
Собственные наблюдения: диагностика рабочего окружения 24 октября 2026 года; примерно 570 процессов и 11 комплектов — значения на момент обследования, без обещания универсального коэффициента экономии. Адаптер обращается к уже работающему ядру intData Bridge и не запускает его новую копию.
Спецификация транспортов MCP описывает запуск дочернего процесса для stdio и независимый сервер с несколькими клиентами для Streamable HTTP. Поведение конкретного приложения зависит от его реализации.