Агент на базе искусственного интеллекта (ИИ-агент) становится частью системы не тогда, когда умеет передавать задачу другому агенту, а когда у передачи есть проверяемый контракт: факты, полномочия, ожидаемый результат, правило отката и ответственный за исключение. Качество такой системы нужно измерять не долей диалогов без оператора, а стоимостью проблемы, которая действительно решена и не вернулась повторным обращением.
Если процесс уже понятен и нужен разбор под свои обращения — это внедрение ИИ-агентов.
Для руководителя продаж, операционного директора или технической команды это меняет порядок проектирования: сначала определяются цена ошибки и критерий устойчивого решения, затем — количество агентов и паттерн оркестрации.
Несколько работающих агентов ещё не образуют систему
Проблема появляется после первых успешных автоматизаций. Один агент отвечает на входящие, второй создаёт сделку в системе управления взаимоотношениями с клиентами (CRM), третий делает саммари звонка. По отдельности каждый выполняет свою функцию. В общей цепочке возникают другие риски:
- классификатор неверно определил намерение, а следующие звенья приняли его вывод за факт;
- при передаче исчезли параметры заказа или последнее обещание менеджера;
- два агента независимо создали одну и ту же сделку;
- инструмент вернул ошибку, но клиент получил ответ об успешном выполнении;
- ни один агент не остановился перед скидкой, отправкой документа или изменением стадии;
- задача ходит между исполнителями по кругу, потому что границы ответственности пересекаются.
В проектах Excella платформа обработала более 6 800 диалогов, а 98% ответов ушли без участия оператора. Но эта цифра сама по себе не доказывает, что проблема клиента решена. Наблюдения из внедрений показывают более важные точки обрыва: потерю контекста при передаче, дублирующую запись в CRM, отсутствие явной эскалации и необратимые действия без подтверждения человека.
Это согласуется с внешними данными о цене слабого управления. В опросе более 2 500 руководителей 74% компаний уже останавливали или откатывали клиентского ИИ-агента: 31% связывали решение с риском раскрытия данных, 22% — с галлюцинациями или репутационным риском, 16% — с отсутствием аудируемости. Это самоотчётный опрос, а не независимый эксперимент, но он показывает, что единицей ущерба может стать не ошибочная реплика, а откат всего внедрения.
Оркестратор — это роли, маршрутизация, состояние и откат
Оркестрация агентов — это управление ролями, маршрутизацией задач, общим состоянием, полномочиями и обработкой ошибок в системе из нескольких ИИ-агентов. Оркестратор определяет, кто выполняет следующий шаг, какие факты ему доступны, как проверить результат и когда остановить цепочку или передать задачу человеку.
Рабочая последовательность выглядит так:
намерение → клиентский контекст и правила → выбор роли → разрешённый инструмент → проверка результата и полномочий → запись состояния → ответ или эскалация
От одиночного агента оркестрация отличается распределением ответственности. От классической автоматизации рабочего процесса — тем, что часть маршрута выбирается на основании вероятностной интерпретации естественного языка. Заранее заданный сценарий может передать заявку из формы в CRM; оркестратор дополнительно решает, относится ли сообщение к продаже, поддержке или претензии и можно ли продолжать без человека.
Такой маршрут нельзя считать надёжным по качеству лучшего звена. Если вероятности успеха независимых этапов равны p₁, p₂, …, pₙ, то вероятность успеха всей операции определяется как P = ∏ pᵢ. Академический аудит 14 750 трасс инструментальных агентов показал, что ошибка параметра приводила к неверному конечному ответу примерно в 62% случаев, с диапазоном 46–73% по исследованным моделям. Авторы также обнаружили, что проверка простым совпадением строк почти случайно согласовывалась с людьми: коэффициент согласия составил 0,049, тогда как между двумя человеческими разметчиками — 0,835. Поэтому журнал самого оркестратора нельзя считать независимым доказательством успеха без ручной проверки выборки.
Правильная оркестрация уменьшает стоимость решения, а не число операторов
Оркестрация спроектирована правильно, если она снижает полную стоимость устойчиво решённой проблемы при неизменных требованиях к качеству, безопасности и полномочиям. Рост доли диалогов без оператора не является достаточным доказательством результата.
Наблюдательный анализ более 32 000 команд связывал активное совместное применение ИИ и операторов с медианой первого ответа 4 минуты против 6 часов, временем решения 25 минут против 32 часов и оценкой удовлетворённости 99% против 89%. Это не контролируемый эксперимент: он не доказывает, что причиной различий была именно оркестрация, но показывает, почему нужно разделять скорость ответа и время фактического решения.
В международном опросе 7 001 потребителя нерешённая проблема снижала оценку понимания запроса на 37% — с 4,44 до 2,78. ИИ получил 4,41 за дружелюбие, но 4,08 за понимание. Вывод для архитектуры простой: вежливый ответ нельзя засчитывать как решённую задачу, если действие не выполнено или клиент вынужден обратиться повторно.
Четыре способа связать агентов и цена каждого паттерна
| Паттерн | Как идёт задача | Когда подходит | Чем платите | Главный контроль |
|---|---|---|---|---|
| Конвейер | Фиксированная последовательность ролей | Стабильный процесс с известными этапами: квалификация → CRM → документ | Ошибка раннего шага распространяется по всей цепочке; растёт задержка | Проверка результата после каждого этапа и остановка при нарушении контракта |
| Роутер | Классификатор выбирает специализированного исполнителя | Входящие обращения разных типов, которым нужны разные данные и полномочия | Ошибка маршрутизации отправляет задачу не той роли | Порог уверенности, резервный маршрут и ручная проверка пограничных классов |
| Супервизор | Центральный оркестратор назначает задачи, проверяет ответы и решает, что делать дальше | Нелинейные процессы, где маршрут зависит от промежуточного результата | Дополнительные модельные вызовы, задержка и сложность отладки | Лимит шагов, журнал решений и независимая проверка выполненных действий |
| Иерархия | Верхний оркестратор управляет супервизорами отдельных функций | Несколько подразделений, источников данных и уровней полномочий | Максимальная сложность наблюдаемости и управления доступом | Сквозной идентификатор проблемы, единая схема состояния и владелец результата |
Конвейер: предсказуемый маршрут с накоплением ошибок
Конвейер подходит, когда этапы нельзя переставлять: извлечь реквизиты, проверить обязательные поля, создать карточку, подготовить документ. Его преимущество — воспроизводимость. Недостаток — тихая ошибка первого звена может доехать до клиента через все последующие.
Каждый шаг должен возвращать не свободный текст, а статус выполнения, использованные факты, результат инструмента и причину остановки. Следующий агент не должен интерпретировать отсутствие результата как успех.
Роутер: один вход и несколько специализированных ролей
Роутер нужен, когда сообщения относятся к разным процессам: новая продажа, действующий заказ, претензия, запрос документов. Он выбирает исполнителя, но не обязан управлять всей задачей после выбора.
Ключевая настройка — не точность на очевидных сообщениях, а поведение на границе классов. Если уверенность недостаточна, безопаснее запросить уточнение или передать обращение человеку, чем принудительно выбрать роль.
Супервизор: решение принимается после каждого шага
Паттерн супервизор в мультиагентной системе полезен, когда следующий шаг нельзя определить заранее. Например, после проверки CRM может потребоваться уточнение у клиента, расчёт, согласование скидки или эскалация.
Супервизор не должен доверять заявлению исполнителя, что действие выполнено. Он проверяет фактический результат: существует ли нужная запись, совпадает ли клиент, разрешена ли операция, не использован ли повторно тот же запрос. В контролируемом опыте runtime-перехватчик снизил галлюцинации одной модели на 23 процентных пункта при контрольной группе из 600 наблюдений, но для другой модели значимого эффекта не было. Следовательно, защитный слой нужно тестировать на конкретной архитектуре, а не считать универсальным решением.
Иерархия: разные контуры и один владелец результата
Иерархия оправдана, когда продажи, поддержка, документы и аналитика имеют разные правила доступа. Локальные супервизоры управляют своими функциями, а верхний уровень хранит статус проблемы и решает, между какими контурами допустима передача.
Если задача укладывается в одного исполнителя и несколько детерминированных проверок, иерархия лишняя. Она добавит точки отказа, расходы и задержку без новой бизнес-функции.
Контекст нужно передавать как проверяемое состояние, а не пересказ диалога
Главная ошибка передачи контекста между агентами — поручить одному агенту пересказать историю другому. Каждый пересказ сжимает исходные данные, смешивает факты с выводами и может незаметно изменить условие задачи.
Рабочий контракт передачи должен содержать:
- сквозной идентификатор проблемы и идентификаторы связанных сущностей;
- подтверждённые факты с указанием источника и времени получения;
- исходное намерение клиента и текущий статус, записанные раздельно;
- уже выполненные действия и их фактические результаты;
- разрешённые инструменты и пределы полномочий следующей роли;
- ожидаемый результат шага и критерий его приёмки;
- открытые вопросы, противоречия и уровень уверенности;
- идентификатор повторяемой операции, защищающий от дублей;
- полный журнал событий, доступный для аудита, но не передаваемый целиком каждой модели.
История сообщений остаётся доказательством, а структурированное состояние — рабочей памятью. Если они расходятся, цепочка должна остановиться. Сжатие контекста допустимо для экономии вычислений, но удалять можно только данные, которые не влияют на решение и не нужны для расследования.
Эскалация должна срабатывать до необратимого действия
Эскалация от агента к оператору — не аварийная кнопка после ошибки, а нормальный маршрут для задач с высокой ценой неверного решения.
Агент обязан остановиться, если:
- действие нельзя безопасно отменить;
- требуется обещание по цене, сроку, скидке или обязательствам компании;
- найдено противоречие между словами клиента и данными системы;
- нужно передать персональные данные в новый контур;
- конфликтный тон или претензия выходят за утверждённый сценарий;
- инструмент не подтвердил выполнение операции;
- достигнут лимит шагов, времени или повторных передач.
Порог нельзя формулировать как общее указание действовать осторожно. Для каждой роли нужны машинно проверяемые условия: допустимая операция, максимальный уровень риска, обязательные поля, разрешённый источник и лицо, которое подтверждает исключение.
Нажимая «Оставить заявку», вы соглашаетесь с политикой обработки персональных данных.
Пять точек, в которых цепочки ломаются на практике
Потеря фактов при передаче
Следующий агент получает резюме без исходных параметров, временных отметок или последнего уточнения клиента. Исправление — структурированное состояние и ссылка на первичный источник каждого критичного факта.
Дублирующая запись в CRM
Повторный запуск после сетевой ошибки создаёт ещё одну сделку, задачу или документ. Исправление — идемпотентность: одинаковая операция с тем же идентификатором не должна создавать новый результат.
Тихая ошибка первого звена
Классификатор выбрал неверный маршрут, а остальные роли не проверили предпосылку. Исправление — валидация критичных входов на границе каждого шага, а не только в начале цепочки.
Отсутствие журнала решений
Команда видит конечный ответ, но не знает, почему был выбран конкретный агент, какие данные он получил и что вернул инструмент. Исправление — единый лог маршрута, версий правил, вызовов и ручных подтверждений.
Зацикливание между ролями
Агенты передают задачу друг другу без изменения состояния. Исправление — лимит переходов, запрет повторного маршрута без нового факта и обязательная эскалация после исчерпания разрешённых попыток.
В проектах с входящими каналами полезно отдельно проверять участок до оркестратора: корректно ли форма создаёт одну сущность, сохраняет источник и связывает дальнейшие действия с тем же обращением. Такой инженерный подход к непрерывному пути показан в кейсе автоматизации обработки заявок; его результаты нельзя переносить на мультиагентную систему без отдельного пилота.
Стоимость устойчивого решения вместо доли автоматизации
Доля диалогов без оператора удобна, но её легко увеличить, просто не передавая сложные обращения человеку. Поэтому для экономики нужна стоимость решённого обращения, учитывающая возвраты и исправления.
| Метрика | Что считается успехом | Что скрывает | Как может дать ложный рост |
|---|---|---|---|
| Доля диалогов без оператора | Диалог не был передан человеку | Нерешённую проблему, ошибочное действие, уход клиента | Запретить или задержать эскалацию |
| Доля повторных контактов | Клиент вернулся с тем же вопросом | Стоимость первичного решения и тяжесть повторной работы | Считать повторный контакт новой темой или новым клиентом |
| Стоимость устойчиво решённой проблемы | Проблема закрыта и не открыта повторно в заданное окно | Требует связать каналы, сущности и затраты | Искажает результат, если менять окно или определение проблемы после запуска |
Формула для расчёта:
Стоимость устойчиво решённой проблемы = (модельные вызовы + инфраструктура + амортизация интеграций + мониторинг и безопасность + труд операторов + повторные контакты и исправления + компенсации и откаты) / число уникальных проблем, не открытых повторно в контрольное окно
Контрольное окно выбирают до пилота — обычно 14–30 дней в зависимости от цикла сделки — и не меняют при сравнении результатов до и после. Обращения из разных каналов нужно объединять по одной проблеме, иначе повторный вопрос на сайте и в мессенджере будет ошибочно посчитан двумя успешными решениями.
В опросе 642 американских компаний системы, которые выполняли действия, показывали 44% предотвращённых обращений к оператору против 33% у систем, только формирующих ответы. Средняя заявленная стоимость закрытого обращения в сегменте сложной программной поддержки составляла 19 долларов. Это самоотчётный коммерческий бенчмарк: сравнивать с ним можно только одинаковые каналы, сложность и определение слова решено. Для российского отдела продаж его следует использовать как ориентир структуры расчёта, а не как целевую стоимость.
Независимых открытых данных 2025–2026 годов, которые доказывали бы влияние именно оркестрации агентов на покупательскую конверсию в сопоставимых контрольной и экспериментальной группах, нет. Поэтому рост выручки нельзя обещать на основании чужих внедрений: его нужно измерять в собственном пилоте.
Персональные данные меняют архитектуру оркестратора
Оркестратор видит больше данных, чем отдельный агент: контакты, историю диалогов, содержимое карточки, записи звонков, документы и результаты действий. Поэтому юридический риск должен входить и в архитектуру, и в расчёт стоимости ошибки.
С 1 сентября 2025 года согласие на обработку персональных данных должно оформляться отдельно от иных документов, которые подтверждает или подписывает субъект. Доказывать наличие согласия обязан оператор — это следует из статьи 9 Федерального закона № 152-ФЗ. Если законного основания для обработки нет, штраф для юридического лица по части 1 статьи 13.11 Кодекса об административных правонарушениях может составить 150–300 тыс. рублей.
При сборе данных граждан России через интернет их первичная запись, систематизация, накопление, хранение, уточнение и извлечение должны выполняться с использованием баз данных в России — часть 5 статьи 18 Федерального закона № 152-ФЗ. Для юридических лиц нарушение локализации влечёт штраф 1–6 млн рублей, повторное — 6–18 млн рублей по частям 8–9 статьи 13.11 Кодекса.
При утечке оператор должен уведомить Роскомнадзор в течение 24 часов, а результаты внутреннего расследования направить в течение 72 часов — часть 3.1 статьи 21 Федерального закона № 152-ФЗ. Неуведомление или просрочка может стоить юридическому лицу 1–3 млн рублей. За саму утечку предусмотрены штрафы 3–15 млн рублей в зависимости от числа субъектов и идентификаторов; за повторную утечку — 1–3% годовой выручки, не менее 20 млн и не более 500 млн рублей. Границы закреплены в частях 11–15 статьи 13.11 Кодекса об административных правонарушениях.
Практическое следствие для архитектуры:
- первичное хранилище и журнал событий проектируются в российском контуре;
- каждому агенту передаётся минимально необходимый набор полей;
- контакты и идентификаторы маскируются там, где они не нужны для действия;
- доступы разделяются по ролям и фиксируются в журнале;
- маршрут во внешние вычислительные контуры проходит отдельную правовую и техническую проверку;
- процедура расследования должна позволять за установленный срок восстановить весь путь данных.
Если оркестратор инициирует рекламные сообщения, одного согласия на обработку персональных данных недостаточно: предварительное согласие на рекламу регулируется отдельно, а автоматическая рекламная рассылка без участия человека запрещена статьёй 18 Федерального закона № 38-ФЗ.
Этот раздел описывает архитектурные последствия действующих норм, но не заменяет правовую оценку конкретного процесса.
Когда оркестрация оправдана, а когда хватит одного агента
Оркестрация нужна не потому, что агентов стало много, а когда у задач различаются источники данных, роли и цена ошибки. Один агент с детерминированными правилами обычно достаточен, если процесс линейный, инструменты одинаковы, а исключения безопасно передаются человеку.
Мультиагентная система оправдана, когда одновременно выполняются несколько условий:
- входящие требуют разных специализированных ролей;
- роли работают с разными системами и уровнями доступа;
- промежуточный результат меняет дальнейший маршрут;
- ошибку нужно локализовать до ответа клиенту;
- отдельные действия требуют подтверждения человека.
Экономический расчёт начинается с базовой стоимости процесса до автоматизации. Затем в него добавляют переменную стоимость автоматического решения, ручную работу после эскалации, повторные обращения, постоянные расходы, безопасность и возможный откат. Если полная стоимость устойчивого решения не снижается, добавление агентов не окупилось, даже если доля ответов без оператора выросла.
Расходы на отдельный входящий канал можно оценить отдельно: методика разобрана в материале о том, сколько стоит AI-виджет для сайта. Для сложной системы дополнительно учитываются интеграции с CRM и внешними системами и независимая AI-аналитика диалогов.
Пилот за четыре недели должен проверить маршрут и экономику
Первая неделя: карта проблем и ролей
Соберите реальные типы обращений, источники данных, действия и исключения. Для каждой проблемы определите владельца результата и цену неверного решения. Зафиксируйте текущую стоимость устойчивого решения и долю повторных контактов.
Вторая неделя: паттерн и контракт состояния
Выберите простейший паттерн, который покрывает маршрут. Опишите схему состояния, обязательные поля, полномочия, идентификаторы операций и условия остановки. Не добавляйте отдельного агента, если достаточно проверяемого правила.
Третья неделя: интеграции, проверки и эскалация
Подключите разрешённые инструменты, идемпотентные операции, журнал решений и ручное подтверждение на необратимых шагах. Проверьте потерю связи, повторный запуск, устаревшие данные, конфликт источников и зацикливание.
Четвёртая неделя: параллельный замер
Сравните одинаковые типы проблем до и после запуска. Проверяйте не только ответы, но и фактические результаты действий. Ручную оценку выборки проводите независимо от журнала оркестратора. Решение о расширении принимайте по стоимости устойчивого решения, повторным контактам и тяжести ошибок.
Так строится внедрение ИИ-агентов в контуре компании: схема процесса, правила доступа и измерение результата остаются частью проекта, а не скрытой логикой модели. Дополнительные сценарии собраны в разделе материалы про ИИ в бизнесе.
Двенадцать решений, которые нужно принять до запуска
- [ ] Определить уникальную проблему клиента, а не отдельное сообщение.
- [ ] Назначить владельца результата для каждого типа проблемы.
- [ ] Зафиксировать границы ролей без пересечения полномочий.
- [ ] Выбрать конвейер, роутер, супервизор или иерархию.
- [ ] Описать структурированный контракт передачи контекста.
- [ ] Отделить подтверждённые факты от выводов агентов.
- [ ] Ввести сквозной идентификатор проблемы и операций.
- [ ] Обеспечить идемпотентность записей в CRM и других системах.
- [ ] Формализовать пороги эскалации и лимит переходов.
- [ ] Поставить подтверждение человека перед необратимыми действиями.
- [ ] Вести журнал маршрутов, данных, решений, версий правил и доступов.
- [ ] Замерить стоимость устойчивого решения и повторные контакты до запуска.
Нажимая «Оставить заявку», вы соглашаетесь с политикой обработки персональных данных.
Вывод
Оркестрация агентов — это инженерная система ответственности, а не чат нескольких моделей. Её устойчивость определяют контракт контекста, идемпотентные действия, проверка фактического результата, явная эскалация и журнал решений.
Главный критерий запуска — снижение стоимости устойчиво решённой проблемы при контролируемом качестве и риске. Доля диалогов без оператора остаётся диагностической метрикой, но не доказательством экономического эффекта.
Если вы проектируете связку из нескольких агентов, начните с карты ролей и стоимости устойчивого решения, замеренной до запуска. Excella разворачивает агентов в контуре компании и в пилоте за четыре недели сравнивает состояние процесса до и после — внедрение ИИ-агентов.