Checkpoints and Save States for Long-Running AI Tasks
Checkpoints and save states let long-running agents pause, resume, recover, and hand off work without losing goals, decisions, approvals, or evidence of what already happened.
Long-running agents need artifacts that survive the current context
Anthropic’s work on long-running agent harnesses describes the challenge of continuing useful work across discrete sessions and highlights the value of leaving clear artifacts for the next session. [1] A checkpoint is the productized version of that idea. It should capture enough durable state that another run can continue without reconstructing the mission from a giant transcript. For gamified tasks, that means preserving objective, completed milestones, unresolved blockers, user constraints, and the evidence behind current progress.
A checkpoint is more than a summary
It is a contract about what the next run may safely assume has already happened.
Context compaction should preserve decisions, not every token
Anthropic’s context-engineering guidance recommends compaction and structured note-taking for long-horizon work, while warning that overly aggressive compression can discard details that later matter. [2] Save-state design therefore needs prioritization. Raw tool outputs can often be archived outside the active context, while architectural decisions, approvals, open questions, and dependencies deserve durable representation. A good checkpoint reduces cognitive load without erasing the reasons behind the plan.
Paused runs need resumable state rather than a fake restart
OpenAI’s Results and State guidance treats interruptions as resumable snapshots: a run may return pending approvals plus state that can be serialized and continued later. [3] This is crucial for long-running motivational systems. If a user approves a high-stakes action tomorrow, the system should resume the same mission state rather than inventing a new turn that may forget why the approval was requested. Continuity protects both safety and trust.
Resume the mission, not merely the conversation
The system should restore the exact operational context needed to continue safely.
Cancellation, failure, and approval pauses are distinct states
OpenAI’s running-agent guidance distinguishes runtime failures from expected pauses such as human approvals and notes that unfinished runs should resume from state when continuity matters. [4] A checkpoint model should therefore encode why execution stopped. “Waiting for approval,” “blocked on external service,” “failed after retry budget,” and “user paused voluntarily” are not interchangeable. The next action should depend on the stop reason, and the interface should communicate it plainly.
Checkpoint quality should be evaluated with replay tests
Workflow evaluation can use traces and repeatable datasets to identify failures in routing, tool use, and end-to-end behavior. [5] Long-running systems should add resume tests: interrupt at different nodes, restore from the saved state, and verify that the agent neither repeats completed side effects nor forgets unresolved constraints. A checkpoint that looks readable but cannot support correct replay is not operationally sound.
Resumability is testable
Teams can deliberately crash, pause, compact, and restore missions to measure whether state survives accurately.
Save states need stable identifiers for external side effects
If an agent created an event, sent a draft for approval, or updated a record, the checkpoint should store the external object identifier and current status. Otherwise, a resumed agent may repeat the action because it only remembers the intention. Idempotency keys and operation receipts help distinguish “planned,” “attempted,” and “completed.” This is especially important in gamified systems because duplicate actions can corrupt progress, rewards, and user trust at the same time.
Users should see meaningful checkpoint milestones
Not every technical snapshot deserves a badge. User-facing checkpoints should correspond to states that change what can happen next: research complete, plan approved, data verified, draft ready, deployment paused, or milestone reviewed. These are natural moments to summarize progress, invite correction, and give the user a sense of control. Technical snapshots can be more frequent in the background, but the visible save-state model should map to the person’s mental model of the quest.
Progress becomes safer when it is reviewable
A checkpoint is an opportunity to confirm that the system and user still agree on the goal before more autonomy is spent.
Good save states make failure cheaper
Without checkpoints, a long mission can turn one late error into a full restart. With them, recovery can return to the last verified state, preserving expensive research and completed work while reopening only the damaged branch. This changes the motivational experience of failure: the user loses a step, not the entire journey. Long-running AI becomes more trustworthy when the system can say exactly what is safe, what is uncertain, and where work will resume.
Checkpoint design also benefits from separating recoverable working state from long-term user memory. A mission snapshot may contain temporary file paths, task IDs, intermediate hypotheses, and pending approvals that should disappear when the quest ends. Long-term memory may contain stable preferences the user intentionally chose to retain. Mixing the two can create privacy problems and stale behavior: an old temporary constraint can accidentally become a permanent personalization rule. Lifecycle metadata should therefore say when state was created, which mission owns it, whether the user approved retention, and when it should expire. Good save-state architecture remembers enough to resume the work without turning every operational detail into a lasting profile of the person.
Works Cited
- 01Anthropic — Effective Harnesses for Long-Running Agents anthropic.com
- 02Anthropic — Effective Context Engineering for AI Agents anthropic.com
- 03OpenAI Developers — Results and State developers.openai.com
- 04OpenAI Developers — Running Agents developers.openai.com
- 05OpenAI Developers — Evaluate Agent Workflows developers.openai.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.