Domain 1 · Lesson 2 · Agentic Architecture (27%)
Coordinator & Subagent Orchestration
Task Statements 1.2 & 1.3 — hub-and-spoke, context isolation, and how to spawn subagents.
Course progress: Domain 1 ▸ lesson 2 of ~4
A multi-agent system is a coordinator (hub) delegating to specialized subagents (spokes). The exam's favorite failures all trace back to two facts: subagents are context-isolated, and the coordinator's decomposition decides coverage.
Hub-and-spoke: the coordinator owns everything
In the reference architecture the coordinator does all four jobs: decompose the task, delegate to subagents, aggregate results, and handle errors. Subagents never talk to each other — all communication routes through the coordinator. Why funnel everything through one hub?
- Observability — one place to see what happened.
- Consistent error handling — recovery logic lives in one spot.
- Controlled information flow — no uncontrolled side-channels between spokes.
Coordinator is dynamic, not a fixed pipeline
A good coordinator analyzes the query and selects which subagents to invoke — it does not blindly run the full pipeline every time. It should specify goals and quality criteria, not step-by-step procedures, so subagents can adapt.
Subagents are context-isolated
This is the fact that generates the most exam questions: a subagent does NOT inherit the coordinator's conversation history, and does not share memory across invocations. Whatever the subagent needs must be placed explicitly in its prompt.
So when you hand off to a synthesis subagent, you pass the actual web-search results and document analyses into its prompt. Use structured formats that separate content from metadata (source URLs, doc names, page numbers) so attribution survives the handoff — this is the seed of provenance (Domain 5).
How you spawn: the Task tool
| Mechanism | Detail |
|---|
Task tool | The way a coordinator spawns a subagent. The coordinator's allowedTools must include "Task" or it literally cannot delegate. |
AgentDefinition | Per-subagent config: description, system prompt, and tool restrictions. |
| Parallelism | Emit multiple Task calls in a single response to run subagents in parallel. Separate turns = sequential = slower. |
fork_session | Branch divergent explorations from one shared baseline (covered in Lesson 4). |
AgentDefinition — how you specify a subagent type
Each subagent type is declared with an AgentDefinition: a description (tells the coordinator when to invoke this subagent), a system prompt (its role and behavior), and tool restrictions (its scoped toolset). The description is what lets the coordinator choose the right subagent — so it must differentiate like a good tool description (Domain 2). The tool restrictions are where you enforce least-privilege per role (e.g., the synthesis agent gets no web-search tools). Get the description vague and the coordinator misroutes; get the toolset too broad and the subagent misuses tools outside its specialization.
The decomposition trap (root-cause reasoning)
Classic scenario: research on "AI in creative industries" returns a report covering only visual arts — music, writing, film are missing. Every subagent succeeded. The coordinator's log shows it split the topic into "digital art / graphic design / photography."
Root causeThe coordinator's decomposition was too narrow. Blaming the search agent, the analysis agent, or the synthesis agent is wrong — they executed their assigned scope correctly. When output has coverage gaps but subagents all succeed, look upstream at decomposition, not downstream.
Fixes: partition scope to minimize duplication (distinct subtopics/source types per agent), and run an iterative refinement loop — coordinator evaluates synthesis for gaps, re-delegates targeted queries, re-synthesizes until coverage is sufficient.
Check yourself
A synthesis subagent produces reports missing whole subtopics, yet each subagent completed its assigned task correctly. The coordinator log shows an overly narrow topic split. The root cause is that the:
- Synthesis agent lacks instructions to detect coverage gaps in its inputs
- Web search agent used queries that were too narrow in their scope
- Coordinator decomposed the task too narrowly when assigning subtopics
- Document analysis agent filtered sources with over-restrictive relevance
Correct: option 3. The subagents worked correctly within the scope they were given; the defect is in what they were assigned. Options blaming synthesis, search, or analysis pin the failure on downstream agents that performed correctly — the exam's recurring "blame-the-wrong-layer" distractor.
You pass findings to a synthesis subagent, but it ignores everything the prior agents discovered. The most likely reason is that subagents:
- Require the tool_choice parameter to be set to the value "any"
- Do not inherit coordinator history; context must be in the prompt
- Cannot process more than one source document per invocation
- Must be spawned sequentially across separate coordinator turns
Correct: option 2. Subagents are context-isolated — they don't automatically inherit the coordinator's history. Prior findings must be placed explicitly in the subagent's prompt. The others are fabricated constraints.
Decision rules to carry forward
Coverage gap + subagents succeeded → fix coordinator decomposition. Handoff → pass context explicitly, structured, with metadata. Parallel → multiple Task calls in one response. Delegate at all → allowedTools includes "Task".
Ask your teacher. Want the difference between hub-and-spoke and a peer-to-peer agent mesh, or how "goals not procedures" prompting actually looks? Ask before Lesson 3.