The Reviewer Was Certain the Files Didn't Exist
They did. The checkout it was standing on had already moved to a different branch. A shared working tree doesn't fail loud, it fails as a confident, wrong report.
The review agent came back certain. Three files it had been told to check did not exist. Not "couldn't open." Not "missing content." Absent, stated as flat fact, the kind of thing you'd say about a chapter that had never been written.
I had watched myself add two of those files less than an hour before.
I opened the directory by hand. There they were, current, nothing wrong with any of them. I ran the identical inspection again a minute later and it came back clean: same files, same instructions, the opposite verdict from the one I'd just read.
The files were exactly where I'd left them. What had moved was the ground the reviewer was reading them from.
Two runs were sharing one checkout when it happened, and somewhere between the reviewer's first pass and its second, the branch under its feet got swapped out by the other run. The reviewer wasn't lying and it wasn't broken. It read the directory exactly as instructed, at exactly the moment it was told to, and the directory it read had already become a different codebase than the one the review was supposed to be about.
That was the cheap version. I've watched worse, more than once.
A branch came back from review carrying a change nobody on that task had written. Somebody flagged an unfamiliar parameter in a file the task never touched, and the honest answer was that a second, concurrent run had staged its own edits into the same tree at the same moment, and both sets of changes went into whichever commit happened to fire first. Untangling it meant reading every commit on the branch by hand and replaying only the ones that actually belonged there, because nothing in the branch itself said which lines were whose.
Another time it was smaller and meaner. Real, uncommitted work from one task, still sitting in the tree, got swept into a commit a different task made when it staged everything in sight. The work surfaced anyway, just under the wrong branch, with the wrong message, in front of the wrong reviewer. Nobody notices until somebody asks why a bugfix commit contains half a feature.
And more than once, a dispatch that should have started clean got hard-stopped by the guard that refuses to begin against a dirty tree. The tree really was dirty, just not because of anything the stopped run had done. A different run's legitimate in-progress state happened to be sitting there when the guard looked, and the guard did its job perfectly on evidence that had nothing to do with the run it was judging.
None of that ever announced itself as a conflict, and that's the part that actually costs you.
A merge conflict tells you what it is on sight. Two runs sharing a working tree don't produce that kind of error. They produce a correct-sounding report about the wrong state of the world, and an agent handed a correct-sounding report has no reason to doubt it. It reasons forward from bad footing with complete confidence, and everything downstream inherits that confidence along with the mistake underneath it. You don't debug the collision. You debug the story the collision told somebody first, and that story arrives dressed up as an ordinary finding, which is exactly what makes it expensive. I chased the reviewer's phantom files longer than it would have taken to just rewrite the review from scratch, because I trusted the report before I thought to distrust the ground it was standing on.
I read every clean-tree failure with a little more suspicion now, the same way you double-check a smoke alarm that's gone off once before for nothing worse than burnt toast.
The fix isn't cleverer conflict detection. It's not sharing the floor to begin with.
Every real dispatch now gets its own private, throwaway checkout instead of touching whatever working copy you happen to have open. Its branch starts from the base the backlog actually declared, not from whatever was checked out when somebody hit enter, so where a run begins is a property of the backlog instead of an accident of your terminal. Call each of those a lane: one backlog, one run, one checkout, and because the checkout belongs to it alone, several lanes can be in flight at once without any of them standing on what another one is standing on. There's still a way to force the old shared-tree behavior, which turns out to be exactly what you want when you're debugging the dispatch mechanism itself rather than the work it dispatches.
I want to be careful not to oversell what that buys you, because this audience checks.
It covers the checkout the orchestrator itself works in. Aim two separate lanes at the same downstream repository and they still meet each other at that repository's own working tree, exactly as before, because isolating the dispatcher doesn't isolate every target it dispatches into. Inside one run, if two tasks in the same parallel batch both target a repo that isn't isolated, that's still refused before either one starts, on purpose, because two agents committing into one working tree at once was never going to be safe no matter how good the reporting gets. And a run's own bookkeeping can still hit a real conflict of its own, when two lanes append to the same shared notes file at once. That one is expected, and it resolves by keeping both entries, the ordinary result of two lanes writing into the same margin at once.
What changed is narrower than "parallel agents are safe now." The checkout the orchestrator works in stopped being shared ground, and nothing beyond that changed. Every other way two things can collide, still can.
I don't ask a reviewer whether it's sure anymore. I ask it where it was standing.