Git worktrees aren't enough for parallel AI agents

Worktrees isolate each AI agent's working directory, but two agents in separate worktrees can still write code that only collides when both PRs merge to main.
If you run several AI coding agents at once, you have probably reached for git worktrees. It is the standard answer, and it is a good one: give each agent its own worktree, and no agent overwrites another agent's files mid-run. Each agent gets a clean, isolated checkout on its own branch, off the same shared repo.
Use worktrees. They solve a real problem. But they solve the execution problem, not the merge problem — and for parallel agents, the merge problem is the one that bites.
What worktrees actually isolate
A worktree gives each agent a separate working directory. Agent A editing files in its worktree cannot clobber the files Agent B is editing in a different one. No half-written file from one run leaks into another. No branch-switch thrash. The agents stop stepping on each other's filesystem.
That is genuinely valuable, and if you were previously running multiple agents against a single checkout, worktrees will feel like a night-and-day upgrade.
What worktrees don't isolate
Here is the gap. Two agents in two isolated worktrees can still change related code — code that reads clean in each branch on its own, and only clashes when both branches land on main.
The isolation is spatial: separate directories. It is not semantic. Nothing about a worktree knows that Agent A's change to a shared helper and Agent B's new caller of that helper assume different things about how it behaves. Each PR compiles. Each PR passes its own tests. Each PR looks correct in review. The problem lives in the relationship between the two open PRs, and no single worktree can see the other one.
This is not a rare edge case. AgenticFlict, a large-scale study of merge conflicts in AI coding agent pull requests (arXiv, 142k+ agent PRs across 59k+ repositories), found a 27.67% merge-conflict rate — and textual git conflicts are only the visible slice. The quieter failures are the ones where git merges cleanly and the breakage shows up later, on main, after both PRs are already in.
Why nobody catches it
Walk the tools you already have and notice what each one looks at:
Git compares text at merge time. If the two changes touch different lines,
it reports no conflict — even when the logic collides.
CI runs on one PR's branch. It exercises the interactions your tests cover,
in isolation from the other open PR.
Code review looks at one PR at a time. A reviewer approving PR #12 is not
also holding PR #47 in their head.
Merge queues serialize ready PRs and rebuild them in order — useful, but
they engage at the end, once a PR is already ready to land.
Every one of these is doing its job correctly. The common blind spot is the same one worktrees have: they each see a single PR. Nobody is watching the cross-PR relationship while the PRs are still open — which is exactly when a heads-up would let you order the merges, or ask one agent to rebase on the other, before anything breaks.
The layer worktrees are missing
Worktrees isolate agents so they can run in parallel. The missing piece is something that watches the open PRs so they can merge in parallel — a layer that looks across branches instead of within one.
That is the gap Veripsa Core fills. It is a GitHub-native, advisory check that looks at your open pull requests and warns which ones may overlap before they reach main. It posts the signal on the PR, where authors and reviewers already are. It stays advisory — it does not hard-block your merge; a human can review the situation and proceed. And it is content-free: it never stores your source file bodies. It works within a single repository today.
It is not a merge queue, not an AI reviewer, and not CI. It is the cross-PR heads-up those tools were never built to give.
The short version
Worktrees are the right first move for parallel AI agents — set them up. Just know what they cover: they keep agents from overwriting each other while they run. They do not keep two independent branches from colliding when they merge. For that, you need something looking at the relationship between open PRs, not at each one alone.
See how the advisory check reads on a real PR in the sandbox at /try, compare it against merge queues and AI reviewers on /compare, or read the product contract in /docs.