Parallel Agents and Merge Conflicts in Cursor

A merge conflict happens when two changes touch the same lines and git cannot decide which to keep. With one person working, that is rare, because you tend to finish one thing before starting the next. Run three agents on one repo and the odds change fast: they work at the same time, and they often reach for the same files, the shared types, the config, the one util everything imports.

The conflict is not the real cost. The real cost is that you are now resolving a clash between two diffs you didn't write, which means reading both well enough to know what each agent was trying to do.

Frequency matters less than shape here. The version that costs a day is a pair of changes that never touched the same line: two agents each add the next numbered migration, both files land, and the order they run in now depends on who merged first. Git has nothing to say about that, and neither does the conflict view, because there is no conflict to show.

Cost this in hours rather than in counts and the picture shifts. A textual conflict in a file you own takes minutes. A clash between two agent diffs you have both stopped holding in your head takes as long as re-reading them, and that is usually where the time parallelism saved goes back.

Isolation first. A git worktree is a separate working copy of the same repo, so two agents can work in parallel without sharing a checkout. It is more separation than a branch alone gives you, and it is the single most useful habit for running agents side by side.

A worktree buys less than the word isolation suggests, and it is worth being precise about which part. Two agents stop writing into the same checkout, so nothing gets clobbered mid-flight and neither one waits on the other. The number of clashes does not drop. They move to the merge, where at least you are looking at two finished changes instead of two half-written ones.

Which is why the scoping step sits before the isolation step in that flow. Give two agents separate worktrees on the same area of the code and you have bought quiet working conditions and a harder merge. Give them separate areas and there is often nothing to resolve.

• Scope agents to different parts of the codebase when you can, so they rarely reach for the same files.
• Keep each agent's task small. Small changes conflict less and review faster.
• Pull main and rebase often, so a change doesn't drift far from what it branched off.

For a two-person team, running one agent at a time and skipping the problem is often faster once you count the merge.

Parallelism pays where the boundaries are already drawn, which in a larger codebase tends to mean per service or per package, and those boundaries are probably written down as code ownership already.

This is the part to hold loosely. Coverage of the Compile demo described Origin resolving merge conflicts automatically by reading each agent's intent, plus handling failed CI runs on its own. If that ships as described, it would attack the exact cost above: the time you spend untangling two diffs you didn't write.

Even taken at face value, automatic resolution does not remove your job at the merge. A conflict resolved the wrong way is a bug that compiles. The point of automation here is to clear the easy clashes so a person spends attention on the ones that actually need judgment.

If intent-aware resolution does ship, the question worth putting to it is what it reads intent from. A resolver has the two diffs, the commit messages, and whatever task description produced each change. That is a fair amount of signal on a team that writes real task descriptions and almost none on a team whose prompts are one line long. My guess is that it pays off most for teams already writing down what they asked for, and those teams hit fewer bad merges to begin with.

Whenever the two changes disagree about behaviour, not just lines. If one agent changed how a function returns and another changed who calls it, no resolver can guess which version you meant. Read both, decide, and write the merge yourself.

The rebase-often rule from the list above needs adjusting for agents. For a person that habit is cheap, since you hold the context and a rebase costs a minute of re-reading. A rebase while an agent is mid-task changes the files underneath it, and you can end up reviewing a change written against code that is no longer there. Rebase between tasks rather than during one.

When a resolution goes wrong, check the base before the diff. Running git merge-base on the two branches tells you whether the agents were working from the same main, and a fair share of merges that look like logic problems are two changes built an hour apart on different bases. If the base is shared and the tests still fail after your resolution, you are probably looking at a behaviour disagreement, and the rule below applies.