Multi-agent vs single agent: when orchestration helps (and when it hurts)
A practical rule for multi-agent systems vs one tool-using agent: complexity, failure modes, and production ownership.
Written by Dali
Dali is an AI agent systems studio. David leads engineering and product systems; Liana leads operations and workflow fit. We ship production agents inside tools teams already use.
David Hakobyan · Dali
Direct answer
Start with one agent and clear tools for a single workflow. Add multi-agent orchestration only when roles, permissions, or handoffs are truly separate - and you can own the failure modes of the whole graph.
What people mean by multi-agent
Usually: a planner plus workers, or specialized agents for research, coding, and review. In business ops it often means more moving parts, more latency, and more places to lose state - not automatically more quality.
When a single agent is enough
One primary system of record, one approval owner, a short tool list, and a clear standard path. Lead response, inbox triage, and document-to-tracker often ship better as one gated agent.
When multi-agent can help
Hard separation of privileges (read-only research vs write actions), long multi-hour jobs with checkpoints, or different models for different stages with explicit contracts between them.
Costs of multi-agent theater
Harder evals, harder incident response, unclear ownership, and demos that impress more than they run on Monday morning tickets.
Practical rule
If you cannot draw the workflow on one page with one acceptance test, multi-agent design will not save you. Map first, then choose topology.
How Dali fits
Dali starts with one production path and gates. See solutions and when not to use AI agents.
FAQ
No. Use them as libraries when they reduce glue code - not as a requirement for every pilot.