A long session needs durable state
Claude Code’s October 7 release notes for version 2.1.293 describe a context-compaction fix involving earlier actions and the retraction or repetition of finished work. The release note is specific to that version. It does not establish how often the issue occurred or guarantee that a long-running workflow cannot lose state in another way.
The design lesson applies to any agent with a bounded conversation history: chat context is not a reliable system of record. A model may summarize or compact prior turns, but the business process still needs a durable record of what was requested, what was completed, and what remains. Do not make the next action depend only on the model remembering its own last message.
Separate plan from confirmed progress
Represent each task as a small state record with an identifier, owner, status, input reference, output reference, and completion check. Use explicit states such as pending, in progress, done, blocked, and needs review. Mark a step done only after the relevant artifact or external system confirms it, not merely because the agent said it had finished.
When the agent resumes after a long pause, give it the current state record and ask it to reconcile the record against observable artifacts. If an item is marked done but the file or transaction is missing, escalate for review. If the output exists but the state record is stale, update the record after verifying the destination and avoid repeating the action.
Design steps to survive interruption
Break large work into bounded actions with checkpoints. Save intermediate artifacts in a location that has a clear owner and version history. After each write, verify that the artifact exists and meets a basic completion condition before starting the next dependent step. This reduces the amount of state that must be reconstructed when a session ends unexpectedly.
Use stable identifiers and make writes idempotent where possible. If a task creates a document, update the same identified draft instead of creating a new copy on every retry. If it sends an external action, use an explicit approval gate and reconcile the external result before resuming. The model should propose recovery; the system should determine whether the operation already happened.
Evaluate continuity, not just completion
Create a test set that intentionally crosses context boundaries: long input, several completed steps, a pause, and a resume. Verify the model continues from the last confirmed state, does not repeat finished work, and clearly distinguishes unknown status from failure. Include cases where a prior step partially completed or where a dependency changed during the pause.
Review the trace and resulting artifacts, not only the final answer. A polished summary can hide duplicate work or missed updates. Set a reviewer threshold for any change that affects a customer record, permission, payment, or published content. For less consequential work, use a lightweight spot check but keep the state transition visible.
Build a recoverable handoff
Before a task is handed to another session or person, write a short handoff: goal, completed steps with evidence, open steps, blockers, and next safe action. Keep private data in the approved system of record and link by identifier rather than copying sensitive content into a prompt. The next worker should be able to verify status without trusting an unverified narrative.
For a pilot, start with a multi-step internal task that has reversible outputs. Measure duplicate actions, lost work, and time to recover from a forced interruption. If the workflow cannot report what is complete and what remains, add a state ledger before adding more autonomy. Durable task state is part of the product design, not housekeeping after the model is selected.