Checkpoint-Resume
Long-running work is segmented at durable checkpoints: after each segment the agent writes state (what is done, what is next, open questions) to a file, so any session can resume without re-deriving context.
When to use
Tasks that outlive a context window or a session: large refactors, multi-day builds, content pipelines.
Steps
| Step | What happens | Verification |
|---|---|---|
| Load checkpoint | Read the state file; reconcile it against the actual workspace before trusting it. | Stated 'done' items spot-checked against reality; drift flagged, not assumed away. |
| Work one segment | Advance the smallest coherent unit of work. | Segment's own success criterion, as in plan-execute-verify. |
| Write checkpoint | Persist done/next/open-questions with timestamps before the session can be lost. | Checkpoint sufficient for a cold-start resume: tested by writing it for a reader with zero context. |
Specification
| Verification method | Reconciliation on load: the checkpoint is a claim to verify, not a fact to trust. |
|---|---|
| Recovery behavior | backtrack-to-last-verified-checkpoint |
| Observability | The state file itself, plus per-segment evidence. |
| Inputs | State file location, Segment size policy |
| Outputs | Progressed work, Always-current state file |
| Risk level / maturity | low / established |
Failure modes
- Checkpoint drift: file says done, workspace disagrees
- Checkpoints too sparse to resume from
- State file grows unbounded
Assessment
The loop that makes context limits an engineering constraint instead of a wall. Reconcile-on-load is the difference between this pattern working and it laundering stale claims.