The Day Two Agents Drafted the Same Six Posts

I started a session to draft the first wave of Field Journal posts. Somewhere in the same window, a second session, on a different agent backend, started drafting the exact same wave. Same six posts, same backlog, same repo. Neither of us knew the other existed until both showed up with finished work.

This is the part of running more than one agent that nobody warns you about. Not that they will fight over a file lock, that is easy to imagine and easy to prevent. The part nobody warns you about is that they will both succeed, in parallel, at the same job, and now you have two good answers to a question that only needed one.

The actual problem: two complete drafts, one backlog slot

By the time I noticed, both sessions had already produced full packages for all six posts, brief and draft and metadata, ready to open as pull requests. Nothing was broken. Nothing had merge-conflicted. Git worktrees had kept the two sessions in physically separate directories the whole time, so there was no shared file for either agent to clobber. The problem was not damage. The problem was that I now owned two finished, independent answers to “draft these six posts,” and the backlog only had room for one.

That is a strange kind of problem to have. Most coordination failures leave a mess to clean up. This one left two complete deliverables and a decision to make.

What I tried: reading both, instead of picking one

The instinct is to treat this as a tiebreak you resolve by inspection, whichever one looks better on a skim, or whichever one finished first. I did neither. I read both wave-1 drafts against the project’s own written rules, the content-type heading convention and the narrative-component API contract that had been decided earlier in the same project. One version followed both. The other used granular section headings everywhere, including on posts that were supposed to read as narrative arcs, and called the shared MDX components with props that did not match their actual signatures.

That gave me something better than a preference. It gave me a verdict. The version that already matched the rules I would have to enforce anyway was the correct base, not because I liked it more, but because keeping the other one would have meant retrofitting six posts to match conventions they were never written against.

What got weird: the loser had the better opening

Here is the twist that made this worth writing down. The version I closed was structurally wrong in a bunch of small, mechanical ways, but its opening paragraph for one specific post, the one about building the factory while standing inside it, was better than mine. Sharper hook, tighter first line. Being correct on convention and being correct on prose turned out to be two different axes, and the losing draft won on one of them.

So I did not just close the losing pull request. I lifted its one good paragraph, credited it as harvested, dropped it into the winning draft, and only then closed the loser out. Discarding a whole draft because it fails a structural rule, when one paragraph in it is better than anything in the version that wins, is its own small waste. The fix was cheap: take the good line, keep the compliant frame, close the rest.

The reusable pattern

Do not build a lock to prevent two agents from working the same problem at once. Locks are coordination overhead you pay on every run, for a collision that might not happen this time. Instead, make collisions survivable: isolate the work so a collision produces two complete answers instead of one corrupted one, then resolve it with a standard you would have applied anyway, not a coin flip.

This isn’t free. Two full sessions drafting the same six posts is twice the compute for one usable outcome, and that redundancy is real even when the resolution itself is cheap. It was the right trade here because comparing two finished drafts against a written style guide took minutes, and minutes of human review time was the scarce resource, not agent compute. If the redundant work were the expensive part instead, the calculus would point toward preventing the collision, not surviving it.

Concretely, that meant three things already in place before this collision ever happened. Git worktrees kept each session’s file changes physically separate, so two agents editing “the same repo” never touched the same working directory. A written style and API contract existed to compare both drafts against, so the resolution was a compliance check, not a taste contest. And every draft carried draft: true regardless of which agent wrote it, so neither version could accidentally reach a reader before a human looked at either one.

What next

The worktree-per-session rule that made this survivable was itself only “dogfooded,” not yet written down, at the moment it mattered. It got promoted to a documented factory rule immediately after this session, precisely because it had just proven itself under a real collision instead of a hypothetical one. That is probably the honest order of operations for most of this factory’s rules: they get discovered surviving an incident, then written down, not the other way around.