One agent doing one job is fairly easy to reason about. Put three or four agents on the same work and new problems appear that none of them would have alone. Two agents reply to the same customer. One cancels an order another has just confirmed. A pair of agents hand a task back and forth forever, each sure the other should do it. These are coordination failures, and they are a common reason multi-agent systems disappoint. The good news is that the patterns for avoiding them are well understood.
The four ways agents trip over each other
Most coordination problems fall into one of four types. Naming them makes them easier to spot.
- Duplication. Two agents do the same work because neither knew the other had started. The customer gets two replies, or the supplier gets two purchase orders.
- Conflict. Two agents change the same thing in opposite directions. One marks stock as reserved, the other releases it.
- Gaps. Each agent assumes another will handle a case, so nobody does. A complaint sits untouched for days.
- Loops. Agents pass work between themselves without progress, burning time and model costs.
When you review a proposed design, walk through a normal day and ask where each of these could happen. It is a cheap exercise and it catches most problems before any code is written.
Pattern one: a single owner for every piece of work
The simplest and most reliable rule is that every task, order or case has exactly one owner at a time. Ownership is recorded somewhere all agents can see, such as a row in a database with an “owner” field.
Before an agent acts, it claims the item. If someone else already owns it, it leaves it alone. When it is done or stuck, it releases the item or hands it on explicitly. This is the same idea as a ticket system in a help desk, and it works for the same reasons.
A small detail matters here. The claim must be atomic, meaning two agents cannot both succeed at claiming the same item at the same instant. Databases offer this through locks or conditional updates. Skipping it is how duplication creeps back in under load.
Pattern two: an orchestrator that assigns work
In many business systems, the cleanest shape is a central orchestrator. It receives incoming work, decides which specialist agent should handle it and tracks progress. The specialists do not talk to each other much. They talk to the orchestrator.
This resembles the classical contract net idea from multi-agent systems research: a manager announces a task and awards it to a suitable worker. In practice, for a small business, the “announcement” is often just a routing rule. Delivery questions go to the delivery agent, refund requests to the refunds agent, anything unclear to a person.
The strength of this pattern is visibility. There is one place to look to see what is happening. The weakness is that the orchestrator becomes a single point of failure and a bottleneck. For most small and medium firms, that trade is worth it.
Pattern three: shared state instead of chatter
A common mistake is to have agents coordinate by sending each other long messages. Each message is interpreted by a language model, which may read it slightly differently each time. Errors compound.
A better approach is to coordinate through shared, structured state. Instead of Agent A telling Agent B “I have confirmed the order and the customer wants it delivered on Friday”, Agent A updates the order record: status confirmed, delivery date Friday. Agent B reads the record. There is nothing to misread.
This is close to the blackboard idea from older research, where specialists write to and read from a common workspace. It also gives you a free audit trail, because every change to the record can be logged with who made it and when.
Hard limits, and when to skip multiple agents
Limits that stop runaway behaviour
Even good designs need hard stops. Useful ones include:
- A maximum number of handoffs per task. After, say, three transfers, the task goes to a person.
- A time limit. Anything unresolved after a set period is flagged.
- A spending cap per task and per day on model usage, so a loop costs little before it is caught.
- A rule that anything touching money or reaching a customer needs a clear owner and, where it matters, a person’s approval.
When not to use several agents at all
Coordination has a cost. Every extra agent adds messages, states and failure modes. Many jobs that are pitched as multi-agent systems work better as one agent with several tools, or as a plain script with one model call in the middle.
A fair test: can you explain why each agent needs to be separate? Good reasons include different permissions (the agent that reads customer data should not be the one that sends mail), different models for cost, or genuinely different skills. “It seemed more advanced” is not a reason.
If you are planning a system with more than one agent, sketch it on paper first: the agents, the work items, who owns what and where state lives. Our agent blueprint tool walks through the same questions, and a clear sketch usually shows whether you need one agent or several.