Guide

When to use a multi agent system

Published 14 September 2026 · Updated 19 September 2026

A multi agent system costs more than the simpler architectures it replaces, and it is often reached for the wrong reason. The question is never whether several agents could do the job, but whether they do something one well-tooled agent demonstrably cannot, and whether that difference is worth the bill.

Start with the token bill, because it is the honest gate

By Anthropic's own figures, multi agent systems use about 15× more tokens than chat interactions, and they are only economically viable for tasks whose value is high enough to pay for that.

Anthropic published overhead figures from its own multi agent research system. The exact wording: "In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats."

Both multipliers are measured against chat interactions, not against each other: the page does not say a multi agent system uses fifteen times more tokens than a single agent, which is the usual misreading. The wording is hedged and first party too, "In our data" and "about", with no methodology, sample or date range given. Treat it as a directional signal from one team, not an industry measurement.

Anthropic's framing of the cost is blunt: "There is a downside: in practice, these architectures burn through tokens fast." Its conclusion: multi agent systems are only economically viable for tasks whose value is high enough to pay for the increased performance. That is the gate.

The justification test

Multi agent earns its cost through one of three things: genuine specialisation, genuine parallelism, or a checker that catches what one agent would miss. If you cannot point at one, you have a single agent with extra moving parts.

Genuine specialisation. Different subtasks need different context, tools, or models, and cramming them into one context window makes each worse. Anthropic reports that a multi agent system using Claude Opus 4 as lead agent with Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on its internal research eval, on a task like identifying board members of Information Technology S&P 500 companies.

Genuine parallelism. The subtasks are independent, so running them at once is a real latency win, not a bookkeeping exercise. Anthropic reports that having the lead agent spin up 3-5 subagents in parallel rather than serially, with subagents using 3+ tools in parallel, cut research time by up to 90% for complex queries. That is a latency result, not a quality one, unrelated to the 90.2% lift above.

A checker that catches what one agent would miss. A second agent reviewing the first's work against explicit criteria finds errors a single pass does not, because the reviewer is not attached to the reasoning that produced the output. Anthropic describes this pattern in Building Effective AI Agents: "In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop."

That post is often summarised as advising against agents, which it does not do. Its ladder runs from a single LLM call to a workflow to an agent, adding complexity "only when it demonstrably improves outcomes". Multi agent sits a rung past where that ladder stops, so its burden of proof is heavier still.

Five coordination patterns worth knowing

Pick the pattern before the roster: it decides what your failure handling looks like.

Pattern Shape Fits when What breaks first
Supervisor A lead agent assigns work to workers and synthesises their results The task decomposes, but not predictably in advance The lead becomes the bottleneck, and a worker fails quietly
Pipeline Fixed order, each agent's output is the next one's input The stages are genuinely sequential, each with a success predicate A bad output flows downstream instead of stopping the run
Fan out The same input goes to several agents at once, merged at the end The subtasks are independent and the merge rule is obvious The merge, especially when one branch returns nothing
Maker checker One agent produces, another reviews against stated criteria Mistakes are expensive and detectable by inspection The checker itself fails and the system quietly accepts
Swarm Peers work over shared state with no central coordinator The work is exploratory and partial participation is acceptable Nothing terminates

Supervisor is the shape Anthropic calls orchestrator-workers: "In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." LangChain ships the same shape as a named building block outside Anthropic entirely: its langgraph-supervisor package exposes a create_supervisor function, documented simply as "Create a multi-agent supervisor." Hybrids are fine if you name which pattern governs which part of the run.

Shared state is where most multi agent bugs start

A multi agent spec needs a merge strategy for every shared-state field. Not a schema of names and types: a rule, per field, for what happens when two agents write to it. Three kinds cover most fields:

  • Accumulator fields such as history, findings and errors: an append or add reducer, growing over the run with nothing replaced.
  • Overwrite fields such as the current stage, the active agent, or a decision: last write wins. They hold current state, not history, and treating them as accumulators produces a log where you wanted an answer.
  • Role-attributed fields: each entry tagged with the agent that produced it. A downstream agent that cannot tell its own prior output from a peer's draft will treat that draft as settled fact and build on it.

The default failure is not choosing a wrong strategy. It is never writing one down, and discovering at run time that "the plan" is whatever the last agent to finish happened to say.

Spec what happens when ONE agent fails, not the system

Most specs describe what happens when the whole thing falls over. The interesting case is one participant failing while the rest keeps running. Anthropic puts the stakes plainly: "One step failing can cause agents to explore entirely different trajectories, leading to unpredictable outcomes." The right answer depends on the pattern.

  • Supervisor: reassign the failed worker's task a bounded number of times, then escalate. Not retry forever.
  • Pipeline: the failed stage halts the pipeline. No silent skip that hands the next stage missing or garbage input.
  • Fan out: a failed branch must not block the others from merging. The merge records which branches failed and proceeds, flagged as partial.
  • Maker checker: a checker failure never auto-approves the maker's output. Escalate instead.
  • Swarm: a failed agent is simply absent next round; the system tolerates partial participation.

Two things belong in every multi agent spec, whatever the pattern.

  • A hard round ceiling as a circuit breaker, independent of the natural stop condition, so delegation cannot loop forever.
  • Enough observability to tell which agent went wrong: Anthropic reports that production tracing let it diagnose why agents failed, and that it built systems able to resume from where the agent was rather than restarting.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's Multi-Agent build type makes the cost argument part of the output: it emits a COST_JUSTIFICATION section, and its shared-state schema requires a named merge strategy for every field. Its system identity section also has to say when a single well-tooled agent might have sufficed and why multi agent was chosen anyway, which the engine treats as the most common mistake in this build type.

Sources

Suggested internal links