Hub-and-spoke agent architecture: how to build multi-agent systems that stay explainable
A hub-and-spoke architecture puts one orchestrator in charge of planning, routing and verification, and gives every specialist agent, tool and human reviewer a bounded job. Here is how the pattern works, when to use it, and the design rules that keep it safe in production.
What hub-and-spoke means for AI agents
A hub-and-spoke agent architecture is a way of organising a system of AI agents so that exactly one component, the orchestrator (the hub), owns the plan, and every other component, the spokes, does one bounded job on request. Spokes are specialist agents, tool servers (for example MCP servers that wrap an ERP, a helpdesk or a document store), data sources, and human reviewers.
The hub never touches company systems directly and the spokes never talk to each other. All communication travels through the hub over typed tool contracts: a named operation, a schema for its input and output, an explicit permission, and a log entry. The result is a system where you can always answer three questions: what was the plan, who did each step, and what did each step change.
Why not let agents talk to each other?
Fully connected "swarm" designs, where any agent can call any other, are quick to demo and slow to operate. They fail in predictable ways:
- No single place to reason about the plan. When a run goes wrong you reconstruct it from six agents' logs.
- Permissions leak. If a summarising agent can call the agent that posts invoices, it effectively has posting rights.
- Cost is unbounded. Agents that can call each other can loop; every loop is a bill.
- Testing is combinatorial. Each new agent multiplies the paths you have to evaluate.
Hub-and-spoke trades a little flexibility for a lot of control. The hub is the only component with a global view, so it is the only one that needs global reasoning ability. Spokes can be small, cheap and specialised.
The five roles in a hub-and-spoke system
| Role | Responsibility | Typical implementation |
|---|---|---|
| Orchestrator (hub) | Turns a request into a plan, routes steps to spokes, verifies results, decides when to stop or ask a human | A capable model (e.g. Claude Opus or Sonnet class) with a small, fixed tool set: delegate, call_tool, request_approval, finish |
| Specialist agents | One domain each: documents, finance rules, support replies, compliance checks | Smaller or cheaper models with a narrow system prompt and only the tools that domain needs |
| Tool servers | Deterministic access to systems: read a PDF, match a purchase order, create a ticket | MCP servers or internal APIs with JSON schemas and scoped credentials |
| Knowledge | Retrieval over company documents and data so answers are grounded, not remembered | Indexed document store with chunking, metadata filters and citations |
| Human review | Approve, reject or correct at defined checkpoints | A queue in the tool your team already uses (Slack, email, helpdesk) with a typed decision returned to the hub |
How a run flows
- Intake. A request arrives: an email, a scheduled trigger, a form, a webhook.
- Plan. The hub writes a short plan: which spokes, in what order, which steps need approval. The plan is stored before execution starts, so it can be audited even if the run fails.
- Delegate. Each step is a tool call with a schema-validated input. Specialist agents return structured results, not prose.
- Verify. The hub checks each result against the plan: did the invoice match a purchase order, is the confidence above the threshold, does the total cross an approval limit.
- Checkpoint. Steps with real-world consequences (posting, sending, creating, paying) pause for a human decision when policy says so. The decision is itself a typed input.
- Finish. The hub produces a summary, the run's cost and duration, and a complete log of every tool call.
Design rules that keep it safe
1. Every edge is a contract
No free-text calls between components. Each tool has a name, an input schema, an output schema and a documented side effect. If a spoke cannot express what it needs in the schema, the schema is wrong, not the rule.
2. Permissions live on the tool, not the agent
The finance agent does not "have ERP access"; it has access to erp.match_po (read) and, only after approval, the hub has access to erp.post_invoice (write). Scoping credentials per tool makes the blast radius of any single prompt-injection or model error small and visible.
3. Reads are free, writes wait
Default policy: agents can read and compute without asking; any write to a system of record goes through a policy check and, above a risk threshold, a human. The threshold is a business rule (amount, customer tier, novelty), not a model judgement.
4. Ground answers in retrieval
Spokes that answer questions must cite the document or record they used. If retrieval returns nothing, the correct output is "not found", never a plausible guess.
5. Budget every run
The hub carries a token and time budget. Exceeding it is a terminal state that returns to a human, not a retry.
6. Evaluate before and after
Keep a test set of real requests with known correct outcomes. Run it before every prompt, model or tool change. A system you cannot re-evaluate is a system you cannot change.
When to use it, and when not to
Hub-and-spoke is the right default when a process touches more than one system, has steps with different risk levels, or must be explained to an auditor, a customer or a regulator. That covers most back-office automation: invoice intake, vendor onboarding, support triage, contract review, order exceptions.
It is overkill for a single-step task ("summarise this document", "classify this email"). Those are one spoke with no hub; build them as a plain tool and keep the option to plug them into a hub later.
Adding a capability is adding a spoke
The practical payoff shows up months in. When the business asks for a new step, say sanctions screening during vendor onboarding, you add one tool server and one line to the hub's policy. The plan format, the approval flow, the logging and the evaluation harness are unchanged. That is what "easy to extend" should mean for an AI system: new work without new risk.
Frequently asked questions
Is hub-and-spoke the same as an "agent supervisor" pattern?
They are close relatives. Supervisor patterns describe the hub; hub-and-spoke additionally fixes the rules for the spokes: no spoke-to-spoke calls, typed contracts on every edge, permissions attached to tools rather than agents, and human checkpoints as first-class steps.
Does the orchestrator need the most expensive model?
Usually the hub benefits from a stronger model because it does the planning and verification, while spokes can run on smaller, cheaper models. Model routing is a design decision: each step uses the cheapest model that passes the evaluation set.
How does MCP fit into hub-and-spoke?
MCP (Model Context Protocol) servers are the natural implementation of tool spokes. Each server exposes typed tools with schemas, which is exactly the contract the hub needs, and credentials can be scoped per server.
We look at the process, propose an architecture, and decide together whether it is worth building. No packages, no price list.
Get in touch → Book a call