Multi-agent vs single agent: когда orchestration помогает (и когда мешает)

Прямой ответ

Начинайте с одного агента и ясных tools для одного workflow. Добавляйте multi-agent orchestration только когда роли, permissions или handoffs действительно разделены - и вы готовы владеть failure modes всего графа.

Что люди имеют в виду под multi-agent

Обычно: planner плюс workers, или специализированные агенты для research, coding и review. В business ops это чаще значит больше moving parts, больше latency и больше мест, где теряется state - не автоматически выше quality.

Когда single agent достаточно

Один primary system of record, один approval owner, короткий список tools и ясный standard path. Lead response, inbox triage и document-to-tracker часто лучше shipping'ятся как один gated agent.

Когда multi-agent может помочь

Жёсткое разделение privileges (read-only research vs write actions), длинные multi-hour jobs с checkpoints, или разные модели на разных стадиях с явными contracts между ними.

Цена multi-agent theater

Сложнее evals, сложнее incident response, неясный ownership и demos, которые впечатляют больше, чем работают на Monday morning tickets.

Практическое правило

Если вы не можете нарисовать workflow на одной странице с одним acceptance test, multi-agent design вас не спасёт. Сначала map, потом topology.

Как помогает Dali

Dali начинает с одного production path и gates. См. solutions и когда не стоит использовать AI-агентов.