Key facts.
- Harder, contamination-resistant evaluations like SWE-bench Pro show real agent success rates are lower than headline benchmarks, so mid-task failures on long work are common. source
- Google's DORA research links changes in AI tooling to delivery tradeoffs, a reminder that long pipelines get interrupted and need recoverable state. source
- SWE-bench Pro success runs below the headline, so long tasks fail mid-run; a stronger model finishes more, not always, so savepoints help. (source)
Why does resumability matter for agents?
A long agent task is a long bet that nothing goes wrong before the end and that bet loses often. The agent can hit a step it cannot complete, a tool can time out, the model can error, the surrounding system can be updated mid-run. Without savepoints, any of these means starting over, discarding all the work done so far and paying for it again. The SWE-bench Pro picture is the reason this is not rare: once you strip benchmark contamination, real success rates on hard tasks are lower, so a long task is likely to hit a failure somewhere and an all-or-nothing design loses everything each time it does.
Checkpoints borrow the savepoint idea from databases and long computations. At meaningful boundaries, persist the agent's state, the goal, the completed steps, the validated intermediate results, so a failure can resume from the last checkpoint rather than the beginning. The discipline is choosing good boundaries (after each consequential, verified step) and capturing enough state to continue correctly. Done well, the cost of a mid-task failure drops from the whole run to the work since the last savepoint, which is what makes long-running agents economically and operationally viable rather than a repeated gamble.
What makes resumability work?
| Element | No savepoints | Checkpointed |
|---|---|---|
| On failure | Restart from zero | Resume from last savepoint |
| Checkpoint boundary | None | After verified steps |
| State captured | Nothing durable | Goal, progress, results |
| Cost of a failure | The whole run | Work since last savepoint |
Choosing where to checkpoint and trusting the state you saved, depends on knowing which steps are verified and meaningful, which the Pattern Intelligence Layer makes clear. VibeModel ties progress to the pattern that defines the task, so savepoints land after genuinely completed, reliable steps and a resumed run continues from state you can trust rather than from a snapshot that might encode a step that was actually wrong.
Frequently asked questions
Where should checkpoints go?
After consequential, verified steps, so a resume continues from a known-good state rather than a half-finished or unverified one.
Why are mid-task failures so common?
Real success rates on hard tasks are lower than headline benchmarks, as SWE-bench Pro shows, so a long task is likely to fail somewhere before the end.
How is this different from state persistence?
Persistence keeps state durable; checkpointing adds the resume points and verified boundaries that let the agent continue correctly after a failure.