- In short
- Hub and spoke architecture is a multi-agent pattern where a central coordinator agent sits at the hub and invokes specialised subagents as spokes. All communication flows through the coordinator; subagents never communicate directly with one another.
What hub and spoke architecture means
When a task is too big or too varied for one agent, you split the work across several. Hub and spoke architecture is the standard way to organise that split: a single coordinator agent sits at the hub, and a set of specialised subagents sit at the spokes. The coordinator decides what needs doing, invokes the right subagents, and gathers their outputs back into a coherent whole. Anthropic's own research system uses exactly this shape, which it calls an orchestrator-worker pattern, where "a lead agent coordinates the process while delegating to specialized subagents."
The defining rule of the pattern, and the single fact the exam tests most, is that the spokes do not connect to each other. A subagent cannot message another subagent. Everything passes through the hub. That constraint is not a limitation to work around; it is the source of the pattern's biggest advantages.
- Hub and spoke architecture
- A multi-agent topology with a central coordinator (the hub) that invokes specialised subagents (the spokes). All communication and coordination route through the hub; spokes never communicate directly.
The coordinator is the only hub
In this topology the coordinator holds the whole picture. It receives the user's goal, breaks it into pieces, and dispatches each piece to a subagent suited to it, a research subagent, a code-review subagent, a data-extraction subagent. When a subagent finishes, its result returns to the coordinator, not to a peer. The coordinator then decides what happens next: synthesise, delegate more work, or finish.
Because the coordinator is the only point through which work flows, it is also the only place you need to look to understand or debug the system. There is no hidden side-channel between spokes to reason about. This centralisation is what makes the architecture observable: every decision, every hand-off, and every result passes through one node you can log and inspect.
Why subagents never talk directly
The no-direct-communication rule is the most common point of confusion, so it is worth understanding why it exists rather than just memorising it. If subagents could message each other freely, the system would become a tangle of point-to-point links that no single node could observe or control. Failures would be hard to trace, duplicated work would be hard to prevent, and the coordinator would lose its authority over the flow.
Routing everything through the hub keeps the system a star, not a mesh. The coordinator can deduplicate effort, enforce ordering, and decide what each subagent should know. It is also why the next knowledge point, subagent context isolation, follows directly: since subagents do not share a channel, anything one needs to know must be handed to it explicitly by the coordinator. The topology and the isolation are two sides of the same design.
Hub and spoke versus one large agent
It is worth contrasting the pattern with the simplest alternative: a single, monolithic agent that tries to do everything in one context. For small tasks that monolith is fine and often preferable. There is no orchestration overhead. The hub and spoke architecture earns its keep when a task is broad enough that one context window would become crowded, or varied enough that different parts need different specialisations, or parallelisable enough that doing the parts at once is a real speed-up.
The trade is overhead for separation. A single agent has no coordination cost but accumulates every detail of every subtask in one growing context, which dilutes its focus and inflates token use. The star spreads the work across fresh contexts and recombines the distilled results, keeping each spoke sharp at the price of the coordination the hub must perform. Recognising when that trade pays off, broad, varied, or parallel work, is part of what the exam probes, because choosing a multi-agent design for a task that did not need one is its own kind of mistake.
What the star topology buys you
The benefits the Anthropic engineering team highlight all flow from this structure. Subagents run with their own separate context windows, so several can explore different facets of a problem in parallel without crowding each other's context. The coordinator condenses their findings into a final answer. On breadth-first tasks that parallelism is a large performance win, because independent spokes finish in the time of the slowest rather than the sum of all.
Just as important is control. Because the hub owns routing, you can decide which subagent runs, in what order, with what information, and what to do when one fails. That control is the seam where coordinator responsibilities and error routing live. Hub and spoke is the chassis; those later knowledge points are the systems bolted onto it.
The specialisation advantage of spokes
A further benefit of the star is that each spoke can be tuned for its job without burdening the others. The Agent SDK lets every subagent carry its own system prompt, its own tool restrictions, and even its own model. A read-only analysis subagent might be limited to Read and Grep so it cannot accidentally modify anything; a heavyweight reasoning subagent might run a more capable model while routine spokes run a cheaper one. None of that specialised configuration leaks into the coordinator's prompt as noise, because it lives inside each spoke.
This is the deeper reason the pattern scales: complexity is partitioned. The coordinator holds the orchestration logic and a clean overview, while each spoke holds the narrow expertise and permissions its slice requires. Adding a new capability is often just adding a well-described spoke, and the hub learns to delegate to it through that description. The star keeps the system both powerful and comprehensible, which is exactly the balance a production multi-agent design needs.
Worked example: a multi-agent research assistant
Worked example
A research system must produce a briefing on a broad topic by gathering evidence from several angles at once.
A user asks for a briefing on the impact of a new regulation. A single agent would have to investigate every angle sequentially, accumulating a sprawling context. Instead the coordinator decomposes the question into facets, legal, financial, operational, and spawns one subagent per facet, each with its own fresh context window.
The legal subagent researches and returns its findings to the coordinator. So do the financial and operational subagents, independently and in parallel. Crucially, the financial subagent never asks the legal subagent anything directly; if it needs a legal fact, that is the coordinator's job to supply when it dispatches or refines the work. Once all three report back, the coordinator synthesises a single briefing. The star topology made the parallelism possible and kept the whole investigation observable from one place.
Contrast that with a single agent attempting the same briefing alone. It would investigate each angle in sequence, its context swelling with legal citations, financial figures, and operational notes all at once, and any confusion in one strand would bleed into the others. The hub and spoke version keeps each strand clean in its own context and only merges the distilled conclusions at the hub, which is why, on broad questions like this, the multi-agent shape both runs faster and reasons more clearly.
Misconceptions to clear up
Misconception
In a multi-agent system, subagents can talk to each other directly to share what they found.
What's actually true
Misconception
The coordinator is just a thin router that forwards messages between subagents.
What's actually true
Scaling beyond a handful of spokes
Hub and spoke works cleanly for a few delegated tasks per turn, but very large jobs that coordinate dozens or hundreds of agents strain the turn-by-turn model, because each delegation and result still passes through the coordinator's context. The Agent SDK addresses this with a Workflow tool that moves orchestration into a script the runtime executes outside the conversation, so the coordinator's context is not consumed by every sub-result. The mental model stays the same, a hub directing spokes, but the bookkeeping moves out of the conversation for scale.
For the foundations exam you do not need the Workflow specifics, but the principle is worth holding: the star topology is the conceptual default, and tooling exists to scale it when the number of spokes grows beyond what one conversation can comfortably track. The exam's scenarios sit comfortably in the small-to-medium range where the plain coordinator-and-subagents picture applies directly, so anchor your reasoning there and treat large-scale orchestration as an extension of the same idea rather than a different one.
How this is tested on the exam
Domain 1 carries the most weight on the exam, and Task 1.2, orchestrating multi-agent systems, opens with this pattern. Questions often probe the no-direct-communication rule: a scenario will imply that two subagents coordinated between themselves, and you must recognise that as impossible in a hub and spoke design. Others ask which component owns a given responsibility, and the answer is almost always the coordinator at the hub. Because this knowledge point unlocks context isolation and coordinator responsibilities, a firm grasp of the star topology is what the rest of the multi-agent cluster stands on.
A reliable test-taking instinct here is to redraw the topology in your head as a star whenever a multi-agent scenario appears. Place the coordinator at the centre and the subagents around it, with arrows only between the centre and each spoke. If a scenario's described behaviour would require an arrow directly between two spokes, that behaviour is impossible as stated, and the question is usually testing exactly that. Conversely, if a scenario asks where some piece of coordination logic belongs, the star makes the answer visual: it belongs at the only point every arrow touches. Keeping that picture in mind turns several Task 1.2 questions into quick reads.
In a hub and spoke multi-agent system, a developer wants subagent B to use a fact that subagent A discovered. How does that information reach subagent B correctly?
People also ask
What is hub and spoke in multi-agent systems?
Can Claude subagents communicate directly?
What does the coordinator agent do?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
What are subagents?
Why watch: Introduces the coordinator-plus-specialist arrangement that is the hub-and-spoke architecture this KP defines.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.