Academy

How agent teams coordinate: a guide to choosing the right shape

When several specialists must cooperate, the wiring between them is the whole problem. Here are the shapes available, and how to choose.

The Felesh team 10 min

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 wiring between three specialistsA ticket, order #7720 arrived cracked, passes through three specialists: search finds the order, draft writes the reply, act sends the replacement. First the search result, 2 matches, feeds the draft. Then the draft needs approval before the action fires and the replacement is sent. On another run the search returns 0 matches, so the plan changes and the customer is asked instead. Who decides what happens next is the wiring.ticket: order #7720 arrived crackedsearchfinds orderdraftwrites replyactsends swap2 matches0 matchesreply v1swap sentapprove?empty: ask the customer insteadthe wiring between themsearch result feeds the draftthe draft needs approval before the action firessearch comes back empty: the plan changeswho decides what happens next? the wiring does
Each specialist is fine alone; the open questions all sit on the wires between them, and an empty search changes the plan.

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.

One orchestrator, three workersThe orchestrator holds a three-step plan: find order #7720, draft the reply, create the swap. It hands each step to one worker, which knows only its task, and gets a result back: 2 matches, reply v1, swap sent. It then writes one answer: swap on its way for #7720. Everything waits on the orchestrator, so it is a single point of failure.answer: swap on its way for #7720orchestrator1 find order #77202 draft the reply3 create the swapsearch workerdraft workeract workertask: find #7720task: write replytask: ship swap2 matchesreply v1swap senteverythingwaits here
The orchestrator holds the plan and each worker holds only its task, which is easy to read, and everything waits on the one box in the middle.

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.

A route no one plannedFour peers, search, check, draft and act, with no head, pass signals along. One: search tells check the item is discontinued. Two: check tells draft to substitute model B. Three: draft tells act the reply is ready. Four: act reports model B is out of stock, which sends the work back to check. Nobody planned this route and it can only be rebuilt after the fact.four peers, no head, signals onlysearchcheckdraftact1234discontinuedsubstitute: model Breply v1 readyB out of stockno one planned this routeyou rebuild it after the fact
In a swarm each agent reacts to the last signal, so the route only exists once it has run and you rebuild it afterwards.

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.

Two runs through one graphA fixed graph: search, a found check, draft, an approved check, act. Run one, order found: search, found, draft, approved, act. Run two, order missing: search, found fails and the route goes to ask the customer. A failed approval would loop back to redraft. The graph, not a model, decides the route.run 1: order foundrun 2: order missingsearchfound?draftapproved?actnono: redraftask the customersame graph, two routes; no model chose either
A graph fixes the nodes and the conditions in its definition, so two runs take different routes through the same graph and no model chose either.

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.

Every agent reads the whole threadA shared thread grows by five messages: search found order #7720, draft wrote reply v1, check asked whether the swap is in stock, search added that #7701 is open too, draft asked whether to merge both replies. Beside it, the context of each of the three agents, search, draft and check, grows by one block per message, so five messages times three agents is fifteen reads.shared threadwhat each agent readssearch: order #7720 founddraft: reply v1 for #7720check: swap in stock? 1 leftsearch: #7701 is open toodraft: merge both replies?searchdraftcheck5 messages × 3 agents = 15 reads, and growing
In a shared thread every agent reads every message, so five messages across three agents is fifteen reads and the context balloons.

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
Which shape for which taskA table of five tasks. A task you can draw before it runs, such as search, draft, approve, act: graph or state machine. A task where each step reveals the next, such as why returns spiked in June: swarm of peers with signals. A task where one mind must own the final answer, such as merging three reports: orchestrator or CWD. A task where the debate is the point, such as two reviewers arguing a policy: chatroom with a shared thread. A short task with a few tools, such as looking up order #7720: one agent, no coordination.if the task is…pickfor examplea task you can drawbefore it runsgraphstate machinesearch, draft,approve, acteach step revealsthe next oneswarmpeers, signalswhy did returnsspike in June?one mind owns thefinal answerorchestratoror CWDmerge 3 reportsinto one replythe debate isthe pointchatroomshared threadtwo reviewersargue a policyshort task,a few toolsone agentno coordinationlook up order#7720
Pick the shape from the task: a drawable task gets a graph, an open one a swarm, and a short one a single 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.

Models at the edges, code in the middleThree lanes. Top, a model: the coordinator decides to replace order #7720. Middle, plain code: the delegator hands the draft to worker 1. Bottom, models: worker 1 is drafting, then times out. The delegator, still plain code, hands the draft to worker 2, which returns reply v1. The model failed, the plan did not.modelcodemodelscoordinator: replace order #7720delegator: draft goes to worker 1delegator: timeout, draft goes to worker 2worker 1worker 2draftingtimed outstandbydraftingreply v1the model failed, the plan did not
In CWD the models sit at the edges and plain code in the middle, so when a worker times out the delegator, not a model, hands the work on.

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.