How Many Agents Is Too Many?
Every addition is locally justified, and then the system costs more and answers worse than a simpler one would. Four measurable signals you've overshot — and the merge experiment that settles it.
Multi-agent architectures grow by addition. A specialist here, a coordinator there, a reviewer for quality — each addition locally justified, and at some point the system costs more, takes longer, and produces worse results than a simpler version would have.
There's no universal number, but there are reliable signals for having passed the point, and they're measurable.
The costs that scale with agent count
Boundaries, quadratically-ish. Each agent that talks to others adds interfaces where context is lost. Failure modes multiply faster than participants.
Coordination overhead. Delegating and aggregating cost model calls that do no work on the actual task. Past a certain ratio, most of your spend is agents talking about the task.
Latency, additively. Sequential handoffs add up. Parallel ones are bounded by the slowest, plus aggregation.
Debugging effort, steeply. Tracing a wrong output through six agents means reconstructing six contexts and the transformations between them.
Blast radius for context loss. Information dropped at hop one is unrecoverable at hop six, and nothing signals its absence.
Four signals you've overshot
1. Coordination exceeds work. Count model calls spent delegating, aggregating, and reporting versus calls doing the task. Above roughly a third on coordination, the topology is the product.
2. Agents whose context you can't distinguish. For each agent, name what's in its context that isn't in its parent's. If you can't, it's a prompt wearing a costume — a role description that cost you a handoff.
3. Findings that don't survive. Trace a claim in the final output back to the tool result that produced it. More than two or three transformations and it's a rumour: each hop rephrased it, and nothing verified it against the source.
4. Simplification improves things. The decisive test. Merge two agents into one with a combined prompt and run your evals. If quality holds or improves and cost drops, they were one agent. Teams that run this experiment usually find at least one merge waiting.
The sizing rule
Ask what must be separated, not what must be specialized:
- Different context requirements → separate agent.
- Different permissions → separate agent.
- Different lifecycle (one runs for an hour, one for a second) → separate agent.
- Genuinely parallel independent work → separate agents, or sub-runs.
- Different expertise only → separate prompt, same agent.
Most systems that feel too big have several agents justified by the last line, which needs no boundary at all.
A practical ceiling
Empirically, systems stay comprehensible up to about five agents in one run, and past that debugging cost rises faster than capability.
⚠️ This isn't a rule about parallel workers — twenty sub-runs over twenty documents is fine, because they're instances of one agent doing one thing, not twenty distinct components. The count that matters is distinct roles with distinct contracts, since that's what determines how many boundaries and failure modes you maintain.
Shrinking an overgrown system
In order of return:
- Merge agents that share context and permissions. The safest and usually largest win.
- Replace agents with tools. A sub-agent doing something mechanical — formatting, validating, looking something up — should be a function. No model call, no handoff, deterministic.
- Flatten hierarchies. A supervisor whose only job is passing things to one other agent is a hop with no purpose.
- Collapse sequential chains where every stage needs the previous stage's full evidence. That's one agent with more turns, and it keeps the evidence.
- Keep the splits that isolate — different permissions, different trust levels, genuinely long-running steps. These are the ones earning their cost.
The takeaway
Count coordination calls against work calls, name what each agent's context excludes, and check how many hops separate your conclusions from ground truth. Then run the merge experiment — combine two agents and measure. Multi-agent systems should be assembled from splits you can justify by context, permission, or lifecycle, not by topic. Everything else is a prompt, and it'll do the job better without a boundary in the way.