когда вам не нужен multi-agent: как выбрать правильную архитектуру без переусложнения

Если у вас одна бизнес-цель, один поток данных и один понятный результат, почти всегда достаточно single-agent контура. Например, разобрать заявку, собрать сводку по клиенту, сделать черновик ответа и передать задачу в CRM. Здесь нужен не совет из нескольких ролей, а надёжное прохождение одного workflow.

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

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

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

Самая дорогая часть multi-agent системы это не токены, а отладка. Нужно понимать, где потерялся контекст, почему роутер отправил задачу не туда, какой агент внёс ошибку и как воспроизвести проблему на следующем запросе. Для маленькой команды это быстро становится тяжелее, чем сама бизнес-задача.

Переход к multi-agent имеет смысл только после того, как single-agent сценарий упёрся в реальные ограничения: длинный контекст, необходимость параллельных веток или отдельные зоны ответственности. До этого момента результат обычно даёт один agent с инструментами и внятной наблюдаемостью.