Multi-Agent Conflict Resolution Without the Folklore

Agentic AI

When multiple agents share state, conflicts are not edge cases, they are the steady state. Leader/follower, consensus, last-writer-wins with reconciliation. We share which patterns hold up and when single-agent is the better answer.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 29, 2024 · 7 min read

A team came to us with three agents (planner, executor, critic) that kept overwriting each other's edits to a shared task list. The proposed fix was a fourth agent to resolve conflicts. We took two of the agents out instead. Throughput went up 40 percent, error rate dropped, and the resulting system was easier to reason about than the four-agent design would have been.

Multi-agent is the hardest architecture pattern in this space and the most over-applied. When it earns its place, it is genuinely powerful. When it does not, you have built a distributed system inside an LLM context for no reason. Both cases are common.

When multi-agent is the right answer

Three signals that justify the complexity.

• The agents have genuinely different objectives that conflict productively (planner wants long-term value, executor wants throughput, critic wants accuracy).
• The agents need different prompts and tool sets that would not factor cleanly into a single agent's context.
• The agents operate at different time horizons or cadences (a real-time agent and a batch reviewer).

If two of these apply, multi-agent often pays for itself. If only one applies, a single agent with multiple modes (or prompts swapped per phase) is usually simpler and just as effective.

Conflict patterns we see

When agents share state, conflicts are inevitable. They show up as race conditions on shared documents, contradictory tool calls, plan thrashing, and outright loops where one agent undoes the other's work. The patterns to handle them, in increasing order of complexity.

1. Last-writer-wins with reconciliation: simplest, works when conflicts are rare and recovery is cheap. The agent that writes most recently wins, with a reconciler that sweeps periodically to catch contradictions.
2. Leader/follower: one agent owns each piece of state. Other agents propose changes; the owner accepts or rejects. Cleaner semantics, more coordination overhead.
3. Consensus: multiple agents must agree before a change commits. Strongest guarantees, highest latency cost. Reserve for high-stakes decisions where wrong is worse than slow.
4. Phased coordination: only one agent acts at a time, by design. Phases are time-boxed. Conflicts cannot occur because writes are serialised. Often the right answer hidden inside a too-clever multi-agent design.

On the planner-executor-critic team above, we replaced free-running coordination with phased coordination: planner runs, executor runs, critic runs, repeat. No conflicts because no concurrent writes. The work the four-agent design was trying to do was achievable in a serial pipeline. The pipeline was what they actually needed.

Shared state, shared blast radius

Whatever pattern you pick, draw the boundary around shared state explicitly. Every multi-agent failure we have investigated traces back to state that one agent could write while another was reading, without either knowing. Make the shared state explicit, version it, and require all writes to go through a single guarded path. This is database design, not agent design, but multi-agent is database design at heart.

Detection signals for multi-agent gone wrong

We add these to the dashboard on every multi-agent engagement.

• Per-agent action rate. If one agent dominates by 10x, the architecture is wrong.
• Inter-agent message volume per task. Climbs when agents are negotiating instead of working.
• Conflict rate, defined as one agent's action overturning another's within a window. Above 5 percent and the coordination pattern is broken.
• Plan revision count across the system, not just per agent. Catches whole-system thrash.

If any of these flags red on a healthy single-agent baseline you could have shipped instead, the multi-agent architecture is not paying for itself yet. That is fine in the first month. It is a problem after three.

When to collapse back to one agent

We have collapsed multi-agent designs back to single agents three times in the last year. Two of those collapses came after the team said it was impossible. In each case, the second-pass single agent had clearer mental model, fewer bugs, and roughly 30 percent lower cost per task.

Multi-agent is a real tool. It is also the seductive tool that makes a system look more sophisticated. Build for the simplest architecture that solves the problem and graduate up only when the data demands it. The data demands less often than the conference talks suggest.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.