Multi-Agent Coordination Patterns: How Agents Actually Work Together (and Where They Fall Apart)

Table of Contents

• Why Coordination Is the Hard Part of Agentic AI
• The Five Coordination Patterns That Actually Matter
• Supervisor (Orchestrator-Worker)
• Hierarchical (Teams of Teams)
• Pipeline (Sequential Handoff)
• Peer-to-Peer Collaboration
• Blackboard (Shared State)
• How to Choose: A Decision Framework
• The Coordination Tax Nobody Budgets For
• Handoffs, Context, and the Telephone-Game Problem
• Coordination as a GaaS Pricing Problem
• Insights Most People Overlook
• References

Why Coordination Is the Hard Part of Agentic AI

Building a single competent agent is now close to a solved engineering problem. You give a model a system prompt, a handful of tools, a memory store, and a loop, and it can book a flight or triage a support ticket. The moment you need two or more agents to cooperate on something larger, the difficulty doesn't double. It explodes.

The reason is that coordination introduces problems that don't exist for a lone agent: who decides what happens next, how does context travel between agents without degrading, what happens when two agents disagree, and who is accountable when the whole thing produces a confidently wrong answer. These are not model problems. They're systems problems, and they look a lot like the distributed-systems problems engineers have wrestled with for decades, except the "nodes" are non-deterministic and occasionally hallucinate their own job description.

For anyone selling agents as a service, this matters commercially, not just technically. A per-outcome pricing model assumes the outcome is reliable. Coordination failures are the single biggest source of unreliable outcomes in multi-step agent products, and they tend to fail in the most expensive way possible: silently, after burning a lot of tokens. So the choice of coordination pattern is partly an architecture decision and partly a margin decision.

The Five Coordination Patterns That Actually Matter

There's a long tail of exotic coordination schemes in research papers, but in production you keep seeing the same five shapes. Everything else is a variation or a combination of these.

Supervisor (Orchestrator-Worker)

A single supervisor agent owns the goal. It breaks the task into pieces, hands each piece to a specialist worker agent, collects the results, and decides whether to stop or keep going. The workers don't talk to each other; all communication routes through the supervisor.

This is the workhorse of credible production systems, and for good reason. There's exactly one place where routing decisions happen, which makes the system debuggable: when something goes wrong, you read the supervisor's reasoning trace. Anthropic's own writeup on building a multi-agent research system leans on this shape, with a lead agent spawning subagents to explore in parallel and then synthesizing their findings. You can read their account of the engineering tradeoffs in a multi-agent research system for a candid look at where the parallelism pays off and where it doesn't.

The weakness is the supervisor itself. It's a bottleneck and a single point of failure, and as the number of workers grows, the supervisor's context fills up with their outputs. There's a ceiling to how many subordinates one orchestrator can usefully manage before its own reasoning degrades. That ceiling is lower than people expect, often in the range of a handful, not dozens.

Hierarchical (Teams of Teams)

When you hit the supervisor's span-of-control limit, the obvious move is to add layers. A top-level supervisor manages mid-level supervisors, each of which manages a small team of workers. It's the org chart applied to software, and it scales for the same reason org charts do: each manager only has to reason about a few direct reports.

Hierarchy buys you scale at the cost of latency and a longer telephone game. A decision made at a leaf node has to climb back up several levels before it influences the final output, and context gets compressed at each hop. This pattern earns its keep in genuinely large workflows. For a three-step task it's pure overhead. The closely related supervisor-agent architecture deserves its own deep dive, and the line between "supervisor with many workers" and "two-level hierarchy" is where a lot of teams quietly over-engineer.

Pipeline (Sequential Handoff)

The pipeline is the assembly line. Agent A does its part and hands the work to Agent B, which hands to Agent C. Each stage is specialized, the order is fixed, and there's no central manager because the structure is the manager.

Pipelines are underrated. They're the most reliable multi-agent pattern precisely because they're the least dynamic: there are no routing decisions to get wrong at runtime, every stage is independently testable, and you can put a human-in-the-loop checkpoint between any two stages without rearchitecting. A loan-application agent that extracts data, then verifies it, then scores risk, then drafts a decision is a pipeline, and it should be. The downside is rigidity. If the task genuinely needs to branch or loop based on intermediate findings, a pipeline either can't express that or starts smuggling a supervisor into one of its stages.

Peer-to-Peer Collaboration

Here the agents talk directly to each other, negotiate, debate, or divide labor among themselves with no boss. This is the pattern behind the "society of agents" and "AI debate" demos, and it's genuinely useful for a narrow set of problems where multiple perspectives improve the answer, like having a generator agent and a critic agent iterate on a draft.

It's also the pattern most likely to spiral. Without a clear stopping authority, peer agents can loop, mutually reinforce a bad assumption, or stage a polite negotiation that consumes thousands of tokens and resolves nothing. Standardized agent-to-agent (A2A) protocols are starting to give peer communication a shared grammar, which helps with interoperability, but a protocol doesn't supply judgment about when to stop. In production, almost every "peer" system I'd trust has a referee bolted on, which means it's quietly a supervisor pattern wearing a peer costume.

Blackboard (Shared State)

The blackboard pattern borrows from a classic AI architecture: instead of passing messages, agents read from and write to a shared workspace. Any agent can pick up work when the state indicates its skill is relevant, contribute, and update the board. Coordination is implicit in the shared data rather than explicit in messages.

This shines when the work is opportunistic and you can't predict the order in advance, and it maps cleanly onto modern event-driven and async agent designs. The cost is the same cost every shared-mutable-state system has ever paid: contention, race conditions, and the need for careful state management for stateful agents so two agents don't clobber each other's writes. If you've ever debugged a concurrency bug, you know the blackboard pattern is where multi-agent systems hide their nastiest, least reproducible failures.

How to Choose: A Decision Framework

Forget the pattern names for a second and ask three questions about your actual task.

First, who needs to make the routing decision, and when? If routing can be decided up front and never changes, you want a pipeline. If routing depends on intermediate results, you need a supervisor. If routing genuinely needs to emerge from the work itself, only then do you reach for peer or blackboard, and you should be suspicious of that conclusion.

Second, how much shared state is unavoidable? If agents mostly produce independent outputs that get combined at the end, message-passing patterns (supervisor, pipeline, hierarchy) keep things clean. If agents must continuously read and modify a common artifact, the blackboard is honest about that and other patterns just hide the shared state inside the supervisor's bulging context window.

Third, what's your reliability and budget tolerance? Dynamic patterns (peer, blackboard) trade predictability for flexibility. Every bit of runtime autonomy you grant is a bit of determinism you give up, and determinism is what makes a system testable, cheap, and safe to sell on a per-outcome basis.

A useful heuristic: start with the most constrained pattern that can express your task, and only loosen the constraints when you hit a wall you can name. Most teams do the opposite. They start with an ambitious swarm and spend months adding back the structure they removed. McKinsey's research on the shift toward agentic AI in the enterprise makes the same point in business terms: the value shows up when autonomy is scoped and governed, not when it's maximized.

The Coordination Tax Nobody Budgets For

Here's the number that surprises people. In a multi-agent system, a large share of total token spend goes not to doing the work but to coordinating the work: agents describing their findings to each other, the supervisor re-reading worker outputs, context being re-sent at every handoff. Anthropic reported their multi-agent research setup used on the order of fifteen times the tokens of a plain chat interaction. Some of that is the parallelism doing real work. A meaningful slice of it is pure coordination overhead.

This is the coordination tax, and it scales worse than linearly. Every additional agent adds not just its own token cost but the cost of every other agent (or the supervisor) having to account for it. Two agents have one relationship to manage; five agents have ten potential relationships. The patterns that constrain communication, pipeline and supervisor, are partly cost-control mechanisms disguised as architecture. They limit the number of conversational edges in the graph, and each edge is tokens.

For a GaaS operator this is existential, not academic. If your coordination tax eats your per-outcome margin, the more your product succeeds the more money you lose. This is why the boring patterns win commercially: a pipeline's cost is predictable to the token, and predictability is what lets you price.

Handoffs, Context, and the Telephone-Game Problem

The single most underappreciated failure mode in multi-agent systems is context degradation across handoffs. When Agent A passes work to Agent B, it almost never passes everything it knows. It passes a summary, and summaries lose information. By the time work has traveled through four agents, the original intent can be a faded photocopy of itself.

This is the telephone game, and it's why long agent chains are fragile. Each handoff is a lossy compression step. The mitigations are unglamorous but real: pass structured artifacts rather than free-text summaries, keep a shared canonical record of the original goal that every agent can re-read rather than relying on what got handed down, and resist the urge to add agents whose only job is to reformat another agent's output. Every agent you add is another compression step, and the question to ask of each one is whether its contribution outweighs the information it will inevitably lose in the handoff.

There's a deep connection here to the broader context-window economy of agent systems. Coordination patterns are, in large part, strategies for deciding what context lives where and who has to carry it. The blackboard says "put it in shared state." The supervisor says "I'll hold the canonical context and feed workers slices." The pipeline says "each stage gets exactly what the previous stage chose to hand over." Seen this way, choosing a coordination pattern is really choosing a context-management strategy, and the failures of coordination are usually failures of context, not failures of the model.

Coordination as a GaaS Pricing Problem

Step back and the strategic picture sharpens. In the Agentic-AI-as-a-Service model, you're not selling a model; you're selling a reliable outcome at a price that leaves margin. Coordination pattern choice is one of the biggest levers on both reliability and margin, which makes it a business decision wearing engineering clothes.

Predictable patterns let you offer per-task or per-outcome pricing with confidence because you can estimate cost and success rate in advance. Dynamic, autonomous patterns force you toward usage-based or time-based pricing because you genuinely can't predict how much coordination a given task will require, which pushes risk onto the customer and makes your offering harder to sell. The vendors who'll win the vertical-agent markets aren't the ones with the most autonomous swarms. They're the ones who picked coordination patterns constrained enough to price a guarantee against. Andreessen Horowitz's framing of the emerging agentic infrastructure and reasoning stack points in the same direction: the durable value accrues to whoever turns unpredictable autonomy into a dependable, sellable service. Coordination is where that turn happens or fails.

Insights Most People Overlook

Most "multi-agent systems" should be one agent. The reflexive move toward multiple agents is usually premature. A single agent with good tools and a long context often beats a multi-agent system on the same task, with a fraction of the coordination tax and none of the handoff degradation. Multi-agent is justified when you have genuine parallelism, genuinely distinct specializations that don't fit one prompt, or a need for isolated context windows, not just because the task feels big. Reach for a second agent only when you can articulate the specific limitation of the first that it removes.

The "autonomous swarm" is an anti-pattern in production. The demos where dozens of agents self-organize with no hierarchy are research theater. In production they're unpredictable in cost, hard to debug, and prone to consensus loops where agents agree their way into a wrong answer. Nearly every robust system labeled "peer-to-peer" or "swarm" has a referee agent that's really a supervisor. The honest version is to admit you need that authority up front.

Coordination overhead, not model quality, is usually the bottleneck on multi-step reliability. Teams chase a better model when their failures are coming from lossy handoffs and ambiguous routing authority. A weaker model in a well-structured pipeline routinely beats a frontier model in a sloppy swarm. The structure matters more than the IQ of the individual agents, which is exactly backwards from where most engineering attention goes.

Determinism is a feature you're trading away, and you should price it. Every increment of runtime autonomy you grant agents is an increment of testability, cost-predictability, and explainability you lose. That trade is sometimes worth it, but it's almost never made consciously. The teams that treat "how much autonomy" as an explicit dial rather than a default-maximum setting ship more reliable products.

Span of control applies to supervisors too. A supervisor agent degrades as its worker count grows, for the same reason a human manager with thirty direct reports does badly: its working context fills with status updates and it loses the thread. If you find yourself adding a tenth worker under one supervisor, that's the signal to add a hierarchy layer, not another worker. The org-chart intuition is right more often than the distributed-systems intuition here.

References

• How we built our multi-agent research system, Anthropic Engineering
• Why agents are the next frontier of generative AI, McKinsey
• The Agentic Reasoning Era, Andreessen Horowitz (a16z)