Multi-agent patterns

Fashionable, and usually the wrong first answer. The strongest response to “design a multi-agent system” often begins by asking whether one agent with good tools would do.

Why multi-agent at all

Legitimate reasons:

• Context isolation. Each agent gets a focused context instead of one bloated prompt. This is the most defensible reason.
• Specialisation. Different system prompts, tool sets, or models per role — a cheap model for retrieval, a reasoning model for synthesis.
• Parallelism. Independent subtasks run concurrently.
• Separation of privilege. The agent reading untrusted content has no write tools. A genuine security argument.

Bad reasons: it sounds sophisticated; you read a blog post; the org chart has three teams.

The cost is real: every handoff is a context boundary where information is lost, latency multiplies, cost multiplies, and debugging goes from hard to very hard.

The topologies

Supervisor

One orchestrator delegates to specialists and integrates results.

        supervisor
       /     |     \
  research  code   write

The default choice. Control flow is centralised so it’s traceable, and the supervisor can re-plan when a specialist fails. The supervisor becomes the bottleneck and its context still grows, but it’s the pattern that works most often.

Pipeline

extract -> analyse -> summarise -> format

Fixed sequence. This is a workflow, not really a multi-agent system, and that’s a point in its favour — deterministic, testable, cheap. If your “multi-agent system” is a pipeline, call it a pipeline and enjoy the determinism.

Parallel with a reducer

Fan out independent subtasks, merge results.

async with asyncio.TaskGroup() as tg:
    results = [tg.create_task(agent.run(sub)) for sub in subtasks]
merged = synthesiser.run(results)

Excellent when subtasks are genuinely independent — researching five topics, reviewing a diff along several dimensions. Latency is the slowest branch rather than the sum.

Network / choreography

Any agent may call any other. Maximum flexibility, minimum predictability — non-terminating conversations, circular delegation, runaway cost. Rare in production, and worth being sceptical about in a design discussion.

Hierarchical

Supervisors of supervisors. Sometimes necessary at real scale; each layer adds latency and lost context. Justify before reaching for it.

Handoffs are where information dies

The core engineering problem in multi-agent systems.

A typed contract between agents is the engineering answer. Define what a sub-agent receives and returns as a schema, exactly as you would an internal API.

class ResearchRequest(BaseModel):
    question: str
    max_sources: int = 5
    exclude_domains: list[str] = []

class ResearchResult(BaseModel):
    findings: list[Finding]
    sources: list[HttpUrl]
    confidence: Literal["high", "medium", "low"]
    gaps: list[str]                     # what it could NOT determine

That gaps field is the sort of detail that makes the pattern work: a sub-agent reporting what it failed to find lets the supervisor re-plan instead of confidently synthesising from an incomplete picture.

Failure modes specific to multi-agent

• Error compounding. Each agent is, say, 90% reliable. Five in sequence is 59%. Chains of agents degrade multiplicatively, and this is the calculation to do out loud.
• Lost context. The specialist lacks a constraint the supervisor knew.
• Circular delegation. A hands to B, B hands back to A. Needs explicit depth limits.
• Cost explosion. Each agent runs its own loop with its own growing context.
• Diffuse responsibility. When the output is wrong, which agent was at fault?

The reliability arithmetic is the strongest argument for keeping the topology shallow.

When one agent is better

An agent with a well-designed tool set frequently beats a multi-agent system:

• No handoff loss — full context throughout.
• Simpler to trace and debug.
• Cheaper and faster.
• Easier to evaluate.

The honest heuristic: reach for multi-agent when context genuinely doesn’t fit, when subtasks are truly parallel, or when privilege separation demands it. Not because the problem “has several parts” — one agent can call several tools.

Implementation notes

• Bound depth and total agent invocations, not just steps within one agent.
• Propagate a trace ID through every agent and tool call, or you cannot reconstruct what happened.
• Budget centrally. A shared token/cost budget across the whole run, not per agent.
• Make sub-agent failure explicit — a sub-agent returning “I couldn’t determine X” is far more useful than one that invents X.
• Isolate privileges per agent. The agent that reads untrusted documents should not hold the tool that sends email. See ../11_mcp/03_building_and_securing.md.

Interview angle

• “When would you use multiple agents?” — context isolation when one prompt can’t hold the task, genuine parallelism, model specialisation, or privilege separation. Not because the task has several conceptual parts — a single agent with good tools handles that better.
• “What’s the main risk?” — compounding unreliability. Five agents at 90% each gives roughly 59% end-to-end. Keep the topology shallow and make each handoff a typed contract.
• “Which topology would you start with?” — supervisor with specialists. Control flow stays centralised and traceable, and the supervisor can re-plan on failure. Network/choreography is flexible and rarely worth its unpredictability.
• “How do you pass information between agents?” — a typed schema, treated like an internal API contract. Include a field for what the sub-agent could not determine, so the supervisor can re-plan rather than synthesise over a gap.
• “How do you debug a multi-agent failure?” — a trace ID propagated through every agent and tool call, with per-step logging. Without it, attributing a wrong answer to a specific agent is guesswork.
• “Is a fixed sequence of agents a multi-agent system?” — that’s a pipeline, and calling it one is a compliment: it’s deterministic, testable and cheap. Don’t add model-driven delegation where a fixed sequence works.