Multi-Agent Systems: When They Help and When They Don't

The diagram is irresistible: a planner agent, a researcher agent, a coder agent, a reviewer agent, arrows between them, a manager on top. It looks like an organization, and organizations work. But agents are not people, and the coordination overhead that organizations absorb with meetings and judgment becomes, in a multi-agent system, lost context, cascading errors, multiplied cost, and an evaluation problem several times harder. The honest current view, including from the teams that build these tools, is that most agent-assisted tasks do not benefit from multiple agents. Some genuinely do. Knowing which is which saves months.

What Multi-Agent Costs

Context is lost at every boundary. Agent A knows things it did not write down; agent B starts from what A wrote down. Every handoff is a compaction, with all the lossy-summary problems that implies.

Errors cascade. A wrong intermediate result from one agent is a confident input to the next, which builds on it. Single agents at least have the chance to notice a contradiction within one context.

Cost multiplies. Each agent re-reads shared context, re-plans, and re-verifies. A task that takes one agent fifteen calls takes a team of four something like forty.

Evaluation gets much harder. One agent has one trajectory to grade. Four agents have four, plus the interactions, plus the question of which one was at fault.

Debugging gets much harder. "Why did it do that" now requires reconstructing a conversation between models.

Where It Earns Its Place

1. Context isolation for exploration. A task that requires reading forty files to answer one question should not put forty files in the main context. Delegate to a subagent with its own window; it returns a paragraph. This is the strongest case, and it is really a single agent with a helper, not a team.

2. Genuinely separable parallel work. Three independent subtasks with no shared state (review three unrelated modules, research three unrelated questions) can run in parallel and merge. The key word is independent; if they need to coordinate, you are back to the costs above.

3. Trust and ownership boundaries. When the other agent belongs to another team or another company, has different permissions, or must be treated as untrusted, a protocol boundary (A2A or an ordinary API) is the right design. This is a multi-agent system by necessity, not by preference.

Outside those three, one agent with a well-scoped tool set, good context engineering, and a solid harness almost always wins.

The Subagent Pattern

Most of the benefit people want from multi-agent comes from subagents: the main agent spawns a scoped helper with its own context window, its own (smaller) tool set, and a narrow task, and gets back a compact result. No coordination protocol, no shared state, no team. The main agent stays in charge of the plan.

main agent (plan, decide, act)
  -> subagent: "find where the tax rate is computed; return file and line"   [read-only tools]
  -> subagent: "review this diff for bugs; return a list"                    [read-only tools]
  -> main agent continues with two short results in context

Use subagents for exploration, review, and parallel independent lookups. Give them fewer tools than the main agent, never more. Treat their output as input to verify, not as truth.

A Decision Procedure

1. Can one agent with better context engineering do this? (Scope tools, reduce tool output, compact well.) Usually yes. Stop here.
2. Is the problem that exploration floods the context? Use a subagent for the exploration. Stop here.
3. Are there independent subtasks with no shared state? Run subagents in parallel and merge. Stop here.
4. Is there a trust or ownership boundary? Design a protocol boundary with authentication and untrusted-input handling. This is the real multi-agent case.
5. None of the above, and you still want a team? Write down the specific failure of the single-agent design that a team fixes. If you cannot, build the single agent.

If You Do Build One

• One agent owns the plan. Others execute scoped tasks and return.
• Every inter-agent message is untrusted input: validate, verify, gate side effects.
• Shared state lives in a store, not in messages. Agents read and write the store; the store is the truth.
• Budget per agent and per task, and a circuit breaker on total cost.
• Evaluate the system end to end on task outcomes, and each agent on its own tasks, separately.
• Trace across agents with one run ID so "why did it do that" is answerable.

What to Practice Next

Take a multi-agent design you have (or have been tempted by) and run the decision procedure. Then build the single-agent-plus-subagents version and compare task pass rate and cost per task on twenty tasks. Most people are surprised in the same direction. The module agents-tools-and-workflow-graphs covers workflow graphs, which are the structured middle ground between one agent and many.