Conflict-safe publishing for agent fleets

Run enough agents against shared storage and the failure arrives on schedule: two of them write the same path, the last writer wins, and the first agent's work vanishes without an error, a log line, or a trace. Conflict-safe publishing eliminates the failure class — each writer declares which base revision it started from, and its publish succeeds only if that base is still current. Losers get an explicit conflict; nobody's work is destroyed.

Why do agent fleets lose work on shared storage?

Because every mainstream option resolves concurrent writes by discarding one of them silently. S3 and bucket mounts are last-writer-wins per object; NFS-style filesystems interleave writes with no notion of "this file changed since you read it"; sandbox snapshots preserve whichever sandbox saved last. Human teams route around this with convention — "don't both edit the config" — but fleets of parallel agents are precisely the workload conventions can't reach. The storage itself has to refuse to lose work.

How does compare-and-swap publishing work?

Each agent works in an isolated session forked from a published revision — its base. Publishing says: advance the workspace head to my result, if and only if the head still equals my base. The check-and-advance is atomic. If a peer published first, the head moved, and the stale publish fails with an explicit conflict — the same optimistic-concurrency primitive databases have trusted for decades, applied to a whole filesystem tree.

The critical property is what happens to the loser: nothing. Its session is preserved exactly as written, ready to be inspected, rebased onto the new head, or retried. An orchestrator can handle REVISION_CONFLICT as a normal, expected signal — fetch, rebase, republish — because losing a race no longer means losing work.

What does provenance add?

Every published commit records the actor, session, and run that produced it, from which base, at what time. For a fleet this is the difference between auditing and archaeology: "which agent changed this file, what did the tree look like before, and what else did that run touch?" are history lookups, not grep sessions over application logs. It also makes automated review possible — gate publishes from certain agents, diff any two revisions, restore the workspace to the moment before things went wrong.

Doesn't isolation slow the fleet down?

Only if isolation is expensive, and that's a storage-architecture choice. Amulet forks a session in about 3 ms copying zero bytes, and sessions mount in under 100 ms regardless of workspace size — so per-agent isolation costs effectively nothing at any fleet size. A hundred agents means a hundred isolated sessions over shared blocks, not a hundred copies of the data. Compare that with cache-layer mounts or platform volumes, where writers share one live tree and the concurrency answer is "don't."

What should an orchestrator do on conflict?

Treat it as flow control, in one of three honest ways: rebase the session onto the new head and republish (the common case when agents touch disjoint files); discard and retry from fresh state (cheap, since forks are free); or escalate to review when the same paths genuinely collide. What it never has to do is reconstruct destroyed work — the failure mode conflict-safe publishing exists to delete.