The factory keeps append-only logs of agent activity: run entries, change entries, each with a tidy sequential id. RUN-0022 follows RUN-0021. It is readable, sortable, and obviously correct right up until the day the factory’s own operating model made it wrong: two agent sessions, closing out in parallel, each read the log, each saw the same last id, and each, correctly following the scheme, wrote RUN-0023.
Neither session misbehaved. That is the point worth sitting with. A next-number scheme is an instruction to read shared state and increment it, and two readers with no lock between them will do exactly what these two did. The collision was resolved by hand in the merge (one session’s entries renumbered to RUN-0024), the logs were reconciled, and the factory moved on. Then, days later, it happened again: RUN-0026 and a change-log id, each independently assigned twice by parallel closeouts, resolved by hand again. A design that generates the same conflict twice in one week is not unlucky; it is working as built.
The control group next door
What makes this a pattern story rather than a war story is the ledger sitting in the same factory that has never had this problem. The Blog Radar ledger is written to by every project’s closeout, routinely concurrently, and its ids are deterministic content hashes: a short digest of date, project, session, and content. The same event always derives the same id; two different events cannot collide by both counting to the same number, because nothing counts. When the sequential logs collided, the ledger crossed the same week of parallel closeouts untouched.
The difference is not care or luck; it is what the id depends on. A sequential id encodes a fact about the log (“I am the twenty-third entry”), which is shared mutable state, contested by every writer. A content-derived id encodes facts about the entry itself, which no other writer can contest. Under a single writer the two schemes behave identically, and the sequential one reads better. The moment writers multiply, and agents multiply writers faster than teams ever did, position becomes the one thing nobody can safely know at write time.
The part worth stealing
Inventory every log, ledger, or registry in your system that more than one process appends to, and ask what its ids depend on. Anything that depends on reading the current end of the log is a merge conflict on a timer. The fix is usually one line at the point of id generation, and it is dramatically cheaper before the first collision than during the second.
What Next
A BLOCKED Banner as an API Between Two Labs
Also in Agentic SDLC Patterns: the other shape of cross-agent coordination, a stop-condition contract written where the next stateless worker will actually read it.