Почему один агент не тянет, а команда агентов доводит дело

Компании внедряют одного универсального бота и ждут, что он закроет весь процесс: примет заявку, сверит остаток, выставит счет, ответит клиенту и поставит задачу в CRM. На демо это выглядит убедительно, но на реальном потоке такой агент начинает путаться, берется за пятое вместо второго, теряет нить в середине цепочки и тихо роняет часть шагов. Проблема не в том, что модель слабая, а в том, что на одного исполнителя навесили сразу пять разных работ

Один агент на длинной задаче держит в голове все сразу: инструкцию, промежуточные данные, десяток инструментов и историю переписки. Чем длиннее цепочка, тем больше в контексте лишнего, и тем выше шанс, что агент перепутает шаг или подставит устаревший факт. Он не умеет сказать себе стоп на середине, перепроверить и передать работу дальше, он просто продолжает генерировать, даже когда уже свернул не туда

Команда агентов устроена иначе. Задача разбивается на роли, у каждой свой узкий участок и свой набор инструментов: один агент принимает и проверяет заявку, второй лезет в CRM и на склад, третий готовит документ, четвертый пишет клиенту. Сверху стоит оркестратор, он не делает работу сам, а раздает шаги нужным ролям и следит, чтобы результат одного дошел до следующего. Каждый участок короткий и проверяемый, поэтому ошибка не тянется через весь процесс, а ловится на своем шаге

Важная деталь в передаче между ролями. Каждый агент отдает следующему не весь свой поток мыслей, а короткий результат в понятном формате: заявка проверена, вот позиции и количества, вот чего не хватает. Следующий агент получает чистый вход, а не пересказ всего разговора, и не тонет в чужом контексте. Оркестратор при этом видит цепочку сверху и может остановить процесс, если один из шагов вернул мусор, а не гнать ошибку дальше по конвейеру

Пример из практики. Отдел заявок пробовал закрыть весь путь одним ботом, тот путал позиции в заказе и иногда отправлял клиенту черновик вместо готового ответа. Путь разложили на роли: приемщик, проверяющий по остаткам, сборщик документа и отправляющий, а оркестратор связал их и добавил простое правило, не отправлять клиенту, пока проверка не поставила ок. Ошибочные письма практически прекратились, а разбор спорных случаев стал занимать минуты, потому что видно, на каком именно шаге и какой агент ошибся

По такому принципу мы в MakeBiz и собираем агентов под процесс: не один всемогущий бот, а набор узких ролей с оркестратором, у каждого своя зона и свои права доступа. Побочный плюс схемы, ее видно насквозь. Когда что-то пошло не так, понятно, какая роль и на каком шаге ошиблась, и чинится именно этот участок, а не вся система целиком. Один агент, который делает все, наоборот превращается в черный ящик: ошибся где-то внутри длинной цепочки, а где именно, уже не разберешь

Ограничение честное: команда агентов не бесплатна и нужна не всегда. Если задача короткая и линейная, ответить на типовой вопрос, достать одну цифру, одного агента более чем достаточно, а оркестрация только добавит лишних звеньев и стоимости. Мультиагент оправдан там, где процесс реально состоит из разных шагов с передачей ответственности, и где ошибка на одном шаге дорого обходится дальше. И роли нужно описать заранее, кто за что отвечает и что считается готовым результатом, иначе агенты будут гонять работу по кругу

Начинать стоит не с вопроса какого бота нам поставить, а с того, как реально устроен процесс: где он разветвляется, где один шаг ждет результата другого, где чаще всего рвется. Там, где шаг один, оставить одного агента. Там, где шагов несколько и они разные, собирать команду с оркестратором. Тогда автоматизация повторяет логику работы, а не пытается впихнуть весь процесс в одну голову