А потом запустили 10 и ... все наладилось.
Между «мы попробовали ИИ» и «мы получили эффект» — пропасть. Большинство компаний застревает где-то посередине: запустили чат-бота, дали ему доступ к базе знаний, подключили к поддержке — а через два месяца поняли, что половину работы по-прежнему делают люди. Дальше расскажем, почему так получается и какой подход даёт другой результат.
Почему один «умный агент» не решает задачу
Многие компании уже пробовали запустить одного ИИ-агента — для поддержки, обработки заявок, разбора резюме или другой рутины. Эксперимент чаще всего заканчивается одинаково. Закрывается часть обращений. В нестандартных ситуациях агент зависает. Остальное дорабатывают вручную.
Проблема не в качестве модели. Проблема в архитектуре — и она проявляется в четырёх типичных сценариях.
Агент теряет нить разговора. Длинный процесс — проверка заказа, согласование, оформление возврата — распадается на этапы. Переходя между ними, агент «забывает» детали, которые были важны в начале. Клиент объясняет одно и то же по второму разу.
Агент делает слишком много сразу. Обновить статус в системе, обработать документ, применить правила возврата, сгенерировать ответ — это четыре разные задачи. Когда одна модель решает их последовательно, качество падает на каждом шаге.
Агент не подключён к рабочим инструментам. Без интеграции с CRM, ERP, почтой, корпоративными мессенджерами и базами знаний у вас не автоматизация, а дорогой собеседник.
Агент не учится на практике. Каждый новый диалог начинается с чистого листа. Типичные ошибки клиентов, внутренние исключения, специфика конкретного бизнеса — ничего не накапливается и не применяется в следующий раз.
Итог: монолитный агент автоматизирует форму, а не суть.
ИИ работает там, где он узкий специалист
Главный вывод последних двух лет звучит просто. Агенты приносят пользу не как замена человека, а как цифровые сотрудники с узкой зоной ответственности и понятным KPI.
Агент по возвратам знает политику компании и проверяет статус заказа. Агент по качеству анализирует фотографии и сравнивает с базой дефектов. Агент по коммуникациям пишет ответы в тоне бренда и отправляет их через нужный канал. Каждый делает одно — и делает это хорошо.
Один такой агент закрывает свою задачу с точностью 90% и выше. Десять таких агентов, собранных в правильную цепочку, закрывают целый процесс. И этот результат стабильно лучше, чем у одного «всеядного» помощника, который вроде бы умеет всё, но ни в чём не достигает рабочего качества.
Именно так устроена ADF (AI DataFabric) — оркестрационный слой нашей платформы HIP 2.0. Дальше расскажем, как такая система собирается на практике.
Архитектура: координатор и команда специалистов
Система строится на двух уровнях.
Агент-координатор — «руководитель проекта»
Принимает входящий запрос, разбивает его на подзадачи и распределяет между исполнителями. Удерживает полный контекст диалога, чтобы при переключении между этапами ничего не терялось. Сам не принимает решений и не пишет финальный ответ — только управляет процессом и следит за состоянием.
Координатор нужен везде, где есть многоэтапные цепочки: согласование договора, обработка заявки на кредит, регистрация нового сотрудника, оформление возврата в e-commerce.
Специализированные агенты — «исполнители»
Каждый работает в своей зоне и подключён к нужным системам.
- Агент проверки данных — обращается к CRM или ERP, проверяет статус клиента, историю операций, условия договора. Применяет правила и возвращает структурированный результат.
- Агент визуального анализа — разбирает фотографии, сканы документов или скриншоты. Используется в страховании (осмотр повреждений после ДТП), ритейле (контроль дефектов товара), медицине (первичный разбор снимков).
- Агент коммуникаций — формулирует ответ клиенту или коллеге, держит фирменный стиль, отправляет через почту, мессенджер или встроенный чат.
- Агент документооборота — заполняет шаблоны, формирует акты и отчёты на основе данных от других агентов.
- Агент мониторинга — отслеживает метрики, шлёт уведомления при отклонениях.
Таких агентов в одной системе могут быть десятки. В сложных отраслевых сценариях — сотни. И тут работает обратное правило: чем подробнее разбит процесс, тем точнее результат каждого шага и всей цепочки.
Как это выглядит на одном процессе
Возьмём типовой возврат в e-commerce. Клиент пишет в чат: «Хочу вернуть кроссовки, которые пришли позавчера, размер не подошёл».
- Координатор разбирает запрос: возврат, причина — размер, нужно проверить условия и оформить.
- Агент проверки данных идёт в ERP, находит заказ, проверяет срок возврата, статус оплаты.
- Агент по политикам сверяет причину со списком допустимых: «не подошёл размер» — да, в течение 14 дней — да.
- Агент документооборота формирует заявление на возврат и сохраняет в системе.
- Агент коммуникаций отвечает клиенту в тоне бренда, прикладывает QR-код для пункта выдачи.
Весь сценарий — около 15 секунд. Оператор подключается, только если что-то идёт не по сценарию: например, клиент пишет про брак, а не про размер, и нужно решение по компенсации.
Память системы
Краткосрочная память — контекст текущего диалога — живёт у координатора. Долгосрочная — это база решённых случаев с метками. Когда оператор поправляет ошибку агента, система запоминает правильное решение и применяет его в следующий раз. Агенты дообучаются постепенно, на реальных данных компании, а не на абстрактных датасетах из открытых источников.
Подводные камни, о которых не пишут в презентациях
Слабая оркестрация. Агент — исполнитель, а не архитектор системы. Чтобы мультиагентные сценарии работали корректно, нужна либо команда дорогих специалистов, которые соберут цепочки с контролем контекста на каждом шаге, либо специализированное ПО — например, ADF в составе HIP 2.0, которое берёт оркестрацию на себя.
Старые системы без API. «Вытащить» данные из системы, развёрнутой 10–30 лет назад, бывает непросто. Программного интерфейса часто нет, форматы данных несовместимы с современными сервисами. Понадобятся адаптеры или ручные интеграции — это раздувает бюджет и повышает риски ошибок. Чтобы их снизить, имеет смысл смотреть в сторону шины данных: в составе HIP 2.0 для этого есть ESB.
Нечёткие входные данные. Агент анализирует только то, что ему дают. Размытая фотография, неполное описание, скан плохого качества — точность падает. Решение: «кормить» модели только качественными данными и заложить правило «если уверенность ниже порога — запросить повторно».
Привычки сотрудников. Первые недели сотрудники интуитивно лезут «помочь» агенту в процессе. Это ломает логику системы. Нужен чёткий протокол: когда человек участвует в цепочке (настройка, изменение архитектуры, разбор нестандартных случаев), а когда — нет (рутинное выполнение).
Стоимость сложных операций. Анализ изображений и обработка длинных документов стоят дороже обычных текстовых запросов. Оптимизируйте: сжимайте данные до нужного размера, кэшируйте повторные обращения по одному объекту, ведите учёт затрат на уровне агента и процесса. Так ROI считается прозрачно.
Что важно запомнить
Оркестрация — это не про выбор модной технологии, а про сборку процесса. Сначала маршрут и зоны ответственности, потом архитектура и модель.
Ценность создают интеграции. Самая сильная LLM без доступа к рабочим системам остаётся витриной для общения. Польза появляется тогда, когда агент действует внутри корпоративного ландшафта.
И участие человека в процессе — не недостаток архитектуры, а её осознанный элемент. Задача автоматизации — снять с людей рутину, а не убрать их из цепочки.
Покажем на вашем процессе
Если у вас есть процесс, в котором уже хочется заменить рутину на мультиагентную систему — расскажите про него. Подберём релевантный сценарий из практики Bercut, покажем, как это работает в ADF, и оценим, что реально автоматизируется в вашем случае. Без презентаций на 60 слайдов — за 30 минут по делу.
Оставить заявку на демо ADF →
Листая дальше, вы перейдёте на hip.bercut.com