Domain 1 · Agentic Architecture

Multi-agent orchestration

When one agent can't hold the whole job in its head, you split it: a lead agent (the hub) breaks the task into pieces and spawns subagents (the spokes), each with its own fresh context window. The hard parts aren't the agents — they're context passing, partial failures, and provenance. This is exactly the "Multi-Agent Research System" exam scenario.

hub-and-spokesubagents context isolationpartial failure provenance

Explain like I'm 10

A teacher (the lead) gives a big group project to four students (the subagents): one finds facts, one checks them, one organises, one writes it up. Each student has their own notebook — they don't share a brain. The teacher hands each one just the part they need, collects the pieces, and staples them together. If one student loses their notebook, the teacher must notice and ask someone else — not pretend the missing page is fine.

Why split at all? Context isolation

A single agent doing deep research would fill its context window with raw search results long before it finished — and once the window is full, quality collapses. The fix: give each subagent a clean window for its narrow slice, and have it return only a compressed summary to the lead. The lead never sees the raw firehose; it sees five tidy reports. This is the real reason multi-agent beats one-big-agent for broad tasks — not "more brains," but more context budget spent in parallel.

worker C hits an error…

The fan-out in 3-D — drag to orbit

The hub-and-spoke shape, free to fly around: the lead on top, four subagents fanned out on their own context islands, and the synthesis collecting below. The failure select above drives this scene too — flip it to "worker C fails" and watch the spoke die in 3-D.

Rendered by the zero-dependency WebGL orbit renderer — the same scene data format as every 3-D view on the site.

The three things that actually break

Hazard	What goes wrong	Architect's answer
Context passing	Lead dumps its entire history into every subagent → wasted tokens, confusion.	Pass each subagent only its task + the minimal context it needs. Isolation is the feature.
Partial failure	One subagent times out; the lead synthesises anyway and silently ships a gap.	Detect missing results, retry or degrade explicitly, and tell the user what's incomplete.
Provenance	Final answer merges five sources; nobody can trace which claim came from where.	Carry source IDs through synthesis so every claim is attributable. Critical for trust + audits.

Exam trap: "more agents = better" is wrong. Multi-agent adds coordination cost, latency, and failure modes. Reach for it when the task is broad and parallelisable (research, "touch every file"), not for a linear task a chain handles. And a lead that ignores a failed subagent is the classic wrong answer — reliable synthesis must account for every spoke, including the ones that died.

Takeaways: multi-agent = a lead/orchestrator spawning subagents, each with an isolated context window that returns a compressed summary. You split for context budget, not brain count. The three exam hazards: pass minimal context, handle partial failures explicitly, and preserve provenance through synthesis. Use it only for broad, parallel work.

Curated companion: Anthropic — How we built our multi-agent research system.