Merge conflicts with parallel AI agents: partition first

Three agents finish within ten minutes of each other. Great morning.

Then you start merging, and the rest of the day disappears. Branch one and branch two rewrote the same route file. Branch three was working from a main that moved twice while it ran. And the merged tree fails a test that was green on every branch separately.

Writing code stopped being the bottleneck the moment you ran more than one agent. Integration became the bottleneck instead, and almost nobody plans for that.

Why agents collide more than teammates do

Human teammates conflict too, but slowly and out loud. Agents don't, for three reasons:

• They never look up. An agent works from the snapshot it read at minute one. A human notices main moved; an agent finds out at merge time, if at all.
• They tidy on the way past. Asked to fix a checkout bug, an agent will happily clean up a shared helper in a file nobody assigned it.
• They work in bulk. Three agents for forty minutes is easily sixty changed files, with no standup in the middle.

So this is not really a git problem. It is an assignment problem, and it gets solved before the agents start, not after they finish.

Partition by the files, not the feature

The highest-leverage habit in the whole workflow: when you split work across parallel agents, split by the files each task touches, not the feature it delivers.

"Add webhook handling" and "add invoice PDFs" sound independent. They both edit the billing service, the routes file, and the same migrations folder. Feature names hide overlap; file paths expose it.

Put it in the brief: name the directories this agent owns, then add the escape hatch, "if you need to change something outside them, stop and tell me instead of doing it". That line turns a silent conflict into a ten-second question. It is task sizing on a second axis: not just how big, but where.

Every repo has landmine files

A handful of files get touched by nearly every task:

• route tables and service registration
• migration folders with timestamped filenames
• barrel files and index exports
• lockfiles
• translation catalogs

Name yours once, then serialize anything that touches them: a card needing a lockfile bump or a new migration runs alone, or runs first and the others rebase onto it.

Migrations especially, because two agents adding one in parallel produce no git conflict at all. Different filenames, clean merge, and now they run in an order nobody has tested.

The conflicts git can't see

A merge conflict is the good outcome. Git stops. You look.

The expensive ones merge perfectly:

• Agent A renames formatPrice to formatMoney and updates every call site it knows about. Agent B, still on the old base, adds three fresh calls to formatPrice. Both branches pass. The merged tree breaks.
• Both agents add the same helper, under different names, in different files. Nothing fails; you just own two of everything now.
• Agent A tightens a validation rule. Agent B builds a feature that quietly depended on the loose one. Green, green, red only in combination.

The defence is boring and non-negotiable: run the full suite on the merged tree, not only on each branch before it lands. Per-branch green says nothing about the combination, and it is exactly the run you will be tempted to skip at 6pm.

Let the agent resolve conflicts, under rules

Agents are genuinely good at this: they read both sides, work out what each was trying to do, and write a resolution that preserves both. Often better than a tired human.

They are also entirely capable of resolving a conflict by deleting the other side's work, because that does make the error go away.

Three rules keep it honest:

1. No blind --ours or --theirs. Require the agent to state, per conflict, what each side was doing and why its resolution keeps both.
2. Tests re-run after resolving, before it reports done.
3. Review the resolution as its own diff, not folded into the feature review. It is the change most likely to lose work and least likely to get read.

Then keep branches short. A branch that lives a full day collects conflicts against everything that shipped that day, which is also why small, frequent commits make merging cheaper.

Merge order is a decision too: the branch touching shared code lands first, and the rest rebase onto it and re-run before review, against the tree they will actually land in.

See the overlap before you deploy the work

All of this depends on knowing what your agents are about to touch, while you can still change it.

That is what SanuDesk is built around. Cards on the Kanban board carry the scope in writing, so two tasks aimed at the same directory read as a conflict before either is deployed. Sessions for Claude Code, Codex and Gemini tile into one grid, so "who is in the billing service right now" is something you look at, not remember. A workspace is just a folder, so a worktree per agent becomes a workspace per agent. Finished work lands in In Review with a what changed and how to test note, so merge decisions queue in one lane. The post-merge suite run is the kind of recurring job a Loop handles on a schedule.

It drives the agent accounts you already pay for, and the grid and board are on the free plan.

The short version

Split work by file paths, not feature names. Serialize the landmine files. Run the full suite on the merged tree, because the worst conflicts never announce themselves. Let agents resolve conflicts, but review the resolution on its own.

Download SanuDesk free and give every agent its own workspace, or see how the grid, the board and Loops fit together on the features page.