Agent team topologies: which hierarchy to build, and when

Topology is a decision, not a default

Ask five teams how their agents are wired and you will get five answers, most of them accidental: whatever the framework's tutorial did. Topology deserves an explicit decision, because it determines how the system fails, how much it costs per run, and how hard it is to add the next capability.

Five shapes cover almost everything worth building. Each has a natural fit and a characteristic failure.

1. Single agent with tools

One model, a list of typed tools, a loop. No delegation, no sub-agents.

Fits: a bounded task with one skill set: classify an email and file it, extract fields from a document, answer from a knowledge base. If the whole job fits in one agent's context and permission set, adding agents adds only latency.

Fails when: the tool list grows past roughly a dozen and the agent starts choosing badly, or when two parts of the task need different permissions and you can no longer scope them separately.

Rule of thumb: start here. Most "we need a multi-agent system" requests are one agent with a well-designed tool set.

2. Hub-and-spoke

One orchestrator plans, routes and verifies; specialist agents, tool servers and human reviewers are spokes that only ever talk to the hub.

Fits: a process that crosses several systems, has steps at different risk levels, and must be explainable afterwards. This is the working default for back-office automation, and the pattern is described in detail in hub-and-spoke agent architecture.

Fails when: the hub becomes a bottleneck of context. Every result passes through it, so a process with dozens of steps and large payloads will strain the orchestrator's context window and cost.

3. Two-level hierarchy

An orchestrator delegates to team leads, each of which owns a group of specialists and returns one consolidated result.

orchestrator
├── intake lead
│   ├── document specialist
│   └── classification specialist
└── finance lead
    ├── matching specialist
    └── posting specialist

Fits: processes too large for one hub's context, or organisations where different departments own different halves of a flow and want separate evaluation sets, permissions and release cycles.

Fails when: the hierarchy is built for tidiness rather than need. Every extra level adds a summarisation step, and every summarisation loses detail. Two levels is almost always enough; three is a sign the process should be split into two systems.

A second level earns its place when the lead does real work: it holds context its specialists do not need, it makes routing decisions, and it can fail a whole branch without the orchestrator re-planning from scratch.

4. Pipeline

A fixed sequence of stages, each transforming the payload and passing it on. No planning at run time.

Fits: high-volume, low-variance work where the steps never change: ingest, extract, validate, enrich, store. A pipeline is cheaper and far more predictable than an orchestrated team because there is no planning token spend and no route to get wrong.

Fails when: real cases need to skip, repeat or branch. The moment you add conditional routing to a pipeline you are building an orchestrator, and you should build it deliberately.

Many production systems are a pipeline with one orchestrated stage in the middle, which is a good outcome: keep the deterministic parts deterministic.

5. Blackboard (shared state)

Agents read from and write to a shared, structured workspace instead of passing payloads directly. A controller decides who runs next based on what is on the board.

Fits: long-running cases that accumulate evidence over hours or days: an investigation, a claim, a diligence file. State outlives any single run, and different agents contribute as information arrives.

Fails when: the board has no schema. Untyped shared state degrades into a junk drawer, and agents begin depending on fields they did not agree on. If you use this shape, version the board like a database, because it is one.

6. Swarm, and why we avoid it

Any agent may call any other agent. It demos beautifully.

Fails when: anything goes wrong. There is no single place that knows the plan, so you cannot answer "why did it do that", cycles are easy to create and hard to detect, permissions cannot be reasoned about (any agent can reach any capability transitively), and cost per run is unbounded. We do not build these for production processes.

Choosing

If the process…	Build
Is one task with one skill set	Single agent with tools
Crosses systems, mixed risk, must be auditable	Hub-and-spoke
Is too large for one hub, or split across owners	Two-level hierarchy
Is high volume and never branches	Pipeline
Accumulates evidence over days	Blackboard with a schema

Migrating between shapes

Topologies are not permanent, and the migrations are asymmetric. Single agent to hub-and-spoke is easy if your tools were typed from the start: the tools stay, the loop moves into an orchestrator. Hub-and-spoke to two levels is easy if handoffs already had schemas: you insert a lead that speaks the same contract. Anything to swarm is easy and anything from swarm is a rewrite.

That asymmetry is the practical argument for typed tool contracts and schema-bearing handoffs even in a system that starts as one agent: they are what makes the next shape a refactor rather than a restart.

Frequently asked questions

Is more agents always better?

No. Every agent adds a handoff, a summarisation step and latency. Add an agent when a part of the work needs a different skill set, different tools or a different risk level, not to make a diagram look thorough.

Can one system use more than one topology?

Usually it should. A common production shape is a deterministic pipeline for ingestion with one orchestrated stage where judgment is required, and a human approval gate before anything is written. Use the cheapest shape that each part of the work allows.

How do I know the orchestrator has become a bottleneck?

Watch context size and planning cost per run. If the orchestrator spends most of its tokens restating results it just received, or if adding a step forces you to trim earlier context, it is time for a second level or for splitting the process.