Supervisor-Workers and Hierarchies
35 min readreadingTopologies and Coordination
3 of 13Multi-Agent Systems Engineering
Up next · Parallel Fan-Out and Map-Reduce Subagents
Before a single prompt is written, the topology has already made most of your engineering decisions for you. Choose a supervisor and you have decided where reconciliation happens, what a trace looks like, and who pays the token bill for coordination. Choose a peer network and you have decided — perhaps without noticing — that no one owns the goal. Topology is to a multi-agent system what schema is to a database: the thing that is cheap to pick and ruinous to change.
This lesson is the catalog. Seven topologies cover essentially everything shipping or published in 2026, from the workhorse supervisor pattern through research-grade market mechanisms. For each: how it works, what coordination costs, how it fails, and when it is the right call. The closing table compresses the catalog to one page — the artifact you will actually use in a design review.
One agent — the supervisor, or orchestrator — owns the goal. It decomposes the task, delegates subtasks to worker agents, collects their results, resolves conflicts, and synthesizes the answer. Workers talk only to the supervisor, never to each other. This is the hub-and-spoke of agent design, and it is the default for the same reasons the manager pattern survives in human organizations: a single point of accountability, a single place to look when things go wrong, and a natural spot to enforce budgets and quality gates.
Coordination cost is moderate and — critically — linear: N workers means N handoffs in and N results back, not N² conversations. The trace reads top-down like a well-run meeting. The costs are the hub's costs: the supervisor is a serial bottleneck (every result funnels through its context window), a single point of failure, and a quality ceiling — a weak supervisor squanders strong workers by decomposing badly or synthesizing lazily. In practice supervisor quality matters more than worker quality; spend your best model there. Anthropic's research system is exactly this shape: an Opus-class lead agent orchestrating Sonnet-class searchers.
When one supervisor's span of control runs out — decomposition gets shallow, its window fills with worker reports — you add a layer: a top-level orchestrator delegating to mid-level supervisors, each running its own worker pool. A research lead with three domain leads, each with four searchers.
Each layer buys scope and pays twice for it: the telephone game now has more hops (goals re-encoded downward, findings re-compressed upward, losing fidelity in both directions), and latency stacks because a parent cannot finish before its slowest subtree. The operational rule of thumb: two levels handle almost everything real; a third needs the kind of scope — hundreds of subtasks — that few production tasks have. Depth is a cost you should be able to defend subtask by subtask.
Agents in a fixed order, each consuming the previous stage's output: researcher → writer → editor; extract → transform → validate. Where the task has a natural order, the pipeline is the honest topology — no coordination logic beyond "next", easy to reason about, easy to test stage by stage.
Its failure modes are the chain's failure modes. Compounding error — Lesson 2's — applies undiluted, and drift accumulates because every stage re-encodes the task. Wall-clock is the sum of stages; nothing is parallel. Two mitigations do most of the work: pass the original goal to every stage (not just the previous output), and put a verification stage after the riskiest transformation, where it converts a 0.90 stage into something closer to a 0.98 one.
An orchestrator splits the task into independent subtasks, launches N workers simultaneously, then a fan-in step gathers and synthesizes. Map-reduce with prompts. This is the topology that converts token spend into wall-clock speed and parallel context windows — the physical win from Lesson 2 — and it is the shape behind every serious research agent shipping today.
It has one load-bearing precondition: the subtasks must be disjoint. Overlapping scopes make workers duplicate each other's reading (token waste), produce near-identical findings (synthesis noise), and contradict each other at the margins (conflict resolution burden). The second precondition is barrier discipline: fan-in waits for the slowest child, so per-child budgets and timeouts decide your tail latency. Lesson 4 builds this topology end to end — decomposition prompts, effort scaling, synthesis, budgets — because it is the one you will actually operate.
Remove the hub. In a peer network, agents message each other directly — a group chat, in AutoGen's founding metaphor (now part of the Microsoft Agent Framework). In a handoff chain, an agent unilaterally transfers control to a peer it judges better suited — the pattern OpenAI's Agents SDK made first-class: triage hands to billing, billing hands to escalation, each handoff carrying the conversation.
Handoff chains are genuinely useful where routing is the problem — support triage, wizard-style flows — because the decision lives next to the context that justifies it. Free-form peer networks are the topology practitioners most often regret: coordination cost is potentially quadratic, conversations can orbit without converging (two polite agents thanking each other is a real failure mode in the MAST corpus), and when the output is wrong there is no owner to ask why. Debate — Lesson 1's panel — is the disciplined exception: peers, but with fixed stances, capped rounds, and a judge. Peer topologies return in Part 2, where Interoperability: MCP, A2A & the Agent Protocol Stack territory — A2A-connected agents across vendors and organizations — makes meshes unavoidable and gives them a protocol.
Blackboard. No messages at all: agents share a common workspace — the blackboard — reading the current state of the solution and contributing when they can. The idea is one of the oldest in AI (the Hearsay-II speech system of the 1970s); its modern echo is a shared state store or a filesystem that agents read and write, with a controller deciding who acts next. It shines when you cannot know the solution path in advance — opportunistic contribution beats planned delegation. The costs: contention (two writers, one truth), stale reads, and traces that show what changed but not why. Most production systems use a disciplined slice of this idea — shared artifacts with an owner, Lesson 5's subject — rather than a free-for-all board.
Markets and auctions. Allocation by bidding: a task is announced, agents bid on cost or claimed competence, the best bid wins. The lineage runs from the Contract Net Protocol (Smith, 1980) through decades of multi-agent systems research. Auctions decentralize load balancing elegantly, and the mechanism resurfaces wherever genuinely independent parties must allocate work — which is why A2A-era agent marketplaces keep rediscovering it. For 2026 production LLM systems, though, it remains mostly research: bids from language models are self-reports, not prices discovered by competition, and a supervisor with a routing table achieves the same allocation with far less machinery. Know it exists; reach for it when your agents genuinely have private information and misaligned incentives — a mesh of vendors, not a team you own.
| Topology | Coordination cost | Signature failure modes | Use when |
|---|---|---|---|
| Supervisor-workers | Moderate, linear in N | Hub bottleneck; weak supervisor caps system quality | Default for delegation; need one owner, auditable traces, budget enforcement |
| Hierarchical tree | High; grows with depth | Telephone-game loss at every level; latency stacks by subtree | Scope exceeds one supervisor's span; rarely deeper than two levels |
| Sequential pipeline | Low | Compounding error (0.9^5 = 0.59); drift; serial latency | Task has a natural stage order; keep chains short, verify mid-chain |
| Parallel fan-out/fan-in | Moderate; barrier at fan-in | Overlapping subtasks; straggler children gate latency; token blowout on easy queries | Independent subtasks; window pressure; wall-clock matters (Lesson 4) |
| Peer network / handoffs | High, up to quadratic | No owner; non-convergent chatter; lost context at handoffs | Routing-shaped problems (handoffs); structured debate; A2A meshes in Part 2 |
| Blackboard | Low messaging, high contention | Write conflicts; stale reads; unattributable state changes | Solution path unknowable in advance; disciplined shared-artifact variants (Lesson 5) |
| Market / auction | High mechanism overhead | Self-reported bids; gaming; complexity without competitive pressure | Independent parties, private information — mostly research in 2026 |
Check: you need to review 200 pull-request files against a style guide, then produce one consolidated report. File reviews are independent; the report must reconcile duplicate findings. Which topology fits?
Two closing rules make the catalog operational. First, pick the cheapest topology that matches the task's dependency structure — independent subtasks get fan-out, ordered stages get a pipeline, routing gets handoffs, and anything needing one accountable owner gets a supervisor. Second, topologies compose: the production systems you will build in Lesson 4 are a supervisor whose workers fan out in parallel, sometimes feeding a short pipeline of synthesis then verification. The catalog is a vocabulary, not a menu of mutually exclusive religions — but every composite you design should still answer the two questions any topology must: who owns the goal, and where do conflicts get resolved.