Concurrency Conflicts in Multi-Agent Codebases

Concurrency conflicts in multi-agent codebases require more than familiar locks and retries. Long inference windows, opaque read sets, and immediate writes to live state change the cost and feasibility of classical controls. Production coordination therefore needs distinct layers for isolation, runtime conflict handling, accountable write admission, and validation of the combined result.

Why multi-agent coding creates a concurrency problem that classical computer science has not already solved

CoAgent, by Lyu et al., documents a Kubernetes case in which two agents succeed individually but leave the cluster unsafe. Agent A scans deployments before there is a canary, while Agent B reads an image before A fixes it. Their interleaved actions leave a canary on a known-bad image silently waiting to take live traffic. Yet the final cluster state matches no serial execution of their actions, which makes the outcome a concurrency anomaly.

The anomaly is familiar to classical computer science, but the shape of the work makes its standard remedies a poor fit. An agent transaction spans minutes of inference rather than microseconds, leaving a long interval in which another agent can invalidate its assumptions. Its read set is broad and opaque because it does not declare every file or resource it will consult beforehand. Live state adds another constraint because a Kubernetes operation cannot simply be buffered like an uncommitted file edit.

How the three classical responses — serialization, locking, and optimistic retry — each break at agentic timescales

Serialization avoids unsafe interleaving by running one agent at a time. However, it also discards the parallelism that justified deploying multiple agents. Two-phase locking, or 2PL, allows concurrent work in principle but holds contending agents behind locks across the inference interval. Lyu et al. describe a “performance gap” when protocols assume transactions are short enough for blocking to be acceptable. They distinguish this from a “functionality gap” when protocols assume shared state is plain data that can be forked and merged.

Optimistic concurrency control, or OCC, lets work proceed but aborts and retries when a conflict invalidates it. At agentic timescales, that retry discards minutes of inference. Lyu et al. report that both 2PL and OCC surrender nearly all concurrency gains on contended workloads. These protocols continue to detect conflicts, but their responses become disproportionately expensive.

Fork-and-merge offers a practical escape for code that can live in separate branches. However, Lyu et al. characterize its isolation as weak, akin to “read committed” in databases. It postpones integration decisions until merge time rather than preventing agents from making incompatible decisions about a shared API. That distinction matters when success on each branch is mistaken for correctness of the combined system.

What scale-level data shows about how frequently these conflicts actually occur in practice

AgenticFlict examined a large corpus of agent-authored pull requests across GitHub and extracted hundreds of thousands of fine-grained conflict regions. It found that cross-agent conflicts occur roughly twice as often as intra-agent conflicts within the same repository. Different agents can choose different architectures for the same problem, with one modifying a component while another deletes and replaces it. If agents cannot see each other’s branches and have no protocol for claiming files, they make those decisions on their own until integration.

The conflict taxonomy explains why counting overlapping lines understates the burden. Content conflicts arise when agents edit overlapping lines and can sometimes be resolved mechanically. Modify/delete conflicts need a decision on whether to keep an edit or remove the file, while add/add conflicts occur when agents put different new contents at the same path. These structural conflicts are the most expensive because they are not mechanically mergeable. Most by far are in source code rather than dependency lockfiles, so they concern logic rather than package-lock.json churn.

Even that evidence captures only the measurable floor. A textual merge can work even when the combined code fails to compile, which is a build conflict. The code can also build and pass tests but behave incorrectly, which is a semantic conflict.

Why static write-set partitioning and file-ownership schemes help at planning time but cannot cover agents whose write sets emerge during execution

Static partitioning removes many conflicts before execution by assigning agents separate files or subsystems. When one agent owns authentication and another owns payments, clear boundaries make this the lowest-overhead approach. For well-decomposed tasks with known write sets, it should be the default.

The limit appears when investigation changes the required scope. An agent assigned a payments bug may discover that its cause lies in a shared utility that another agent also depends on. Preserving the original partition then requires stopping the other agent, replanning, or accepting a boundary violation. Ownership conventions cannot decide this case in advance because the write intent did not exist at planning time.

Huang’s ATM frames this as a pre-write admission gap. Once agents have formed intents, the system must decide which can proceed together, which require serialization, and which must fail closed. Both ATM and CoAgent address this runtime coordination point rather than assuming that planning can settle every future access. Partitioning remains the first defense, but it needs a mechanism for work that crosses its boundaries.

How advisory concurrency control turns the LLM's own reasoning into the conflict-resolution mechanism

CoAgent uses a capability that classical transactions lack, namely the agent’s ability to judge whether a change actually invalidates its plan. It implements MTPO, or Monotonic Trajectory Pre-Order, as toolcall middleware. MTPO fixes a serialization order at launch, gives agents order-filtered reads, and applies writes speculatively in place. When Agent B’s write conflicts with Agent A’s read, a one-way notification asks A to reassess the dependency. The runtime reports the conflict instead of treating it as an automatic reason to abort.

If the plan remains valid, the agent continues. If it does not, the agent repairs the dependent operations. The framework mechanically undoes and reorders misplaced writes through saga-style inverses registered by the tools. This separates the judgment about a plan’s validity from the machinery that restores write order. The practical gain is preservation of the inference already spent on unaffected work.

CoAgent reports results within 5% of serial correctness on ten contended workloads, with a 1.4× speedup and near-serial token cost. Those results support advisory control as a useful response to contention. The approach also requires every tool to register an inverse in advance. That instrumentation is a substantial constraint when agents use many external tools or perform side effects that are difficult to undo.

How pre-write admission gating provides a governance-compatible alternative when agent writes must be auditable before they execute

Advisory repair addresses whether concurrent work remains correct, but governance also asks who had authority to mutate shared state. Huang’s ATM places an admission decision before a governed write executes. Its Content Identifier, or CID, broker routes intents to parallel admission, deterministic composition, serialization, or a fail-closed path. A neutral steward then applies governed shared writes rather than leaving that authority with the proposing agent. This separation makes the admission decision distinct from the agent’s desire to proceed.

ATM binds task intent, repository scope, write admission, validation, and evidence obligations into one governance chain. When the persistent atom map has gaps, virtual atoms provide temporary governance units that can be audited for write sets that take shape as agents work. The design supports accountability for which agent proposed a change, under what task authorization, and with what admission decision before execution.

That claim has a clear boundary. ATM does not replace Git merge or address cross-clone or cross-PR governance. Its scope is auditable admission within a single governance domain. Admission gating consequently complements correctness-oriented controls rather than resolving every downstream integration problem.

What git worktree isolation actually prevents and what it leaves exposed at the semantic and build layers

Git worktrees remain the right execution baseline for parallel coding agents. Each agent has its own working directory, branch, index, and file state, but they share commit history. This prevents simultaneous edits from corrupting a shared working tree. It removes the destructive file-level collision without forcing all agents to run serially.

The remaining exposure is easiest to see across files. Agent A can rename a function in utils.py while Agent B adds a call to the old name in main.py. Their separate branches can be internally consistent, yet the merge produces a broken import. Similarly, deleting a supposedly unused method conflicts with another agent’s decision to add a caller. Incompatible assumptions about a shared API can survive compilation and branch-level tests while violating the combined semantic contract.

CI must validate every merge because the merged state is the state that needs to work. When write intents overlap, worktrees also need a way to signal that overlap to each other, though ATM itself does not cover cross-clone or cross-PR governance. Structural changes require human or agent-assisted semantic review, including API changes, function deletions, and module reorganizations.

How human review bottlenecks and autonomous test repair failures compound the coordination problem at throughput

Once agents stop interfering with each other’s files, the amount of validation they can get may limit how much work gets through. If several agents finish together and reviewers cannot keep up, parallel execution leaves work in a queue and delivery gets no faster. Coordination therefore has an organizational boundary as well as a technical one. Plans for agent throughput have to take into account how much work humans can review.

A 2026 arXiv study on autonomous test repair found that only 14% of repair attempts reached full completion. That result gives no grounds for making autonomous repair the main gate for work that agents produce in parallel. Reducing conflicts earlier through partitioning, advisory control, or admission gating reduces the need for human arbitration at merge time. Hierarchies of planners, workers, and judge agents give another way to share the work of checking results. With either approach, the value of adding more agents still depends on how much validation the team can handle.

What a layered coordination architecture looks like in practice for a team running agents in production

A production design begins by assigning well-bounded tasks through file-ownership or module-ownership conventions that agents can consult. This planning layer should cover known, non-overlapping write sets and leave runtime controls to handle work that turns up outside them. Each agent then works in its own worktree and branch. Results merge when tasks are done rather than throughout the work, so integration happens at a chosen boundary.

Contended shared resources need a further decision point when write intents emerge. CoAgent-style advisory control uses the agent’s judgment to preserve useful inference, while ATM-style admission establishes whether a governed write may execute. The choice depends on whether throughput or auditability is the primary requirement, within each mechanism’s stated scope. Where both correctness and accountability matter, these responsibilities complement each other.

The integration layer must run build and semantic validation on every merge before it can treat the combined branch as correct. Structured tests need assertions that agents cannot silently delete, with those assertions reviewed and version-controlled like other code. This layer evaluates the result of concurrent work rather than trusting separate branch successes. It also connects runtime coordination to the review capacity needed to accept that work.

Finally, observability and cost controls belong at the session level. Every tool call, diff, and token should be attributable to a specific agent session and trigger, while session budget caps bound the cost of retry loops during conflict storms. Configuration for every layer belongs in the repository, reviewed, versioned, and deployed like infrastructure code. Together, these layers make parallel execution useful by controlling not only who can work at once, but whether their combined work is correct, accountable, and affordable.