Answer
How should long-running agent work be checkpointed?
Whenever losing the work since the last one would be annoying, recording what is verified rather than what was attempted.
Whenever losing the work since the last checkpoint would be annoying, and each one should record what has been verified rather than what was attempted. A checkpoint that records intentions resumes onto a false premise.
The frequency question has a practical answer rather than a theoretical one: checkpoint whenever redoing the work since the last one would be irritating. Writing is cheap and losing a stage is not, so the error is nearly always too infrequent. Beyond the stage boundaries, any point where something expensive was discovered — a fact that took twenty minutes to establish, a route that was ruled out — is worth writing down at the moment of discovery rather than at the end.
The content matters more than the cadence, and there is one distinction that decides whether a checkpoint is usable. It must record verified state rather than intended state. A checkpoint saying the records were updated, written because an update was issued, resumes onto a false premise if that update failed. A checkpoint saying the records were updated and re-read as showing the new value is a fact. This is the same read-back discipline that applies to any completion report, applied to the thing a resumption will trust.
A usable checkpoint has four parts. Where the work stands, as verified state. What the next action is, specifically. What has been decided and why, so the resuming run does not reopen it. And what was attempted and abandoned, so the dead ends are not re-explored. The last two are the ones consistently omitted and they are what distinguish a resumption from a partial restart.
Checkpoints need to be cheap to write or they will not be written, which argues for appending to a file rather than for any structured mechanism. The format matters less than the habit, and a running plain-text record that a person can also read is more valuable than a schema nobody maintains. Where the work produces artefacts, the checkpoint should reference them rather than contain them.
There is a decision to make about whether a checkpoint can be wrong, and it can. A checkpoint recorded during a run that later turns out to have gone down the wrong path will faithfully record the wrong path, and resuming from it continues in the wrong direction with confidence. Dating entries and keeping the earlier ones is what makes it possible to go back further, which is the whole recovery mechanism when a wrong path is discovered late.
Finally, the checkpoint has to be somewhere the next run reads by default. A record written to a location nobody loads is a diary rather than a checkpoint, and the difference only becomes apparent at the moment of resumption, which is the worst time to find out.
A checkpoint is a claim about the world, so it should contain what you checked rather than what you told something to do.
Siddharth Sharma, Context Theory
Related questions
Should the agent decide when to checkpoint?
It can, and it should also be prompted by structure: a checkpoint at every stage boundary happens regardless of judgement. Leaving it entirely to the agent produces checkpoints when it feels like a moment, which correlates with progress rather than with risk, and the risky moments are the ones it does not notice.
How does this differ from a session handover?
A handover is written for a reader who has none of the context and is a deliberate act at the end of a session. A checkpoint is written continuously for a resumption that may never happen. In practice the last checkpoint often becomes the handover, which is an argument for writing checkpoints as though somebody unfamiliar will read one.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A checkpoint recording intended state rather than verified state causes a resumption to proceed from a false premise, because an issued instruction that failed is recorded as an accomplished change. | Interrupting a run after a failed write and inspecting whether the checkpoint records the change as made. |
| Response | Decisions with reasons and abandoned approaches are the two consistently omitted checkpoint components, and their absence turns a resumption into a partial restart that reopens settled questions and re-explores dead ends. | Resuming from an existing checkpoint and counting the questions the new run reopens. |
| Software | A checkpoint recorded during a run that later proves to have taken a wrong path faithfully records that path, so dated retained earlier entries are the mechanism for recovering to a point before the divergence. | Attempting to resume from before a wrong turn using only the most recent checkpoint. |
| Constraint | A checkpoint written to a location the next run does not load by default is a diary rather than a checkpoint, and the distinction becomes apparent only at the moment of resumption. | Starting a fresh run and checking whether it reads the checkpoint without human intervention. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one