Merge Conflict Resolution Across Parallel Agent Worktrees

When multiple AI coding agents share a single checkout, they can overwrite each other's edits, and nothing warns them. The last write wins, earlier changes vanish, and nothing in the process raises an error. Git worktrees exist to stop that specific failure: each agent gets its own branch, its own working directory, and its own private index, all pointing back to one shared object store. That isolation solves a narrower problem than it looks like it solves. Worktrees don't eliminate conflicts between agents' work; they postpone them, moving the collision point from the middle of a task, where it would otherwise corrupt files silently, to the merge, where ordinary git tooling can actually see it.

That shift is worth making. Silent corruption is worse than a visible conflict, because nobody knows to go looking for it. But deferring a conflict is not the same as resolving one, and when many agents work at once, the place where their work comes back together becomes the bottleneck for the entire operation. The rate of conflict between two agents is also higher than the rate within a single agent's own sequential work, because different coding agents tend to make different stylistic and architectural choices when solving the same kind of problem. One agent refactors a function in place; another deletes it outright and writes a replacement. Both produce working code in isolation. So they produce a modify/delete conflict, and git cannot resolve it on its own.

The friction that builds up at the merge boundary comes in three layers, and only the first is visible to standard tooling. Textual conflicts are what git actually flags: overlapping edits to the same lines. Build conflicts sit one level up, where the merge completes cleanly but the resulting code fails to compile or fails lint. Semantic conflicts sit above both: the code builds, the tests pass, and the program still behaves incorrectly at runtime because two agents made assumptions about each other's work that turned out to be false. Counting textual conflicts alone understates the real cost of integrating parallel agent work, and the rest of this piece is organized around closing that gap, one layer at a time.

The three structural causes of merge conflicts in parallel worktrees

Three structural causes account for nearly all conflicts in parallel agent worktrees, and each one points toward a different fix.

The first is shared hotspot files: routes, configuration files, database migration registries, shared manifests, the small set of files that almost every task in a repository eventually has to touch. If one agent adds a new database migration and a second agent adds a different migration to the same schema, a conflict is not a risk, it's a certainty. These files are predictable, which makes them solvable through upfront planning. They are the reason task partitioning, covered next, has to happen before any agent starts writing code.

The second cause is scope creep: an agent assigned a narrow task drifts into files adjacent to that task. A fix for a failing test quietly refactors a shared helper function along the way. No ownership map, however careful, can anticipate every instance of this, because the drift happens inside a task that looked properly scoped at the outset. Catching it requires watching the diff while the agent is still working, not discovering it after the fact. Early detection during the work itself matters as its own layer, separate from upfront planning.

The third cause is generated files. When one agent regenerates and commits an architecture artifact or an inventory manifest, the generated file encodes a snapshot of the whole repository, so every other branch in flight now conflicts with it by construction. The fix is a rule, not a tool: agents should not commit generated files. A coordinator regenerates them once, after every branch has merged.

These causes leave behind two conflict types that resist mechanical repair, no matter which one produced them. Add/add conflicts happen when two agents each create a file at the same path, but with different contents. Modify/delete conflicts happen when one agent edits a file that another agent has deleted. An analysis of a large real-world agent-generated commit dataset found that modify/delete conflicts alone make up 26.8% of all conflict regions, and both types force a judgment call about which architectural decision should win, a call no merge tool can make on its own.

One more cause deserves mention only so it can be dismissed: git lock contention, where multiple processes fight over a single .git/index.lock file, disappears entirely under worktrees, since each worktree carries its own index. That's a solved problem. It belongs in this list only to be cleared off the table before the harder causes get attention.

Task partitioning before agents start: preventing conflicts that cannot be resolved well later

The cheapest conflict to resolve is the one that never happens, and the single most reliable way to prevent conflicts is an ownership map drawn up before any agent starts working. The map lists which files each task will touch and checks that no file path appears in two agents' assigned scopes. If two tasks genuinely need to touch the same file, those two tasks get sequenced, one after the other, rather than run side by side under the illusion that they're independent.

This is design work, not paperwork. It requires knowing which files a task will touch before the task runs. That means thinking through the dependency structure of the codebase before handing out tickets. Shared hotspot files need explicit ownership decisions made at this stage: either one agent is designated the migration owner for any schema change that task cycle, or the set of tasks is restructured so that each agent's changes stay confined to its own tables. Coordination itself needs the same discipline. A shared checklist file, updated by a dozen agents as they each complete steps, turns into its own conflict surface the moment more than one agent writes to it at the same time. If you use GitHub Issues or a local ticketing system instead, agents get a coordination surface that lives outside the working tree entirely, so status updates stop competing with code changes for the same file.

None of this claims that perfect partitioning is achievable for every real task. Some tasks genuinely share an interface, and no ownership map can cut that dependency away unless you change the architecture itself. The answer in that case is to partition as tightly as the task structure allows, assign a single owner to whatever file the two tasks must share, and accept that the shared portion gets sequenced rather than forced into parallel execution it cannot actually support. Even a well-built partition only prevents the conflicts it can see coming. Scope creep and hotspot drift happen inside tasks that looked cleanly scoped at the start, which is exactly the gap the next layer of defense is built to close.

Early clash detection during parallel work, before the merge queue

Partitioning sets the boundaries before work starts, and detection watches whether those boundaries hold while the work is underway. If you run a lightweight check on active branches while agents are still working, rather than only once they reach the merge queue, you catch drift early enough to fix cheaply. An agent's diff can be checked against its assigned scope at intervals, flagging edits that fall outside the task's declared file set. A test fix that quietly touches a shared helper function appears as an anomaly in the diff long before it becomes a conflict at merge time, and long before it becomes a bug in production.

Verification gates provide a second, more structural form of early detection. Before an agent starts, the worktree gets created and the lint and test suite runs immediately, confirming the baseline is green before the agent touches anything. After the agent finishes, the same suite runs again. Any new failure at that point belongs to the agent's changes, not to some pre-existing issue in the codebase, because the first run already ruled that out. This bracketing turns "something broke" into "the agent broke this specific thing," which is a much faster problem to diagnose.

A third check matters specifically because agent worktrees tend to live for a while before merging: running git merge-base develop <branch> reveals how far a branch's starting point has drifted from the current state of the integration branch. A worktree that started from a base several days or several merges behind the current branch is a conflict multiplier waiting to happen, and this check surfaces that cheaply, before the merge itself turns it into a multi-file conflict that's much harder to untangle after the fact.

Augment Code's Intent orchestrator builds this pattern into the workflow itself as part of the system, not a manual check. A Verifier component checks each agent's output against a living specification, and a Coordinator component manages the order in which branches merge based on that validation. The effect is to move early validation into the orchestration layer as a built-in step.

Text-level resolution at merge time: mechanical strategies for the conflicts that survive

Even when partitioning and detection run throughout, some conflicts still reach the merge. Not all of them need a person to resolve them by hand. Certain file types have known, automatable resolution strategies, and using them removes an entire category of repetitive manual work before a human ever has to look at a diff.

Lock files are the clearest case. An npm merge driver configured in .gitattributes auto-resolves package-lock.json conflicts without intervention, because the resolution logic for that file format is well understood and doesn't need judgment about intent. Where that isn't set up, the simpler fix is coordinating agents so that only one branch installs new dependencies during a given work cycle, which keeps the lock file from diverging across branches from the start.

Order matters as much as tooling for the conflicts that remain. Merging branches in the order that minimizes conflicts, usually starting with the most foundational changes, means every later branch integrates against a base that already reflects the prior merges, rather than against a snapshot that's about to change underneath it. Merging several agent branches at once compounds this problem, because a conflict that appears after a batch merge could trace back to any of the branches in that batch, and finding the actual source takes far longer than it would if each branch had merged one at a time. The discipline that works is sequential: finish reviewing one branch, merge it, update the next worktree so it reflects the merged state, then move to the next review.

For the conflicts that still need a generated resolution rather than a fixed rule, two different technical approaches handle different situations. An empirical comparison of LLM-based and search-based conflict resolution, published in 2026, found that LLM-based resolution does well on conflicts with imbalanced content, drawing on learned patterns to fill in the smaller side of an uneven conflict, but struggles with non-English content and large inputs, sometimes producing resolutions that are truncated or empty. Search-based resolution generalizes better across different datasets, and it does best on balanced conflicts, where both sides of the conflict carry roughly equal weight. Neither approach covers every case the other one does, which is the whole reason a merge strategy needs more than one tool in it.

One tool narrows that gap specifically. Rover, described in a paper posted to arXiv, combines LLM-generated resolutions with program analysis, addressing a specific weakness in standalone LLMs: their tendency to miss semantic dependencies on variables, functions, or composite types defined elsewhere in the project, dependencies that are often essential to resolving a conflict correctly. Measured against a standalone LLM, Rover performs better at the character level, the lexical level, and the semantic level. Even a tool built specifically to close that gap only closes it at the text level. What a merged file means at runtime is a separate question, and it's the one the next layer has to answer.

Semantic conflicts: the category that survives a clean textual merge

A clean git merge just means the text came together with no conflict markers. It does not mean the resulting program behaves correctly. Semantic conflicts, cases where merged code produces incorrect behavior at runtime despite a textually clean merge, sit above both the textual and build layers, and they are essentially unmeasured by standard tooling. Every textual conflict count is a conservative floor on the real amount of integration friction in a parallel-agent workflow, not a ceiling.

Context contamination is the clearest mechanism behind this. One agent finishes a refactor of a shared service. A second agent, working in parallel on a consumer of that same service, has no way of knowing the interface underneath it changed, because the two agents never shared context during the work itself. Both produce code that looks correct in isolation. The failure only appears once their changes combine, and by that point it has nothing to do with either agent's individual diff.

Two recent research efforts put a number on how much mechanical isolation can actually buy against this problem, and the number has a ceiling. STORM, described in a paper posted to arXiv in 2026, mediates each agent's interaction with the shared workspace at write time, instead of letting agents work in isolation and reconciling their changes afterward, so every agent is always working from a consistent, current view of the codebase. On the Commit0-Lite benchmark, STORM reaches a substantially higher weighted pass rate than a standard git worktree baseline, which suggests that detecting conflicts earlier, at the point of writing rather than the point of merging, lowers the cost of recovering from them on repositories where components are tightly coupled.

CodeCRDT, described in a paper posted to arXiv, takes the isolation approach to its logical limit: it guarantees textual convergence with zero merge failures, using the same strong eventual consistency guarantees that distributed systems use to keep replicated data in sync. Even under that guarantee, preliminary results show that roughly five to ten percent of cases still carry a semantic conflict after a textually perfect merge. That number is the clearest evidence available that textual safety and semantic safety are different properties, achieved through different mechanisms, and that solving one does not solve the other.

The practical conclusion follows directly from that gap. Every layer covered here, partitioning tasks before agents start, detecting drift while they work, resolving text-level conflicts mechanically where possible, reduces how much semantic risk reaches production, but none of them, alone or combined, removes it. Scoping tasks narrowly enough that diffs stay small keeps semantic review meaningful rather than nominal: nobody can meaningfully review a five-hundred-line diff for hidden contradictions, but a fifty-line diff is reviewable, by a human or by an agent assigned to that purpose. Running CI against every merge, with no exceptions for merges that completed cleanly, is what keeps the semantic layer examined. A clean merge is necessary. It was never going to be enough on its own, and treating it as the finish line is how semantic conflicts end up getting discovered in production.