Hub-and-Spoke Coordinator Topology

When one agent has to research five sources, review ten files, or juggle a dozen tools, its attention gets diluted and its context window fills with noise. The hub-and-spoke (coordinator) topology fixes this by splitting the work: a central coordinator agent decomposes the task and delegates each slice to a focused specialist subagent.

• The hub (coordinator) owns the plan: it decomposes, delegates, aggregates, routes, and handles errors.
• Each spoke (subagent) is a narrow specialist with its own role, system prompt, and a least-privilege tool set.

This is the backbone of the Multi-Agent Research System pattern, and a high-value topic in Domain 1 (Agent Architecture & Orchestration, 27% of the exam).

A coordinator is not just a router. On the exam, the correct answer almost always shows the hub doing all five of these jobs:

• Decompose — break the goal into independent or sequential sub-tasks.
• Delegate — hand each sub-task to the right specialist.
• Aggregate — merge subagent results into one coherent answer.
• Route — decide which specialist (or none) a sub-task needs.
• Handle errors — recover transient faults, escalate the non-recoverable, and keep partial results.

If a design makes the coordinator a thin pass-through that just forwards text, it is doing too little. If a subagent tries to plan the whole job, it is doing too much.

In a coordinator agent, delegation is itself a tool call. The coordinator's allowedTools must include "Task" — that is the mechanism it uses to spawn a subagent. Each subagent is described by an AgentDefinition:

• name — the specialist's identifier.
• description — when to route to it (the coordinator selects by description, not by name).
• system_prompt — the specialist's instructions and persona.
• allowed_tools — a least-privilege list scoped to that role.

Without "Task" in the coordinator's allowed tools, it simply cannot delegate — a common trap answer.

This is the single most-tested fact about hub-and-spoke, so internalize it: subagents do NOT inherit the coordinator's conversation history.

Each subagent starts with a clean context window. It knows only what the coordinator explicitly puts into its prompt. If the coordinator learned a constraint, a date range, a customer ID, or a prior finding, and then delegates without restating it, the subagent is blind to it.

Rule: all context a subagent needs must be passed explicitly in each Task prompt. This is a feature, not a bug — it is exactly what keeps each spoke's context clean and focused.

Because nothing is inherited, the coordinator hydrates every Task call with the facts that slice needs. Notice how the customer tier, the date window, and the prior finding are all written into the prompt — not assumed.

The coordinator can delegate to several specialists at once. Multiple Task calls emitted in a single response run in parallel. That is how a research coordinator fans out across five sources simultaneously instead of querying them one after another.

• Use parallel Task calls when sub-tasks are independent (different sources, different files, different regions).
• Use sequential delegation when a later step depends on an earlier result (a fixed pipeline / prompt chain).

Independent workstreams in parallel; dependent steps in sequence.

Specialists earn their reliability from a tight tool surface. The fact sheet is blunt about this: 4–5 tools per agent is optimal, and 18+ tools degrades selection reliability. Overlapping or ambiguous tool descriptions cause misrouting.

So scope tools to the role and follow least privilege:

• A read-only researcher gets search/fetch tools — never write or delete.
• A refund agent gets process_refund — but not the database admin tools.

Remember: the model picks a tool from its description, not its name. A good description states purpose, return values, input formats with examples, edge cases, and applicability boundaries.

When the spokes report back, the coordinator's aggregation step does more than concatenate. For a research system it must preserve provenance — the claim-to-source mapping (URL or doc name, the quote, and the publication date).

• When two subagents return conflicting stats, annotate the conflict rather than silently picking one. Publication dates often resolve the apparent contradiction.
• Render by content type: tables for financials, prose for news, lists for technical findings.

Silent suppression of a disagreement is a wrong answer; surfaced, dated, cited disagreement is the right one.

One failing spoke must not abort the whole workflow. The coordinator distinguishes failure types and acts accordingly:

• Transient fault (timeout, rate limit) — recover locally inside the subagent; retry there.
• Non-recoverable — escalate to the coordinator with partial results so the rest of the job still completes.
• Distinguish an access FAILURE (worth retrying) from a valid EMPTY result (genuinely no matches — do not retry).

This is why structured errors matter: a generic "Operation failed" blocks recovery, while a structured error (failure type, attempted query, partial results, alternatives, retryable flag) lets the coordinator route intelligently. Never silently suppress; never abort the whole run on one spoke's failure.

Why pay the cost of multiple agents at all? Context isolation. Each spoke runs in its own clean context window, so verbose tool output from one specialist never crowds out another's reasoning.

• It defends against lost-in-the-middle: models attend most to the start and end of a context, so keeping each spoke's window short and on-topic keeps key facts in the high-attention zones.
• Trim verbose subagent tool output to the relevant fields before it reaches the coordinator.

A single mega-agent doing everything in one window is exactly the anti-pattern hub-and-spoke is designed to replace.

The coordinator drives each delegation through the standard agentic loop, and the exam is strict about how it ends. Terminate on the model's stop_reason, never by parsing the text for words like "done".

• Inspect stop_reason: on tool_use, run the tool (or Task) and append results; on end_turn, the turn is complete.
• Decisions are model-driven. An iteration cap is a safety net, never the primary stop mechanism.

Parsing output text for a completion signal, or using a hard iteration cap as the main exit, are classic distractor answers.

A coordinator agent has already learned, in earlier turns, that the user only wants results for the EU region in 2026. It now fans out three parallel Task calls to specialist subagents to gather data. What MUST the coordinator do for the subagents to apply that EU/2026 constraint?

Key takeaways for the exam:

• Shape: one coordinator (hub) decomposes, delegates, aggregates, routes, and handles errors; specialist subagents (spokes) do focused work.
• Delegation: the coordinator's allowedTools must include "Task"; each spoke is an AgentDefinition with name, description, system_prompt, and least-privilege allowed_tools.
• No inherited history: pass ALL needed context explicitly in every Task prompt.
• Parallelism: multiple Task calls in one response run in parallel — use it for independent work; sequence dependent steps.
• Tools: 4–5 per spoke is optimal; route by description; scope to the role.
• Aggregation: keep provenance, annotate conflicts (dates resolve them), render by content type.
• Errors: recover transient locally, escalate non-recoverable with partial results, never abort the whole run.
• Termination: stop on stop_reason, never on parsed text; iteration caps are a safety net only.