Learning objectives. Describe the main multi-agent topologies and their trade-offs; judge honestly when multiple agents beat one; design delegation, communication and conflict resolution; and account for the real cost of coordination.

Core lesson

Multi-agent architecture is a solution to a context and specialisation problem, not a sign of sophistication.

The strongest empirical guidance available comes from teams operating these systems at scale. Anthropic’s published analysis of its multi-agent research system reports that agents consume roughly four times the tokens of a chat interaction and multi-agent systems roughly fifteen times — while also finding that an orchestrator-with-subagents architecture substantially outperformed a single agent on breadth-first research tasks where information exceeds a single context window and subtasks parallelise cleanly. The same analysis is candid about where it does not work: tasks requiring shared context and tight interdependence, where most coding work sits.

Both halves of that finding matter. Multi-agent systems can be dramatically better and cost an order of magnitude more. That is a business decision, not an architectural preference.

ARCHITECT — the topologies

Figure 5a — Single agent and router topologies

Figure 5b — Supervisor–worker and critic topologies

Single agent with many tools. The default. One context, one decision-maker, simplest to debug. Prefer it until you have evidence it is insufficient. Its limits are context exhaustion and instruction dilution when the toolset and rule set grow too large.

Router. A cheap classifier routes each request to a specialist. Low cost, low coupling, easy to test — arguably the highest return-on-complexity pattern in business use.

Supervisor–worker (orchestrator–worker). A lead agent decomposes the objective, delegates to workers, and synthesises results. Workers have clean contexts and narrow tools. This is the workhorse of serious multi-agent systems. Its dangers are lossy delegation (the worker did not receive what it needed) and lossy synthesis (the lead misrepresents what the workers found).

Hierarchical. Supervisors of supervisors. Justified only at genuine organisational scale; every layer adds latency, cost and information loss.

Peer-to-peer / swarm. Agents negotiate without a central coordinator. Interesting research, rarely justified in business today: emergent behaviour is difficult to test, budget or explain to an auditor.

Critic / evaluator–optimiser. A second agent reviews the first’s output against explicit criteria and returns feedback, iterating to a threshold. Effective when quality criteria can be stated clearly. The critic must have a different vantage point — different prompt, different information, ideally a different model — or it will simply agree.

Delegation, communication and conflict

Delegation quality determines system quality. A delegated task must carry the objective, the acceptance criteria, the necessary context, the boundaries and the expected output format. Most multi-agent failures are delegation failures: the worker did excellent work on a subtly wrong interpretation of the task.

Communication. Prefer structured messages with defined schemas over free-form prose between agents. Prose invites drift; schemas can be validated and logged. Shared state — a common scratchpad or store — reduces message volume but introduces concurrency questions: who may write, and what happens on conflict?

Conflict resolution. When two agents disagree, the system needs a rule decided in advance: authority (the designated agent decides), evidence (the position with verifiable sources wins), escalation (a human decides), or abstention (report the disagreement rather than resolving it). The worst outcome is silent resolution, where the synthesis quietly picks one and nobody knows a disagreement existed.

Escalation. Multi-agent systems need a route out. Any agent must be able to stop and escalate with context.

The honest cost model

Cost	Description
Token cost	Multiple contexts, repeated instructions, synthesis passes
Latency	Sequential delegation adds round trips; parallelism helps but adds coordination
Complexity	More failure modes, harder debugging, harder testing
Information loss	Every hand-off is a lossy compression
Evaluation burden	Each agent needs its own evaluation plus end-to-end evaluation

The decision rule: adopt multi-agent architecture when the work genuinely parallelises, when specialisation demonstrably improves quality, when a single context cannot hold the task, or when separation of duties is a governance requirement — and when the value of the task justifies a multiple of the cost. Otherwise, one agent with good tools.

Business example — a marketing campaign department

An orchestrator receives a campaign brief. In parallel: a research agent gathers market and competitor context; an audience agent assembles segment insight from the CRM; a brand agent retrieves and applies voice guidelines. Their outputs converge on a strategy agent that produces a campaign plan, then a content agent drafts assets and a critic agent reviews every asset against brand and compliance criteria. Nothing publishes: a human marketing lead approves the plan and the final assets. The design earns its cost because research, audience and brand work are genuinely independent, and because separating the critic from the drafter measurably improved compliance pass rates. The same firm’s invoice-processing work, by contrast, remained a single agent — the steps are sequential and interdependent, and a multi-agent version was slower, dearer and no better.

Common mistakes

Building a “team of agents” for a task one agent handled fine, because it is a more exciting architecture.
Vague delegation, then blaming the worker’s output.
A critic that shares the generator’s prompt and information, and therefore its blind spots.
No conflict rule, producing confident synthesis over unresolved disagreement.
Measuring only the end-to-end result, so you cannot tell which agent is failing.
Ignoring the token multiple until the invoice arrives.

Expert insight

Multi-agent systems are organisational design applied to software. Every lesson from human organisations transfers: unclear responsibilities produce gaps; too many layers produce distortion; specialists outperform generalists on narrow work and underperform on ambiguous work; and coordination is a real, permanent cost that must be paid out of the gains. Design the org chart before you build the agents.

Knowledge check

Give the reported token multiples for agents and multi-agent systems relative to chat, and explain why they matter commercially.
Describe supervisor–worker and name its two characteristic failure modes.
When does multi-agent architecture reliably not help?
What must a well-formed delegation contain?
Why must a critic agent have a different vantage point?
Name four conflict-resolution rules.
Why must each agent be evaluated individually as well as end-to-end?

Challenge

Take a multi-step process you have already built as a single agent. Design a multi-agent version on paper. Estimate its token cost, latency and additional failure modes. Then state the specific evidence that would justify building it. If you cannot state that evidence, you have your answer.

Further exploration

Anthropic, How We Built Our Multi-Agent Research System (2025) — architecture, cost findings and evaluation approach.

Multi-Agent Systems