Curriculum › Agentic Architecture & Orchestration · 27% of the exam

Coordinator-subagent orchestration

What you’ll be able to do

  • Design a hub-and-spoke coordinator that routes all subagent communication, error handling, and information flow
  • Have the coordinator select subagents based on query complexity instead of always running the full pipeline
  • Partition research scope across subagents by distinct subtopics or source types, without narrowing coverage
  • Implement an iterative refinement loop that checks synthesis output for gaps and re-delegates targeted work

What you need to know

Hub and spoke: the coordinator is the only hub

In a coordinator-subagent system, one coordinator agent sits at the center and every specialized subagent — web search, document analysis, synthesis, report writing — is a spoke. Subagents don't talk to each other. Results come back to the coordinator, errors come back to the coordinator, and the coordinator decides what each subagent receives next.

That routing rule is a design choice with concrete payoffs. Observability: there is one place where every handoff can be logged and inspected. Consistent error handling: a failed search is handled by one policy at the hub rather than by whichever subagent happened to receive the failure. Controlled information flow: the coordinator decides exactly what context each subagent gets, so nothing reaches a subagent by accident.

coordinator web search doc analysis synthesis every request, result, and error passes through the hub; spokes never talk directly

Subagents start with isolated context

A subagent does not inherit the coordinator's conversation history. Whatever the coordinator learned from the user, or from an earlier subagent, does not exist for the next subagent unless the coordinator puts it in that subagent's prompt. This is why routing through the hub matters: the coordinator is the only participant that holds the whole picture, so it is the only one that can decide what each spoke needs. (How to write that handoff is lesson 1.3.)

What the coordinator is responsible for

  • Decomposition — turning the user's request into subtasks.
  • Delegation — choosing which subagent handles each subtask, and what it's told.
  • Aggregation — combining what comes back into one result.
  • Selection by complexity — deciding which subagents a query actually needs. A simple factual question may need one search and no document analysis; a broad comparative question may need all of them, several times. A coordinator that pushes every query through the full search → analysis → synthesis → report pipeline wastes latency and cost on simple queries. Have it analyze the query's requirements first and invoke only what they call for.

The narrow-decomposition risk

The coordinator's decomposition sets the ceiling on coverage. If a request about "remote work's effect on cities" is decomposed into "commercial office vacancy," "downtown retail foot traffic," and "office-to-residential conversions," every subagent can do flawless work and the report will still say nothing about housing prices in suburbs, public transit ridership, or municipal tax revenue. Nobody was ever asked to look.

The diagnostic signal is distinctive: each subagent's output is correct and on-topic for what it was assigned, but the final report is missing whole areas. When you see that, look at the coordinator's subtask list before tuning any subagent's prompt. The fix is a decomposition that maps the full breadth of the topic before splitting it.

Partitioning scope to avoid duplication

Breadth is one half; the other is non-overlap. If three search subagents all receive "research remote work and cities," they'll find many of the same sources. Give each a distinct slice — by subtopic (housing, transit, municipal finance) or by source type (academic papers, government statistics, industry reports) — so parallel work adds coverage rather than repeating it.

Iterative refinement: loop until coverage is sufficient

A single pass rarely produces complete coverage, and the coordinator shouldn't assume it did. In an iterative refinement loop, the coordinator:

  • evaluates the synthesis output against the original request, looking for gaps — unanswered sub-questions, thinly supported claims, missing areas;
  • re-delegates to search and analysis subagents with targeted queries aimed at those gaps, not a rerun of the original broad queries;
  • re-invokes synthesis with the new findings added;
  • repeats until coverage meets the quality bar, then hands off to reporting.
before — one pass, whatever comes back ships
findings = run_all(search, analysis) # same pipeline for every query report = synthesis(findings) return report
after — coordinator selects, evaluates, and refines
plan = coordinator.plan(query) # broad map of the topic, then distinct slices findings = delegate(plan.subagents_needed, plan.slices) draft = synthesis(findings) while (gaps := coordinator.find_gaps(query, draft)): findings += delegate_targeted(gaps) # narrow queries aimed at each gap draft = synthesis(findings) return report(draft)

Key concept

The coordinator is the hub: it decomposes, delegates, routes every result and error, and aggregates. Coverage is capped by its decomposition, so scope broadly, partition without overlap, and loop on gaps until coverage is sufficient.

When a scenario says every subagent did its job well but the result is incomplete, the root cause is almost always upstream at the coordinator — in what it assigned, or in its failure to check for gaps.

Practice scenario

ScenarioA research system answers "How are cities adapting to extreme heat?" Logs show the coordinator created subtasks for "cool roof programs" and "urban tree canopy," both subagents returned accurate, well-cited findings, and synthesis produced a polished report. Reviewers complain it omits cooling centers, building codes, and power-grid planning. The team proposes adding "be comprehensive" to the synthesis agent's prompt.
Work it through, then open this

Synthesis can only combine what it was given, so a prompt change there won’t add missing research. The gap was created when the coordinator decomposed a broad topic into two narrow subtopics. Fix the coordinator: have it map the topic’s full breadth (infrastructure, public health services, regulation, energy) and assign distinct slices to subagents. Then add an iterative refinement step: after synthesis, the coordinator checks the draft against the question, sends targeted queries for uncovered areas, and re-runs synthesis until coverage is sufficient.

Build exercise — Add gap-driven refinement to a coordinator

Intermediate · 30 min

What you’ll learn

  • Writing a decomposition step that maps a topic’s breadth before splitting it
  • Selecting subagents based on what a query needs
  • Closing the loop between synthesis output and re-delegation
  1. Give a coordinator a broad research question and log its subtask list before any subagent runs. Compare that list to an outline you write yourself of everything the question covers.

    • Why: Decomposition sets the ceiling on coverage; you need to see it separately from downstream quality.
    • You should see: At least one area in your outline that no subtask covers, or confirmation that the decomposition is broad and non-overlapping.
  2. Add a selection step: the coordinator classifies each query’s complexity and invokes only the subagents it needs. Try one simple factual query and one broad comparative query.

    • Why: Running the full pipeline for every query wastes latency and cost on simple ones.
    • You should see: The simple query skipping subagents the broad query uses.
  3. After synthesis, have the coordinator list coverage gaps against the original question, send targeted queries for each gap, and re-run synthesis. Stop when the gap list is empty or below your quality threshold.

    • Why: A single pass rarely achieves full coverage, and the coordinator is the only agent that can see the whole picture.
    • You should see: A second or third iteration that adds material on previously missing areas, with all requests and results logged at the coordinator.

Exam traps

Decomposing a broad topic so narrowly that whole areas are never assigned to any subagent

Subagents only research what they’re assigned. A narrow subtask list produces an incomplete report no matter how well each subagent performs.

Blaming downstream subagents for coverage gaps that originate in the coordinator’s decomposition

If every subagent’s output is correct for its assignment, tuning their prompts won’t help. Check the coordinator’s subtask list first.

Routing every query through the full subagent pipeline regardless of its complexity

The coordinator should analyze what a query needs and invoke only those subagents. A fixed full pipeline wastes effort on simple queries.

Letting subagents pass results directly to each other, bypassing the coordinator

Direct spoke-to-spoke traffic loses observability, splits error handling across agents, and lets context flow uncontrolled.

Assuming a subagent can see the coordinator’s conversation history

Subagents start with isolated context. Anything not passed in their prompt doesn’t exist for them.

Accepting the first synthesis pass without checking it for coverage gaps

An iterative refinement loop evaluates the draft, re-delegates targeted queries for gaps, and re-synthesizes until coverage is sufficient.

Giving parallel subagents overlapping scope so they duplicate each other’s work

Partition by distinct subtopics or source types so parallel work adds coverage instead of repeating it.

Sources

Quick check

A support agent built with the Agent SDK calls lookup_order with the same order ID three or four times in a row before answering. Logs show each call executes successfully and stop_reason is "tool_use" every time. What is the most likely root cause?