Chapter 54 — Multi-agent systems and orchestration

In one sentence

Sometimes it helps to split work across several specialised agents — and much more often it just multiplies your bugs, your cost, and your latency.

The idea

   SINGLE AGENT                    MULTI-AGENT
   one loop, one tool set          a coordinator delegating to specialists

                                        [ORCHESTRATOR]
   [agent] -- tools                     /      |      \
                                  [researcher][writer][reviewer]
                                       |         |        |
                                     tools     tools    tools

When it genuinely helps

Situation	Why splitting helps
Genuinely parallel subtasks	Three independent searches run at once — real latency win
Very different tool sets	A "database agent" and a "web agent" with 30 tools each would confuse one model; 15 each is manageable
Separation for safety	A read-only research agent whose output is reviewed before a separate agent with write access acts on it
Different models per role	A cheap model to classify, an expensive one to reason (real cost savings)
Adversarial review	A generator and a critic that doesn't share the generator's context

When it doesn't (which is most of the time)

   Each hand-off between agents:
      * LOSES context (the next agent doesn't know what the last one saw)
      * ADDS latency (a full round trip)
      * ADDS cost (the system prompt is re-sent for every agent)
      * ADDS a failure mode (misunderstood hand-off)
      * MULTIPLIES debugging difficulty (which agent went wrong?)

   Five agents that each work 90% of the time
      -> 0.9^5 = 59% end-to-end success.

That arithmetic is the whole argument. Reliability compounds downwards. Before adding an agent, ask: could this be a tool on the existing agent instead? Usually, yes.

The orchestration patterns

   SEQUENTIAL (a pipeline)
     A -> B -> C            simple; each step's output is the next step's input

   ROUTER (a dispatcher)
     [classify] -> one of {A, B, C}      cheap; only one specialist runs

   ORCHESTRATOR-WORKERS
     planner decides the subtasks, spawns workers, merges results
     -> good when you can't know the subtasks in advance

   GENERATOR-CRITIC
     A produces, B critiques, A revises
     -> good when quality criteria are clear; beware infinite politeness loops

   BLACKBOARD (shared state)
     all agents read/write one shared state object
     -> avoids lossy hand-offs, but needs careful concurrency

The rules if you do build one

Hand off explicitly and completely. Pass a structured object, not a summary — anything not in the hand-off is lost.
One agent owns the outcome. Diffuse responsibility produces systems where nothing is anyone's job.
Cap the total budget, not per-agent. Otherwise five agents each with a "reasonable" cap can cost 5× your intended maximum.
Log the whole trace with a single correlation ID across all agents. Without this, debugging is impossible.
Only one agent gets write access. Keep the others read-only.

Practice (20 min, mostly thinking)

Take the Chapter 51 agent. Now design a two-agent version: a researcher (read-only tools) and a writer (no tools, just composes the answer).

In notes.md:

What exactly does the researcher hand to the writer? Write the JSON schema.
What information is lost in that hand-off?
If the final answer is wrong, how would you tell which agent caused it?
Would a single agent with both tools have been simpler? Be honest.

Then build it and compare cost and latency against the single-agent version. Most people find the single agent wins.

Check yourself

Give two situations where multi-agent genuinely helps.
Why does reliability compound downwards?
What is lost at every hand-off?
Why should only one agent have write access?