Why do parallel writer agents clobber each other?

Because they share one working tree. When several agents each read the same file and write their own version back, only the last write survives and the rest are silently lost. Anthropic's swarm study is the extreme version: agents on shared infrastructure sabotage each other and hide it. The fix is to remove the shared state, not to add more coordination on top of it.

How does worktree isolation fix it?

Each writer gets its own git worktree and its own branch off the base. Two writers physically cannot touch the same working copy, so there is nothing to clobber during the write phase. All contention is deferred to one deterministic merge step at the end, which is the single point where the edits meet.

What resolves the conflicts at merge time?

For additive edits, a git merge=union driver set in .gitattributes unions the overlapping hunks so both sides' additions survive, then the repo's own tests verify the merged result. For edits that genuinely contradict, the same step hands the conflict to one arbitration agent rather than letting two writers fight over the lines. Either way the merge is a single governed point, never a free-for-all.

Parallel write-merge — Workloft Ships

Two days ago we shipped the easy half of swarm-safe fan-out: read-only agents that review in parallel and never touch anything. We said the hard half, the one that matters, was agents that actually write to the same code, and that it needed per-agent isolation and a merge step rather than a report. This is that build. The result is blunt: a naive shared working tree loses two of every three parallel edits and the tests fail, while giving each writer its own git worktree and merging at the end lands all three with the tests passing. We proved it twice, once deterministically and once with five real agents.

What we did

The failure we are fixing is a lost update. Point three agents at the same file, let each read it and write its own version back, and only the last writer survives; the other two edits vanish with nothing to show for it. That is the everyday version of what Anthropic's swarm study showed at full volume, agents on shared infrastructure quietly undoing each other's work.

So we remove the shared state instead of policing it. Every writer gets its own git worktree on its own branch off the base, which means two agents cannot physically touch the same working copy while they work. All the contention is deferred to one place: a single deterministic merge step that integrates each branch in turn. For additive edits a merge=union driver, set once in .gitattributes, unions the overlapping hunks so both sides' additions survive; for edits that truly contradict, that same step hands the conflict to one arbitration agent rather than leaving two writers to fight over the lines. Then the repo's own tests run on the merged result, and the workflow reports edits landed against edits expected. If verify fails it says so; it never reports a clean merge it cannot stand behind.

We built it as a reusable Workflow: a coordinator sets up the worktrees, one isolated agent per disjoint task writes and commits to its own branch, and a final agent merges and verifies. It is the write-half companion to the coordinated fan-out we shipped on Friday.

Why it was worth doing

Because the numbers are unambiguous. We set up three tasks that each insert a new operation at the same anchor line of one registry, so the edits genuinely overlap. Run naively in a shared tree, one of three edits survives and the test suite fails. Run with a worktree per writer and a merge step, all three land, the union-merge output is clean rather than garbled, and the tests pass. One survivor versus three, failing versus passing, from the same three edits. Then we ran the reusable Workflow for real: five Claude agents, three writers each committing to their own branch, two overlapping hunks auto-resolved at merge, and the verification passing on disk with all five operations present. Same result live as on the bench.

It also closes the loop on the swarm paper in a way a review panel could not. The read-only half raised the floor on how we check work. This half is the part the study was actually about, many agents changing the same thing at once, and it turns that from a hazard into a routine fan-out you can point at a real repository.

What's still off

The union driver is the right tool for additive edits, new lines that sit beside each other, and that is a large share of real fan-out work such as adding cases, handlers or entries. It is the wrong tool for edits that contradict, two agents rewriting the same function different ways. There the workflow falls back to an arbitration agent, and an agent resolving a merge is a model judging other models, with the same shared-blind-spot caveat we flagged on the review half. The verify step is the backstop: a merge that breaks the tests does not get to claim success, whoever or whatever resolved it.

And worktrees are not free. Each one is a checkout on disk, so this pays for itself when writers do real, separable work, not when three agents each change one line. The honest scope is parallel writes that are mostly independent with occasional overlap. For that, which is most fleet work, it turns a lost-update coin toss into every edit landing.