Avoiding merge conflicts when several AI agents work in parallel

Split by area, not by size

Two small tasks in the same file will conflict; two large tasks in different packages will not. Before handing out work, sort it by which files it will touch. Tasks that must touch shared files — a router, a schema, a lockfile — go to one agent, or run one after the other.

Know the usual hot spots

• Lockfiles (package-lock.json, pnpm-lock.yaml, Cargo.lock). Tell agents not to add dependencies, or regenerate the lockfile once after merging.
• Registries — route tables, dependency-injection setup, barrel index files that every feature appends to.
• Migrations with sequential numbers. Two agents both create migration 042.
• Formatting. One agent reformats a file the other edited. Run the formatter in every worktree before merging, with the same config.

Merge in a fixed order and rebase the rest

Merge the smallest or most foundational branch first. Then rebase each remaining branch on the new main before merging it — git rebase main inside that worktree — and rerun its tests. A conflict found during that rebase is one branch against a known main, which is far easier than untangling three at once.

If a rebase conflict is large, it is often cheaper to discard the branch and give the agent the same task again on top of the new main. Agent time is cheap; your time resolving a confusing conflict is not.

Keep tasks short-lived

The longer a branch lives, the further main moves underneath it. Tasks that finish in minutes rarely conflict; tasks that run all afternoon usually do. Break big changes into a sequence rather than running them all at once.