Lock, Lease, or Fence: Which Stops a Zombie Write?
A lock, a lease, and a fencing token answer three different questions. The write your version check passes is the one the fence refuses.
Read the post →Blog
Engineering notes on shared state in multi-agent systems — stale reads, lost updates, and what it takes to make agent memory safe to write to.
A lock, a lease, and a fencing token answer three different questions. The write your version check passes is the one the fence refuses.
Read the post →When an update vanishes the reflex is a store migration. The store was never the problem. The fix is the version on the write, over the store you already run.
The failures arrive in a fixed order as an agent workspace grows: stale reads, then lost updates, then zombie writes. Find your rung and see the next one coming.
BYO-substrate bindings are live in v0.13.0. CoherentRow guards a Postgres row, CoherentObject guards an S3 object, and the coordinator holds a version, MESI state, and a content hash, never your bytes. A peer's commit marks your cached read stale before you act on it, on a single host, with the same typed conflict and the same reacquire() recovery on every substrate.
The coordination lever is live. Version-CAS, a read-generation fence, and MESI invalidation-deny stop the concurrent lost-update and the sequential stale-read-then-write on a single host, with five TLA+ invariants checking they hold.
The vanished write is not one bug. It is a class with five members, and prevention is not one lever. A durability receipt, a retention policy, and a coordination primitive split the five between them, and only the last one is the runtime's to ship.
Thirty agent-memory products describe how agents remember. Not one describes what happens when two writers hit the same key. The lost update is the half that breaks production.