1.2 Multi-Agent Orchestration

In Lesson 1.1 you built a single agent: one loop, one model, working through a task. That carries you a long way. But picture a harder job — "research the impact of AI across every creative industry and write me a cited report." A single agent would have to search music, then film, then writing, then visual arts, then design, reading hundreds of articles, one after another, cramming every result into one ever-growing conversation. Two things go wrong: it's slow (everything happens in sequence), and the conversation balloons until the important early findings get buried under everything that came later.

Now picture how a human research team handles the same job. A lead researcher breaks the topic into areas, hands each to a specialist, lets them work in parallel, and then pulls their findings together into one report. Each specialist keeps their own notes; the lead doesn't need to read every article — just the summaries. The work gets done faster, and no single person drowns in detail.

That team is exactly what multi-agent orchestration gives you. One agent — the coordinator — breaks a big task into pieces and delegates each to a specialized subagent (which is itself just an agent running its own loop from Lesson 1.1). The subagents work independently, often at the same time, and report back. Task Statement 1.2 is about designing this team well: how the coordinator divides the work, how the pieces talk to each other, and — most importantly for the exam — how to spot when the team produces a bad result and trace it to the right cause.

There are many ways to wire a team together, but the one the exam cares about — and the one that works best in practice — is hub-and-spoke. Picture a bicycle wheel: a hub in the centre, spokes radiating out to the rim. The coordinator is the hub. Each subagent is at the end of a spoke. And here's the defining rule: the spokes connect only to the hub, never to each other.

Concretely, that means every piece of communication flows through the coordinator. The search subagent never hands its results directly to the synthesis subagent. It returns them to the coordinator, and the coordinator decides what to pass onward. The subagents are like consultants who report only to the project manager and never email each other directly.

Why force everything through the centre? Because routing through one place buys you three things that a free-for-all can't: observability (the coordinator sees everything that happens, so you can debug it), consistent error handling (one place decides what to do when something fails), and controlled information flow (the coordinator decides exactly what each subagent sees, so nothing leaks or gets duplicated by accident).

This is the single most important — and most tested — fact about subagents, and it follows directly from Lesson 1.1's idea that each agent has its own conversation. When the coordinator spawns a subagent, that subagent does NOT inherit the coordinator's conversation. It does not see the coordinator's history, it does not see what other subagents found, and it remembers nothing from any previous time it was invoked. It starts blank.

Think of each subagent as a brand-new contractor who walks in having read none of the project emails. If you want them to know something, you have to tell them — explicitly — in the brief you hand them. There is no shared whiteboard they can glance at, no group memory. This is the isolation principle, and it's a feature, not a bug: it's what keeps each subagent's context clean and focused (and it's what makes the coordinator's job to pass context properly — the subject of all of Lesson 1.3).

The practical upshot for 1.2: a coordinator that assumes its subagents 'just know' the background will get useless results. Every subagent invocation must carry, in its own brief, exactly what that subagent needs to do its job.

If the coordinator is the brain of the operation, what exactly is it responsible for? Four things. When a multi-agent system misbehaves, the cause is almost always a failure in one of these — usually the first one.

Look closely at 'decompose'. The coordinator's first act is to carve the task into subtasks. If it carves badly — too narrowly, missing whole parts of the question — then it hands its subagents the wrong assignments. The subagents will execute those wrong assignments perfectly, and the final report will be confidently incomplete. This is the failure mode the exam tests more than any other, so we'll give it its own section next.

Here is the scenario the exam returns to again and again. You run a research system on "the impact of AI on creative industries." Every subagent reports success: the search agent finds good articles, the analysis agent summarises them correctly, the synthesis agent writes a coherent report. And yet the final report covers only visual arts — music, writing, and film are completely missing. Where's the bug?

The instinct is to blame a worker: maybe the search agent's queries weren't broad enough, or the synthesis agent should have noticed the gap. Resist that instinct and look at the coordinator's logs. There you find it: the coordinator decomposed "creative industries" into just three subtasks — "digital art", "graphic design", and "photography." Every one is a visual art. The subagents did their jobs flawlessly; they were simply never ASSIGNED music, writing, or film. The coverage gap was baked in at the moment of decomposition, before any subagent ran.

The lesson generalises: when a multi-agent result is incomplete but every subagent succeeded within its scope, the root cause is upstream — the coordinator's decomposition — not the downstream workers. The fix is to broaden the decomposition so it spans all relevant parts of the topic. Adding more subagents, rewriting the search queries, or giving the synthesis agent a gap-checker all miss the real cause.

Multi-agent systems are genuinely powerful, but they are not free, and a good architect knows when NOT to reach for one. The numbers are striking. In Anthropic's own research system, a multi-agent setup (an Opus-4 lead coordinating Sonnet-4 subagents) beat a single Opus-4 agent by 90.2% on their internal research evaluation — a huge gain. But it used about 15× more tokens than a normal chat (general agents use about 4×). In fact, token usage alone explains roughly 80% of the variance in how well these systems do. More agents means more parallel reasoning, which means more tokens.

So the deciding question is not "is this task hard?" — it's "what SHAPE is this task?" Multi-agent pays off when the work is naturally parallel, when the information exceeds what one context can hold, when many complex tools are involved, or when the query is breadth-first (explore several independent directions at once). It is the wrong choice when all the agents would need to share the same context with many dependencies between them, and for most coding, where the subtasks usually depend on each other and can't truly run in parallel.

You now have the whole picture: why teams beat soloists for the right tasks, the hub-and-spoke shape, the isolation principle, the coordinator's four jobs, the signature decomposition failure, and the cost trade-off. As with 1.1, the way to lock it in is to build a small version and then deliberately reproduce the failure mode.

Everything here rests on subagents being able to receive a proper brief — because they start blank. HOW you write that brief, pass findings between stages, and keep citations intact is the entire subject of the next lesson, 1.3.