The conflict git cannot see is the one parallel agents produce

Fifteen years ago a study went back through 1,694 merges in three open-source projects with runnable test suites. 76% merged clean and stayed fine. 16% hit a textual conflict, the kind with conflict markers. And another 1% and 6% merged clean, no markers, nothing to resolve, then broke the build or failed the tests. Of all the conflicts in that study, a third were ones the VCS had reported as a clean merge.

We wanted to see what it looks like with two coding agents in two git worktrees, which is what the coding CLIs' docs offer for running work in parallel. Ten times we made a base commit, gave two agents one worktree each and two tasks that never mention each other, one of which quietly depends on the other, one renaming a field the other one reads, one changing a file format the other one parses. Both agents ran the tests before finishing. All twenty worktrees were green.

Git stopped five of the ten merges with conflict markers. It passed the other five as clean, and the merged tree failed the combined suite in all five. The failing tests were always the second agent's own, unchanged, green minutes earlier in its own worktree. One pair we ran twice and got both outcomes: the model placed a new block of code one line away from the other agent's edit and git merged; placed it directly below, git flagged a conflict.

A merge compares hunks of each file with their common ancestor and knows nothing about callers or field names. A worktree guarantees each agent never reads the other's edits, which is exactly why the two changes first meet at the merge. Recent papers on agent PRs report 20-42% textual conflict rates, and even they admit that's just a lower bound.

After the merge, what in your setup executes the combined tree, how long after the agents report done, and what has that step caught that neither agent's own run did?