Academy

The Coordinator, the Worker, and the Delegator

One agent can only carry so much. When you split the work across many, you need a shape for who decides, who does, and who keeps the whole thing balanced. That shape has a name.

The Felesh team 8 min

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.

Four jobs in one promptOne agent works through four jobs on order A-2210: it looks the order up, reads the return policy (30 days), drafts a reply offering a refund, and books a follow-up. Each job fills the same prompt. Past a line on the context gauge it slips: the follow-up says return by day 45, contradicting the 30 days decided at step 2.one agent, one promptcontext1 look up orderA-2210, bought 12 Jun2 check policyreturns: 30 days3 draft replyoffer a refund4 book follow-upreturn by day 45slipsstep 4 contradicts the 30 days from step 2
Each added job fills the one prompt, until the fourth decision contradicts the second.

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.

Three roles, one spineA request, refund A-2210 and book a call-back, goes to the Coordinator at the strategy level. The plan and limits pass down to the Delegator at the management level, which hands the three tasks to three Workers at the execution level: look up A-2210, draft the reply, book the call-back. Each Worker returns a result; status and results pass back up the spine, and the Coordinator assembles one answer.strategymanagementexecutionRefund A-2210 and book a call-backCoordinatorplans, then assemblesplan, limitsstatus, resultsDelegatorwho, when, how many at onceWorkerlook up A-2210Workerdraft the replyWorkerbook call-back
The Coordinator plans, the Delegator matches each task to a Worker, and results climb back up the same spine.

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.

The Delegator rebalances and reroutesFive order look-ups, #2210 to #2214, sit with three Workers. Worker A holds four and is a bottleneck while Worker C is idle. The Delegator moves #2212 and #2213 to Worker C. Worker B then fails, and its look-up #2214 is rerouted to Worker A. The Coordinator never has to think about any of it.five order look-ups, three WorkersDelegatorwatches eachWorker’s loadand healthWorker AWorker BWorker C#2210#2211#2212#2213#2214#2212#2213#22144 queuedbottleneck2 queued3 queued1 queuedfailedidle2 queuedthe Coordinator never had to think about any of this
The Delegator rebalances an overloaded Worker and reroutes the task of one that fails, so the Coordinator never has to.

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.

What coordination costsTwo bars for the same task, answering a customer about refund A-2210. One agent in one call is the 1× bar. The coordinated run adds the same task work and then a dashed span of coordination, context passed between roles and synthesis, reaching 15× or more. If one agent can already do the task, the extra spend buys nothing. The figure is widely reported, not a measurement of this example.one task: answer a customer about refund A-2210one agent, one call1×Coordinator + Delegator + Workers15× or morecoordination · context passed between roles · synthesisIf one agent can do it, the extra spend is wasted.a widely reported figure, not a measurement of this example
For the same task, the coordinated run is reported to cost 15× or more in tokens, and for work one agent could do, that spend buys 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.

Seven shapes for many agentsA map of seven ways to arrange agents. Six tiles: a single agent with one context; an orchestrator with its workers; a swarm with no central head; a graph, a state machine with explicit transitions; a chatroom where agents talk freely; and a deep hierarchy of coordinators. Below them CWD, drawn as a Coordinator, a Delegator and three Workers: its clear middle layer makes it legible and controllable, and the price is coordination overhead.single agentone contextorchestratorhub and workersswarmno central headgraphstate machinechatroomtalk freelyhierarchymany levels deepCWDa clear middle layer makes it legibleand controllable; the price is overhead
CWD sits among six other ways to arrange agents: its clear middle layer buys legibility and control, at the coordination cost every multi-agent shape shares.

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.