Definition. A single agent handles a task with one planning loop; a multi-agent system splits the task across specialized agents coordinated by a router. The split is worth it past a specific complexity threshold, not by default.
Why the default assumption should be single-agent
Multi-agent architecture is often reached for because it sounds more sophisticated, not because the task requires it. Every hand-off between agents is a place context can be lost, latency added, and a new failure mode introduced. The practical default should be: start with one agent, one toolset, one evaluation loop. Split only when a specific, measurable problem shows up that a single agent cannot solve.
The signal that actually justifies splitting
Tool-selection accuracy is the clearest quantitative signal. As the number of tools available to a single agent grows, the model's ability to reliably pick the correct one for a given step degrades — in practice, often somewhere in the 10–20 tool range, depending on how distinct and well-documented the tools are. Past that point, a router that classifies the task and hands it to a specialist agent with a narrower toolset consistently outperforms one generalist agent choosing from a long flat list.
A second, non-quantitative signal is task diversity: if a system needs genuinely different reasoning styles for different sub-tasks — for example, a strict, deterministic style for financial calculations and a more exploratory style for research — separate agents with separate system prompts and possibly separate underlying models handle that better than one agent context-switching between modes.
Multi-agent coordination patterns
- Router + specialists: a lightweight classifier agent reads the task and hands it to the right specialist. Simplest multi-agent pattern, lowest overhead.
- Sequential pipeline: agents run in a fixed order, each consuming the previous agent's output. Predictable, easy to debug, but inflexible if the task doesn't fit the pipeline shape.
- Orchestrator + workers: a central agent maintains the overall plan and dispatches sub-tasks to worker agents, collecting results and re-planning as needed. Most flexible, most engineering overhead.
Compare: single-agent vs. multi-agent
| Single agent, many tools | Multi-agent (router + specialists) | |
|---|---|---|
| Best for | Narrow, well-defined task domains | Broad domains with distinct sub-tasks |
| Tool selection accuracy | Degrades past ~10–20 tools | Stays high — each agent sees a small toolset |
| Debugging | Simpler — one transcript | Harder — requires tracing across agents |
| Latency | Lower — no hand-off overhead | Higher — routing adds a step |
| Cost per task | Lower, one model call chain | Higher, routing plus specialist calls |
What most teams get wrong
The most common mistake is architecting for multi-agent complexity before the single-agent version has actually been built and measured. Without a baseline, there is no way to know whether tool-selection accuracy is really the bottleneck, or whether the problem was a vague system prompt, missing documentation on a tool, or an evaluation set that didn't reflect real usage. Build the single-agent version first, measure where it fails, and split only where the data says to.
Frequently asked questions
When should I split a single agent into multiple agents?
When tool selection accuracy degrades — typically past 10–20 tools — or when a task spans genuinely distinct domains needing different prompts or models.
Does a multi-agent system cost more to run?
Usually yes — routing adds at least one extra model call. Worth it when it buys back tool-selection accuracy or allows smaller specialist models.
Is a multi-agent system harder to debug?
Yes — failures can originate in routing, hand-offs, or any sub-agent, requiring cross-agent tracing most teams underestimate.