Express course · No. 29
A single agent handles one goal in a loop. Some problems are bigger than that — too many tools, too many distinct skills, too much to hold in one context. Multi-agent systems split the work across specialized agents coordinated by an orchestrator. Done right, that's more reliable and scalable; done by reflex, it multiplies every failure mode. Here's when many agents beat one, and how to wire them.
Essence only · One picture per idea · Reliability over magic
Before wiring agents together, understand the problem it solves. Multi-agent systems exist for a specific reason — and reaching for them without that reason is how they go wrong.
One agent that does everything does nothing well
A single worker told to be the architect, the plumber, the electrician, and the inspector — versus a small crew of specialists who each do one thing properly.
A single agent given too broad a mandate — every tool, every kind of task, one giant prompt — has too many ways to go wrong at every step. As the job grows, its reliability falls. Splitting the work across specialized agents, each with a narrow job, can make the whole system more capable and more reliable, the same way a crew of specialists beats one overstretched generalist. Specialization is the core reason multi-agent exists.
Context and tools overload a single agent
One desk piled with every document and every tool for ten different jobs — the worker spends more effort sorting the clutter than doing the work.
Two concrete limits push past a single agent. One agent's context window fills with everything for every part of the task, and overstuffed context degrades quality (the context-engineering problem). And a single agent holding all the tools has to choose among a giant menu every turn, which it does worse the more there are. Splitting lets each agent carry only the context and tools its narrow job needs — clean, focused, reliable.
Specialization is the point — and the cost is coordination
A relay team is faster than one runner doing four legs — but only because the handoffs are practiced; a fumbled baton loses the race.
The gain from multi-agent is specialization: narrow agents that each do one thing well. The cost is coordination: now something has to split the work, route it, pass context between agents, and assemble the results — and that coordination is itself a source of complexity and failure. The whole discipline is capturing the gain of specialization while keeping the coordination cost from eating it. When the gain doesn't beat the cost, one agent was the right answer.
One agent that does everything does nothing well — too much context, too many tools. Many specialized agents can be more capable, but the price is coordination, which must be worth the gain.
The most common shape of a multi-agent system has a coordinator at its center. Understanding the orchestrator is most of understanding how these systems are wired.
A coordinator that routes the work
A general contractor on a building site: they don't lay the bricks or wire the panel — they break the project into jobs and send each to the right specialist.
The orchestrator (or coordinator) is the agent in charge: it takes the overall goal, breaks it into subtasks, and routes each subtask to the right specialized agent. It doesn't do the specialized work itself; its job is decomposition and direction. This mirrors the plan-and-execute idea from the agents course, scaled up — one capable agent plans and delegates, while focused workers carry out the pieces.
It assembles the workers' results
An editor commissions sections from different writers, then combines them into one coherent article — the pieces come back, and someone makes them whole.
The orchestrator's second job is assembly: gathering what the worker agents return and combining it into a coherent final result. A research orchestrator might send subtopics to several agents and then synthesise their findings into one answer. This collect-and-combine step is where the separate streams of work become a single output — and doing it well (resolving conflicts, dropping duplicates) is as important as the splitting.
The coordination layer is the real architecture
An orchestra isn't a pile of brilliant soloists — it's the conductor and the score deciding who plays when. The coordination is the music.
In a multi-agent system, the value and the difficulty move into the coordination layer: who runs when, with what input, and how results combine. The individual agents get the attention, but whether the system works is decided by the orchestration around them — the routing, the context passing, the error handling. As with single agents, the model is the easy part; the structure around it is where reliability is won or lost.
The orchestrator decomposes the goal, routes each subtask to a specialized worker, and assembles their results. The coordination layer — not the individual agents — is the real architecture.
The agents the orchestrator directs are most useful when each is narrow. The discipline of keeping workers focused is what makes the whole system reliable and testable.
Each worker has one clear job
A kitchen with a station for each task — one cook on sauces, one on grill, one on plating — each mastering their narrow role instead of fumbling all of them.
A worker agent is a specialized agent with a narrow, well-defined job: search the docs, write the code, check the facts, format the output. Because its mandate is small, its prompt is focused, its tools are few, and its behaviour is predictable. The orchestrator hands it a clear subtask, it does that one thing, and returns the result. Narrow workers are the building blocks — each simple enough to get right and to trust.
Narrow agents are easier to test and trust
You can thoroughly inspect a single specialist's work because their job is small and defined — far easier than auditing a generalist who does a bit of everything.
A narrow agent is dramatically easier to evaluate, debug, and trust than a sprawling one. With one clear job, you can write evals for it, see exactly where it fails, and fix it in isolation — the same reliability argument as the agents course, applied to each piece. A multi-agent system is reliable only if its workers are individually reliable, and that's far easier to achieve when each does one well-scoped thing.
Depth in one job beats breadth across many
A surgeon who only does one operation, thousands of times, beats a generalist attempting it occasionally — focus produces a reliability breadth can't.
The principle running through this is that depth beats breadth: a focused agent doing one thing repeatedly is more reliable than a broad one doing many things occasionally. This is why you decompose — not to have more agents for its own sake, but to let each one be narrow enough to be genuinely good at its piece. If a worker's job is still too broad to be reliable, the answer is usually to split it further, not to pile on more tools.
Worker agents are narrow specialists — one clear job, a focused prompt, few tools — which makes each testable and trustworthy. Depth in one job beats breadth across many.
Agents are only as good as what they pass to each other. How work and context move between them — cleanly or messily — decides whether the system stays coherent or degrades into noise.
A handoff passes work between agents
A relay runner passing the baton: the exchange is its own skill, and a clean pass — not just fast runners — is what wins the race.
A handoff is the moment one agent passes work to another — the orchestrator to a worker, or one agent directly to the next. What gets passed is the subtask and the context needed to do it. Handoffs are where a lot of multi-agent failures happen: if the receiving agent doesn't get what it needs, or gets a muddled version of it, its output is wrong no matter how good the agent is. The exchange is a first-class part of the design.
Pass clean, structured context — not everything
A good briefing gives the next person exactly what they need for their task — not the entire transcript of every prior conversation to wade through.
The temptation is to pass each agent the whole history so far, but that recreates the overstuffed-context problem inside every agent. Better is a clean handoff: give the receiving agent a focused, structured summary of just what it needs — the relevant facts and the specific task — not the raw firehose. This keeps each agent's context tight and focused, which is exactly what made splitting worthwhile in the first place.
Context isolation keeps agents focused
Separate workrooms, each with only the materials for that room's job — so no one is distracted or confused by the clutter of every other task.
A real benefit of multi-agent is context isolation: each agent works in its own clean context, seeing only what its job requires, not the accumulated mess of the whole system. This is part of why splitting can improve reliability — it prevents the context rot that builds up in one long-running agent. But you only get that benefit if your handoffs are disciplined; pass everything to everyone and you've rebuilt the single-overloaded-agent problem with extra steps.
Handoffs pass work between agents, and they're where multi-agent often fails. Pass a clean, structured summary of just what's needed, so each agent keeps the focused context that splitting was meant to give.
Multi-agent systems are wired in a few recurring shapes. Knowing the three main ones — and when each fits — is most of knowing how to structure the coordination.
Sequential: a pipeline of stages
An assembly line: each station does its part and passes the product to the next, in a fixed order, until it comes out finished at the end.
The sequential pattern chains agents in a fixed order: agent A's output feeds agent B, whose output feeds agent C. A draft agent, then an edit agent, then a fact-check agent. It's the simplest multi-agent shape and the most predictable, ideal when the work has natural stages that must happen in order. It's essentially a pipeline of specialists — and when the steps are fixed, it's more reliable than a loop that re-decides the order each time.
Parallel: fan out and gather
Sending the same research question to several assistants at once, then collecting all their findings together — many working simultaneously, results merged at the end.
The parallel pattern runs multiple agents at the same time on independent pieces, then gathers their results — a fan-out followed by a gather. Researching five subtopics, processing many items, getting several independent perspectives: all are faster done in parallel than one after another. The orchestrator splits the work, the workers run simultaneously, and the results are combined. Parallel shines when the pieces don't depend on each other and speed matters.
Hierarchical: orchestrators of orchestrators
A company org chart: a manager directs team leads, who each direct their own workers — coordination nested in layers for a job too big for one level.
The hierarchical pattern nests coordination: a top orchestrator delegates to sub-orchestrators, each managing their own workers. This handles genuinely large, complex tasks by breaking them down in layers, the way an organisation does. It's the most powerful shape and the most complex — more coordination, more places to fail — so you reach for it only when the task is genuinely big enough to need nested decomposition. Most systems are fine with sequential or parallel; hierarchy is for the few that aren't.
Sequential chains agents in a fixed pipeline; parallel fans out independent work and gathers it; hierarchical nests orchestrators for big tasks. Use the simplest shape the work actually needs.
Multi-agent is seductive and often overused. More agents don't just add capability — they multiply the ways the system can break, and ignoring that is how these systems quietly fail.
More steps compound more error
A longer relay with more handoffs has more chances to drop the baton — every extra exchange is another place the whole run can fail.
A single agent already only succeeds a fraction of the time over a long chain (the reliability problem from the agents course), and multi-agent makes the chain longer: more agents, more handoffs, more steps, each able to fail and pass its error downstream. Reliability multiplies down the chain, so adding agents can lower overall success unless each piece and each handoff is solid. More agents is more surface area for compounding failure, not automatically more capability.
Coordination has its own overhead and cost
A meeting to coordinate five teams can cost more than the work itself — past a point, the coordinating outweighs the doing.
Every agent is its own model calls, its own latency, its own cost — and the orchestration adds more on top. A multi-agent system can be far slower and more expensive than a single agent for the same task, sometimes without being any better. The coordination overhead is real: routing, handoffs, assembly, retries. If the specialization gain doesn't clearly beat this added cost and latency, the simpler single agent was the better engineering choice.
It's harder to trace and debug
Tracking one parcel is easy; tracing a fault through a web of warehouses, trucks, and handoffs is a different and much harder job.
When something goes wrong in a multi-agent system, finding where is much harder than in a single agent: the failure could be in any worker, any handoff, or the orchestration itself. Observability — tracing a request across the agents, logging each handoff — becomes essential and more difficult. This debugging cost is a real part of the price. A system you can't trace is a system you can't reliably fix, and multi-agent makes tracing genuinely harder.
More agents multiply the failure modes: more steps compounding error, real coordination overhead and cost, and much harder tracing. Reflexive multi-agent lowers reliability, not raises it.
Multi-agent is a powerful tool for the right problem and an expensive mistake for the wrong one. Using it well is mostly restraint — splitting only when a single agent genuinely can't cope.
Split only when one agent genuinely can't cope
You don't form a committee to answer a simple question — you bring in a team only when the job is genuinely too big for one capable person.
The default should be a single agent, and you reach for multi-agent only when one genuinely can't handle the job — too many distinct skills, too many tools, too much context to hold coherently. If a single well-built agent can do it, the multi-agent version just adds cost, latency, and failure modes for no gain. The question is never "could I split this?" — almost anything can be split — but "does one agent actually fall short here?"
Keep each agent narrow and each handoff clean
A well-run crew has clearly-defined roles and practiced handoffs — the structure, not heroics, is what makes it dependable.
When you do go multi-agent, the two disciplines that make it work are: keep each worker narrow (one clear job, few tools, testable in isolation) and keep each handoff clean (a focused summary of just what's needed, not the whole history). Most multi-agent failures trace to a worker that's too broad or a handoff that's too muddy. Get those two right, with a clear orchestrator and the simplest pattern that fits, and the system stays reliable as it scales.
- Can a single agent actually do this — or does it genuinely break under the load? - Is there a clear orchestrator that decomposes, routes, and assembles? - Is each worker narrow — one job, few tools, testable on its own? - Are handoffs clean — a focused summary, not the whole history dumped? - Which pattern fits — sequential, parallel, or hierarchical — and is it the simplest that works? - Does the gain beat the cost — more steps, latency, spend, and harder tracing?
- multi-agent / orchestrator — splitting work across agents, coordinated by a director. - worker agent / specialization — a narrow agent with one clear job; depth over breadth. - handoff / context isolation — passing work cleanly; each agent in its own focused context. - sequential / parallel / hierarchical — pipeline, fan-out-and-gather, nested coordination. - fan-out — splitting work to run several agents at once. - coordination overhead — the added cost, latency, and complexity of orchestration. - compounding error — more steps and handoffs multiplying the chance of failure.
- You reach for multi-agent only when one agent genuinely can't cope. - A clear orchestrator decomposes, routes, and assembles the work. - Each worker is narrow — testable and trustworthy on its own. - Handoffs are clean, passing focused context and keeping each agent's window tight. - You use the simplest pattern that fits and can trace a failure across the agents.
Multi-agent is deliberate: split only when one agent truly can't cope, give it a clear orchestrator, keep each worker narrow and each handoff clean, and use the simplest pattern — because every agent you add multiplies the cost and the failure modes.