You build one good agent. It answers well, it calls a few tools, it holds a short conversation. So you give it more to do. Now it looks up an order, checks a policy, drafts a reply, and books a follow-up β all in one long prompt. And somewhere around the fourth responsibility, it starts to slip. It forgets what it decided two steps ago. It calls the wrong tool with the right arguments. It contradicts itself politely. The prompt that was supposed to make it capable has quietly made it unreliable.
The usual next thought is: split it up. One agent to look things up, one to draft, one to act. Many agents instead of one.
That instinct is right, but it is not free, and it is not automatic. βMany agentsβ is not a better system β it is a different system, with its own failure modes and a cost most people underestimate. Before you build one, it is worth knowing that the shape you are reaching for already has a name and a set of honest trade-offs.
First: you probably donβt need this yet
Most of the reliability you lost above, you can get back without a second agent. Tighten the scope. Give the one agent fewer tools and a clearer job. Move the fixed parts of the work out of the model and into plain code. A large share of βwe need a multi-agent systemβ turns out to be βwe need one well-scoped agent and a bit of ordinary software around it.β
So the first question is not how do I coordinate many agents β it is do I need many at all. That question belongs in its own place (β βYou might not need an agentβ), because getting it wrong is expensive in a specific, measurable way this post returns to at the end.
If you have genuinely hit the ceiling of one agent β the work is too broad for one context, it spans tools that donβt belong together, it needs several things to happen at once β then you need a structure for the many. This post is about the most studied one.
The pattern: Coordinator, Worker, Delegator
The pattern is called CWD β Coordinator, Worker, Delegator. It is an established, documented pattern, not a novel invention, and it is easiest to understand the way it was first framed: by analogy to how a human organisation divides labour. A strategy layer, a management layer, and a layer that does the work. Three roles, three levels.
The Coordinator sits at the top. It owns the goal, not the doing. It takes a request, breaks it into parts, decides what needs to happen and in what order, and β at the end β puts the pieces back together into one answer. It is the only role that holds the whole picture. It plans and it synthesises; it does not, itself, book the flight.
The Worker sits at the base. A Worker is a specialist: it does one kind of thing well β search, or drafting, or a single class of action β and it does not need to know why. You hand it a well-formed task; it hands back a result.
The Delegator sits in the middle β and this is the role most people skip. The intuitive picture is that the Coordinator hands work straight to the Workers. In the CWD model it doesnβt. The Delegator is the layer between strategy and execution: it takes the Coordinatorβs plan and matches it to the Workers actually available β their capabilities, their current load, whatβs already in flight. It distributes and balances. If the Coordinator decides what and the Worker does it, the Delegator decides who, when, and how much at once.
That middle role is easy to overlook because in a small system you can fuse it into the Coordinator and not notice. You notice the moment the system grows: when five things can run in parallel, when one Worker is a bottleneck, when a task needs to move because its first owner failed. Dynamic allocation, load balancing, fault tolerance through redundancy, even reassigning roles at runtime β those are all Delegator concerns. Strategy shouldnβt have to think about them, and execution canβt.
Information flows both ways along this spine: plans, priorities and constraints go down; progress, results and status come back up. That upward flow is not decoration β itβs what lets the Coordinator re-plan when reality disagrees with the plan.
Where CWD loses
A pattern earns trust by admitting where itβs the wrong choice. CWD has three honest weaknesses.
Itβs expensive. Running a coordinated set of agents costs far more than a single call β community and design work in the field puts the difference at roughly 15Γ or more in token usage (this is a widely reported finding in the literature). You are paying for the coordination, the passing of context between roles, the synthesis at the end. For a task a single agent can already do, that spend buys you nothing.
Itβs overkill for most work. The failure we opened with β one agent buckling under four jobs β often has a smaller fix than a three-layer hierarchy. Simple and medium tasks are usually better served by one well-scoped agent, or by a fixed workflow where the path is known in advance. Reach for CWD when the work is genuinely broad, parallel, or too large for one context β not before.
Itβs one shape among several. CWD is not the only way to arrange many agents, and not always the best. There is the single agent; the orchestrator-with-workers; the peer swarm with no central head; the graph or state-machine where control follows explicit transitions; the open chatroom where agents talk freely; the deep hierarchy of coordinators over coordinators. Each fits a different problem, and choosing among them is a real decision with real trade-offs (β βHow agent teams coordinate: how to chooseβ). CWDβs strength is that a clear middle layer makes it legible and controllable; its cost is the coordination overhead it shares with every multi-agent shape.
The takeaway
A multi-agent system is not a smarter agent β itβs a structure. CWD names that structure honestly: a Coordinator that plans and synthesises, Workers that execute, and β the part not to skip β a Delegator in the middle that matches work to capacity.
And the most useful thing this pattern teaches is when not to use it. Many agents cost more, fail in more ways, and earn their place only when one agent genuinely canβt do the job. Thatβs not a limitation to apologise for β itβs the whole point of choosing a shape on purpose.
Further reading
- Biswas & Talukdar, Building Agentic AI Systems, Ch. 6 β the CWD model in full.
- Anthropic, Building Effective Agents β the case for simplicity-first, and workflow-vs-agent as a deliberate choice.