Multi-Agent Systems
Orchestrator-workers, handoffs, debate, and parallel specialists — the coordination patterns, what they cost, and the honest case for using one agent
Multi-Agent Systems
TL;DR
Sometimes one agent is not enough, and several specialists coordinated well genuinely beat one generalist. Far more often, a multi-agent system is a single agent's problem made more expensive and harder to debug. This page covers every standard pattern, what each costs, and the honest test for whether you need one.
| Property | Value |
|---|---|
| Level | Intermediate → Advanced |
| Reading time | ~25 minutes |
| Prerequisites | Context Engineering |
| You will understand | Every coordination pattern, its cost, and when one agent is better |
First, the Honest Warning
Multi-agent systems are the most over-adopted idea in this field. Every agent you add multiplies cost and latency, and introduces failure modes that did not exist before — agents contradicting each other, context lost in handoffs, and a coordinator that becomes a single point of failure. A wrong result now has several possible origins plus the joins between them.
Add a second agent only when a single one has measurably failed at the task.
The genuine reasons to split into several agents:
| Reason | Why it works |
|---|---|
| Different tool sets | A researcher and a code-runner need different tools. One agent with both has a longer, noisier tool list. |
| Different instructions that conflict | "Be exhaustive" and "be concise" cannot both govern one prompt |
| Genuine parallelism | Independent subtasks can run at once and finish faster |
| Adversarial review | A critic without the generator's context is meaningfully more critical |
| Separate context budgets | Each agent gets a clean window instead of one shared, overflowing one |
Bad reasons, which are common:
| Reason | Why it fails |
|---|---|
| "It seems more sophisticated" | It is more expensive and harder to debug. That is all. |
| "One agent for each step" | That is a workflow. Write it as one. |
| "More perspectives is better" | Only if they genuinely differ. Same model, same data, different name = same answer, several times. |
The Patterns
What each coordination pattern costs
No agent at all. One prompt, one answer. Always try this first.
Read the task and answer it
Wall-clock time so far
0 ms
One call was 900 ms
Cost so far
0.00 units
One call was 1.00
Run them all. Two results are worth sitting with: the router can beat a single call on cost, because it sends easy work somewhere cheap. And parallel workers cost three times more but finish almost as fast as one, because you wait for the slowest, not the sum.
Router — classify, then dispatch
Router
Simple
Small, cheap model answers directly
Technical
Agent with engineering tools
Billing
Agent with account tools
| Aspect | Detail |
|---|---|
| Cost | Can be lower than a single agent, because easy requests go somewhere cheap |
| Strength | Each path gets a focused prompt and a short tool list |
| Risk | Misrouting. Always have a fallback path for "unsure". |
| Use when | Traffic is mixed and most of it is easy |
Build one: LLM Router & Orchestration
Orchestrator + workers
A planner splits the task, specialists do the parts, the planner assembles the result.
Orchestrator and workers
Orchestrator
Workers
Shared
| Aspect | Detail |
|---|---|
| Cost | Roughly 5× a single call |
| Strength | Genuinely handles tasks needing different kinds of expertise |
| Risk | The orchestrator is a single point of failure. A bad plan wastes every worker's effort. |
| Watch | Workers duplicating each other's work because the split was unclear |
Parallel specialists
Same task, several independent workers, results merged.
| Aspect | Detail |
|---|---|
| Cost | N× the workers, but you wait only for the slowest |
| Strength | The best latency profile of any multi-agent pattern |
| Risk | Partial failure — decide in advance what happens when one worker fails |
| Use when | Subtasks genuinely do not depend on each other |
Debate / evaluator-optimizer
One agent produces, another criticises, the first revises.
Generator and critic
Generator
Produce a first attempt
Critic
Find the weaknesses — with no stake in the original
Generator
Revise against the criticism
Deliver
Once the critic passes it, or the round cap is hit
| Aspect | Detail |
|---|---|
| Cost | Roughly 5× |
| Strength | Measurably improves judgement-heavy work — analysis, writing, review |
| Risk | Will argue forever without a hard round cap |
| Key detail | The critic must not share the generator's context, or it inherits its blind spots |
See it working: Bull vs Bear Market Analyst
Handoffs
One agent transfers control and context to another.
| Problem | Fix |
|---|---|
| Context is lost in the transfer | Pass an explicit structured summary, not the raw trace |
| Handoff loops | A hands to B, B hands back. Track handoff count and cap it. |
| Nobody owns the task | One agent must remain accountable for the final answer |
| The user notices the seam | Keep the voice and format consistent across agents |
Comparing Them
| Pattern | Cost | Latency | Debuggable | Use when |
|---|---|---|---|---|
| One agent | 1× | 1× | Hard | Default — start here |
| Router | 0.6–1× | 0.8× | Easy | Mixed traffic, mostly easy |
| Chain | 2–3× | 2–3× | Easy | Steps known in advance |
| Parallel | 3–4× | 1.5× | Medium | Independent subtasks |
| Orchestrator + workers | 5× | 4× | Hard | Genuinely different expertise |
| Debate | 5× | 5× | Medium | Quality over cost |
The router is the only row that can come in below a single agent, because it removes work rather than adding it. If you are going to add exactly one pattern, this is usually the one worth adding.
Shared State
Multiple agents need to agree on what is true. This is where subtle bugs live.
| Approach | How | Trade-off |
|---|---|---|
| Pass in messages | Each agent receives what it needs in its prompt | Simple. Duplicates data and drifts. |
| Shared state object | One structured record all agents read and write | Consistent. Needs care about concurrent writes. |
| Shared store | A database or vector store | Scales. Adds infrastructure and staleness. |
When two agents can write the same state, you have a concurrency problem — the ordinary kind, with the ordinary solutions. Parallel workers writing findings to one object will overwrite each other unless you design for it. Give each worker its own slot and merge deliberately.
Common Mistakes
What goes wrong
Multi-agent before single-agent was measured
The core error. You cannot know a second agent helped if you never measured the first.
One agent per step of a known process
That is a workflow with extra cost. Write it as a chain.
A critic that shares the generator's context
It inherits the same assumptions and approves the same mistakes. Give it a clean window and the artefact alone.
No cap on debate rounds or handoffs
Agents will pass work back and forth until your budget stops them.
Raw trace passed on handoff
Expensive and noisy. Pass a structured summary of what matters.
Same model and data, different names
Five 'perspectives' that are one perspective billed five times.
No single owner of the final answer
Nobody reconciles contradictions, and the user gets whichever agent spoke last.
Concept Checks
Check yourself
Why must a critic agent not share the generator's context?
Because criticism is only useful when it comes from outside the reasoning that produced the work. An agent carrying the generator's full trace has already absorbed its assumptions, its interpretation of the task, and the dead ends it rejected — so it tends to validate rather than challenge. Given only the artefact and the criteria, it evaluates what is actually there, which is what you wanted. Independence is the mechanism, not the model.
How can a router cost less than a single agent, given it adds a call?
Because the classification call is small and the work it avoids is large. Real traffic contains many simple requests that do not need tools, a long context, or a strong model. Paying a tiny routing cost on every request to send a substantial fraction to something cheap nets out negative. It also improves the hard cases, since each path gets a focused prompt and a short tool list instead of one prompt covering everything.
Someone proposes five specialists that all use the same model and the same data. What is wrong?
They are not five perspectives, they are one perspective purchased five times. Genuine diversity comes from different tools, different data, different instructions, or an adversarial role — not from labels. Without one of those, the agents converge on similar answers, and any apparent agreement is a measurement of the same model agreeing with itself, which is worse than useless because it looks like corroboration.
Why is the orchestrator the riskiest component in an orchestrator-workers system?
Because everything downstream depends on its plan, and its errors are silent and expensive. If it splits the task badly, every worker executes correctly against the wrong brief, and the failure only surfaces at assembly — after you have paid for all of them. It is also where duplicated work originates, since overlapping subtask definitions send two workers after the same thing. Traces at the planning step are worth more than traces anywhere else.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| Start with one agent | Add a second only after measuring the first fail |
| Good reasons to split | Different tools, conflicting instructions, real parallelism, adversarial review |
| Router | The only pattern that can cost less than the baseline |
| Orchestrator + workers | Powerful; the planner is the single point of failure |
| Parallel specialists | Best latency; decide what partial failure means |
| Debate | Real quality gains; the critic must be independent |
| Handoffs | Pass a structured summary, cap the count, keep one owner |
| Shared state | An ordinary concurrency problem — design for it |
| Same model, different name | Not a perspective |
Next
You can build one. Now find out whether it actually works: Evaluating Agents.