You have three specialists. One knows how to search. One knows how to draft. One knows how to act on an external system. Give each a well-scoped job, and they perform well in isolation.
Now ask them to cooperate.
The search result needs to feed the draft. The draft needs to be approved before the action fires. If the search comes back empty, the plan changes entirely. Suddenly, the hard problem isnβt what each specialist does β itβs the wiring between them. Who decides what happens next? Who knows the overall goal? What happens when one specialist fails or takes longer than expected?
That wiring question is what coordination shapes answer. This post deconstructs the main ones, offers a heuristic for choosing, and is honest about what coordination costs in every case.
The coordination shapes
Single agent
The simplest answer: one model, all tools, one context. The agent decides, acts, checks its own output, and returns.
When it fits: the task is short, the path is known, and parallelism adds nothing. A single agent doesnβt coordinate at all β it sequences. Thatβs its strength, and its ceiling.
When it doesnβt: a context window that spans search + draft + action grows unwieldy. Different tools start leaking into each otherβs reasoning. The model starts contradicting itself across long chains.
Orchestrator-worker
One central agent decides and delegates; workers execute and return results. The orchestrator knows the plan; the workers know only their task.
The strength here is a clear chain of command. Itβs easy to read, easy to debug, and easy to add a new worker without touching the plan. When the orchestrator synthesises a coherent answer from the workersβ results, it works well.
The weakness: the orchestrator is a single point of failure and a serialisation bottleneck. Everything waits on it. Under dynamic load, a rigid orchestrator struggles.
Swarm / peer coordination
No central head. Agents emit signals; each agent reacts to what it sees and decides its own next step. Hand-offs are emergent rather than planned.
When it fits: the sequence of work canβt be pre-drawn, because each step depends on what the last step found. Exploratory tasks, open-ended research.
When it doesnβt: swarms are hard to inspect and harder to reason about when something goes wrong. The coordination is implicit, which means debugging requires watching many parallel streams and reconstructing what happened after the fact.
Graph / state-machine (e.g. LangGraph)
The workflow is expressed as an explicit directed graph. Nodes are agents or functions; edges are transitions; conditions route between them. The control flow is structural β it lives in the graph definition, not in any modelβs judgement.
When it fits: the work has a known DAG β a predictable set of states and transitions, even if the path through it varies per run. The graph is inspectable, testable, and deterministic by construction.
When it doesnβt: graphs require the DAG to be known in advance. When the task is genuinely open-ended β when you canβt enumerate the transitions before you run β a fixed graph encodes assumptions that will be wrong.
Chatroom / free conversation
All agents share a message thread. Any agent can read any otherβs output, respond, ask, or hand off. No fixed structure; the conversation itself is the coordination.
When it fits: deliberation or negotiation tasks where the emergent conversation is the point β a multi-perspective review, a debate between evaluators.
When it doesnβt: it generates large amounts of noise. Every agent sees every other agentβs tokens. Context balloons quickly, and it is hard to extract a deterministic output from free conversation.
Hierarchical
Coordinators coordinating coordinators, each managing a sub-team of workers below. Deep trees of delegation.
When it fits: very large work where sub-problems are truly distinct and independently manageable β enough to warrant their own planning layer.
When it doesnβt: deep hierarchies multiply the coordination overhead at every layer, and the cost of passing context up and down the tree grows quickly. This is usually a sign the problem should be decomposed differently before you add coordination.
How to choose
The decision isnβt about which architecture looks most capable β itβs about the problemβs actual shape.
Start with the taskβs predictability. Can you draw the DAG before you run? If yes, a graph or state-machine encodes it directly and runs deterministically. If no β if each step reveals what the next step is β you need something more adaptive.
Then look at the hand-off pattern. If a central agent should own synthesis (the final answer must integrate everything and make sense), an orchestrator or CWD gives you that. If the work can be chunked and results aggregated without a synthesising mind over them, workers in parallel suffice.
Then consider how much autonomy the agents need. A swarm or chatroom gives each agent local authority. Thatβs exactly right for exploratory or deliberative tasks, and exactly wrong when you need a predictable output under a budget constraint.
A rough heuristic:
- Known DAG with fixed transitions β graph / state-machine
- Emergent hand-offs, exploratory β swarm
- A planner that must own synthesis, dynamic work β orchestrator or CWD
- Deliberation, multi-perspective review β chatroom
- Single short task, a few tools β one agent
CWD as a deterministic runtime
Within the orchestrator family, the CWD pattern β Coordinator, Worker, Delegator β adds one structural commitment: the Delegator, the middle layer between planning and execution. The Coordinator decides what and synthesises. The Workers execute. The Delegator decides who, when, and how much at once β managing load, fault tolerance, and dynamic reassignment without burdening the Coordinator or the Workers with those concerns.
The underlying thesis, as Felesh frames it: intelligence at the edges, determinism in the middle. The Workers and Coordinator are language models β they reason, adapt, and handle uncertainty. The Delegator and the control flow between roles are deterministic infrastructure. Predictability and debuggability come from the middle; capability comes from the edges.
The CWD anatomy β including how context flows up and down the spine and why the Delegator is the role most often skipped β lives in full at The Coordinator, the Worker, and the Delegator. This post references that structure without recapitulating it.
Where coordination loses
Every multi-agent shape shares one honest cost: coordination is expensive.
Community and design work in the field puts the token overhead at roughly 15Γ or more compared to a single call (a widely reported finding in the literature β not a Felesh result). That cost comes from context passed between roles, models deciding on behalf of other models, and synthesis steps that re-read everything. For a simple or medium-complexity task, that overhead buys nothing. A single well-scoped agent is almost always the right answer for those.
There is also an operational cost: more agents mean more things that can fail, more logs to inspect, and more edge cases in the hand-off logic. The event-driven reliability patterns that keep a multi-agent team from dropping messages are themselves additional engineering β as covered in detail in Event-driven by design: agent teams that donβt lose messages.
The rule is the same as Anthropic states in Building Effective Agents: reach for multi-agent coordination only when a single agent has genuinely hit its limit β when the work is too broad for one context, or when parallelism is the only way to meet the requirement. Start with the simplest structure that could work, and add coordination when you have a concrete reason, not a preference for architecture.
Coordination shapes are not a ladder where more sophisticated is better. Theyβre options with costs. The right shape is the one that matches the problemβs actual structure β and the most useful thing to know about any coordination pattern is the case where you shouldnβt use it.