9.7 Multi-agent systems

What this is and why it exists

Several specialised agents working together is an appealing picture and frequently a worse system than one agent with good tools. Coordination is not free, handovers lose exactly the context that mattered, and behaviour arising from interaction is hard to reproduce and therefore hard to fix. This topic is the patterns that work, the connective tissue between agents, and an honest account of when adding agents is engineering and when it is theatre.

The vocabulary

• Supervisor pattern — one agent directing several workers.
• Hierarchical pattern — supervisors of supervisors, a tree of responsibility.
• Peer pattern — agents coordinating without a director.
• Message passing — agents communicating by explicit messages.
• Shared state — agents communicating by reading and writing common data.
• Handoff — one agent transferring work to another.
• Emergent behaviour — behaviour arising from interaction rather than from any one agent.
• Run recording — the complete trace of a multi-agent execution.

The mental model

Start with the question the topic exists to force: what does a second agent buy? There are three honest answers. Different tools, where one agent needs database access and another needs a browser, and separating them narrows what each can do — a security benefit as much as an organisational one. Different context, where one agent works over documents and another over code, and keeping their transcripts separate keeps each one focused and cheaper. Genuine parallelism, where independent sub-tasks can run at the same time and the wall-clock saving is real.

If none of those applies, a second agent is a persona, and personas cost money. The same model with a different system prompt, in a separate loop, is more requests, more tokens, more latency and one more place for the context to break — for a difference you could have achieved by asking the one agent to consider the question from another angle.

The three patterns, and what each is good for.

Supervisor is the one to reach for first. One agent holds the task, decides which worker handles each part, and assembles the results. Workers are narrow: specific tools, specific instructions, no view of the whole. It is straightforward to reason about because there is one decision-maker, and straightforward to debug because every routing decision sits in one transcript. Its limit is the supervisor itself — it becomes the bottleneck and the single point of failure, and its context grows with everything the workers return.

Hierarchical is supervisors of supervisors, and it exists for the case where one supervisor's context cannot hold the whole task. A mid-level supervisor summarises its part of the tree upward rather than passing everything, which is the point. It is more machinery, and it is warranted only when the flat version has actually been outgrown.

Peer patterns have agents coordinating without a director — negotiating, critiquing, handing work sideways. They fit genuinely collaborative tasks, and they are the hardest to control: without a director there is nobody to decide when the work is done, so termination becomes a distributed problem, and conversations between agents can continue producing plausible output indefinitely. If you use peers, the stopping rule has to be external — a step budget, a token budget, an arbiter — because the agents will not find it themselves.

Message passing and shared state are the two ways they coordinate, and they fail differently.

Message passing is explicit: an agent sends a structured message and receives a reply. The transfer is visible, so it can be logged, validated and replayed, and each agent's view is exactly what it was sent. The cost is that everything needed must be in the message, which is where handoffs lose things.

Shared state is a common store all agents read and write. It is simpler to write and harder to reason about at scale, for the ordinary reasons shared mutable state is always harder: two agents writing the same field, an agent reading a value another is midway through updating, and no record of who caused what. Prefer messages for anything crossing an agent boundary, and use shared state for large artefacts referenced by identifier — put the document in the store and pass its identifier in the message, rather than either copying it or letting everyone mutate it.

Handoffs are where context quietly dies, and this is the failure to design against.

The receiving agent gets whatever was in the message. What it does not get is everything the sending agent knew and did not think to include — why the approach was chosen, what was already tried and failed, which constraint made an obvious option wrong, what the user actually asked as opposed to the sub-task derived from it. The receiver then does something reasonable and wrong, and to the person watching it looks like a competent agent making an inexplicable decision.

Design the handover explicitly, as a schema rather than as prose. The fields that matter: the original request, verbatim, not the sending agent's paraphrase of it; the specific sub-task; the constraints that apply; what has already been tried and why it failed; and the expected shape of the reply. That last one closes the loop, because a reply the caller cannot use is a handover that failed in the other direction. A handover schema is the single highest-value artefact in a multi-agent system, and writing it usually reveals that one agent would have been enough.

Debugging emergent behaviour is the ongoing cost, and there is one practical answer: record everything. Behaviour arising from interaction is not reproducible from any single agent's transcript, and it frequently is not reproducible at all — the same inputs take a different path because generation varies. So capture, for every run, every request and response, every tool call and result, every message between agents, with timestamps and identifiers linking them into one causal picture. Then a failure can be examined after the fact, and a recorded run can be replayed against a change.

Without that, multi-agent debugging is guesswork with a large bill attached. The observability topic makes this concrete, and it is worth saying here because the recording has to exist before the incident, not after.

The closing judgement. Start with one agent and good tools. Add a second when it brings different tools, different context or real parallelism, and be able to say which. Prefer a supervisor over peers. Write the handover schema before writing the agents. And measure the committee against the single agent on cost, steps and success rate, because it frequently loses, and the version with fewer moving parts is the one you will be able to fix.

What you should now be able to explain or do

Give the three honest reasons for a second agent and recognise a persona. Choose among supervisor, hierarchical and peer patterns with a reason, and say what limits each. Explain why peer patterns need an external stopping rule. Compare message passing with shared state and apply the identifier rule. Write a handover schema with the five fields that matter. Explain why emergent behaviour needs complete run recording, in place before the incident. Measure a multi-agent design against a single agent.

Check yourself