A long-running AI task eventually develops two problems at once. It gets close to the context limit, and it becomes harder for the model to notice which earlier detail still matters. The tempting response is to summarize everything and keep going. That is better than an overflow, but a vague recap can quietly discard the exact file path, decision, test failure, or user constraint that the next step needs.
The practical move is to write a structured checkpoint before you compact, summarize, or hand a task to a fresh session. A checkpoint is not a diary of the conversation. It is a small state artifact: the goal, the verified current state, decisions already made, evidence locations, remaining work, and the conditions that would make the plan unsafe to continue.
Anthropic’s context-window guidance says that all request material—including system prompts, messages, tool results, images, documents, and tool definitions—consumes the window. It also warns that accuracy and recall can degrade as token count grows, and recommends server-side compaction for long-running conversations.[1] Its memory-tool guidance describes the complementary pattern: persist information outside the active context and retrieve it just in time, so the active task stays focused.[2]
Checkpoint the state, not the story
A useful checkpoint lets a new model or a human answer five questions without rereading a transcript:
- What is the intended outcome? Name the deliverable and its acceptance checks.
- What is already true? Record only completed, verified facts—such as a changed file, a passing test, or a returned record ID.
- Why was a choice made? Preserve the few decisions that constrain the next move, plus the evidence or source that supports them.
- What remains? List the next bounded action and its dependency, not a vague instruction to “continue.”
- What must not happen? Keep safety limits, rejected alternatives, and open uncertainty visible.
This differs from a prose summary. “We investigated deployment and made progress” is not recoverable state. “Remote directory inspected; only public/index.html is authorized for upload; local validation still required” tells the next context what it can safely do.
Copy this pre-compaction checkpoint
Write the checkpoint to durable storage your agent can read in the next session. Keep links, IDs, paths, and commands literal; do not replace them with a high-level paraphrase.
TASK: [specific deliverable]
SUCCESS WHEN: [observable acceptance checks]
VERIFIED STATE
- [fact]: [evidence: URL, file path, test command + result, or record ID]
- [fact]: [evidence]
DECISIONS LOCKED IN
- [decision]: [reason and evidence]
- [scope or permission boundary]: [what is allowed / forbidden]
WORKING SET FOR THE NEXT CONTEXT
- Read first: [small set of files, URLs, or IDs]
- Current artifact: [path and exact status]
- Next action: [one bounded action]
- Dependency / blocker: [what must be checked first]
OPEN QUESTIONS
- [unknown]: [safe fallback or who/what resolves it]
DO NOT
- [repeat an already-completed write]
- [broaden scope, use a stale result, or infer a missing value]
CHECKPOINT CREATED: [timestamp]
The important word is verified. Do not write “tests pass” because a model remembers seeing green output. Write the command, target, and result—or mark the check as not run. Do not say “the user approved it” unless an approval record or message is available to the next session. A checkpoint that turns guesses into facts is worse than no checkpoint because it gives the next agent false permission to act.
Compact only after the handoff is usable
Use a checkpoint at predictable boundaries: before a compaction threshold, before a risky write, after a completed milestone, and before delegating a subtask. Then test it briefly. Start a clean context—or ask a reviewer unfamiliar with the transcript—to read only the checkpoint and name the next action, the evidence to inspect, and the prohibited action. If they cannot do that, the checkpoint is still a recap rather than a handoff.
Keep the checkpoint small enough to retrieve cheaply. Large raw tool outputs belong in their original files or logs; the checkpoint should point to them with stable locations. Anthropic’s memory tool uses file operations controlled by the application, and its documentation recommends restricting memory operations to a dedicated directory. That is a useful operational model: use a scoped, durable store rather than sprinkling session state through temporary chat messages.[2]
Failure mode: the checkpoint becomes a stale control plane
A checkpoint can outlive the state it describes. A branch may change, a deployment may finish elsewhere, an approval may expire, or a source document may be replaced. If the next session treats the file as current truth without checking the linked evidence, it can duplicate a write or continue an invalid plan.
Add a timestamp and an evidence pointer to every consequential state claim. On resume, re-check volatile facts first: external status, file version, permissions, and pending actions. Treat the checkpoint as a map to verification, not a substitute for verification.
The habit to keep
when an agent’s context gets long, do not ask it to remember the whole journey. Make it leave a small, checkable handoff that gives the next context the right facts, the next safe step, and the boundaries it must preserve.