After an interruption, you can identify finished work, reuse verified results, and restart only the uncertain stage. You will learn to separate intended work from actual results, measure completeness, and preserve recovery evidence.
Durable records preserve finished decisions
Work held only in an active conversation can disappear when the process stops or context changes. Write the goal, completed stages, current stage, decisions, and remaining uncertainty into a durable record. Dexter Horthy explains that saved artifacts let teams resume where they stopped without depending on compressed conversation history. Ryan Lopopolo likewise describes execution plans carrying progress and decision logs for complex work. Together, those records show the next worker which decisions remain settled and where uncertainty begins.
Recipes identify intended work
Before expensive work begins, record the inputs, order, settings, and tools that define the intended result. That recipe can name expected work early, while the produced result remains unavailable for inspection. Greg Kamradt's repository stores the recipe instead of each enormous rendered context, keeping records compact and repeatable. A matching recipe proves that instructions match, although it cannot prove the resulting content matches. Keep recipe identity separate because software changes can produce different results from identical instructions.
Content identity proves reusable results
After production finishes, create a separate identity from the content that actually exists. Reuse an accepted result only when this content identity matches the candidate you are considering. Kamradt's reconstruction process recreates the exact prior input from its compact recipe without repeating the model run. Exact input reconstruction helps investigation, although it does not prove the earlier response was complete or correct. If exact identity cannot be established, treat reuse as uncertain and perform the authorized work again.
Completeness decides whether reuse is safe
A successful finish signal cannot establish that the result contains everything your reader or customer needs. Choose a measurable property that exposes truncation, such as duration, item count, or expected coverage. Set any tolerance from your own product evidence, because another system's threshold may hide meaningful loss. Store the measurement beside the result, then confirm that saved evidence still belongs to current content. An equally sized replacement can leave a saved identity stale, so refresh it after outside changes. Reject missing measurements and measured shortfalls, while applying your product's separate rule to extra material.
Stable names reveal the restart point
Give each workflow, stage, and run a stable name that survives the active process. Record the accepted result and evidence beside that name before moving to the next stage. When an identity is missing, inspect persisted results before deciding whether an authorized restart remains necessary. Never repeat external actions silently, because their effects may survive even when the active process disappears. Stable names connect the durable plan to the exact evidence that justifies resuming after interruption.
Decide reuse from one fixed snapshot
Build each reuse decision from the last accepted state before the current process begins changing anything. Keep that snapshot unchanged while new results arrive, so every reuse choice shares one reference point. A missing or unreadable completion record should reduce reuse instead of blocking otherwise authorized work. Upload or rebuild unmatched results when allowed, then record the new accepted state for future recovery. If a batch reuse attempt is refused, fall back only to the already authorized individual action. Never widen existing permissions merely because the faster recovery route was refused or unavailable.
Checkpoints limit repeated work
Save a restart point only after a stage has produced accepted evidence and recorded its identity. Kamradt's runner uses resumption to skip completed cells when an interrupted sweep starts again. Harrison Chase describes checkpoints that let users return to earlier steps and rerun from there. Changing an earlier input invalidates later work that depended on it, even when those stages once passed. Keep independent accepted stages, then rerun only the uncertain stage and anything its changes affect.
Summary repair stays separate from completed work
Sometimes completed work survives, while its required summary is missing, malformed, or rejected. Preserve the completed effects and their identity, then retry only the summary from the same context. Instructions asking for summary-only recovery express intent, but they cannot prevent available actions from running. Verify that the repair sent no messages, changed no records, and repeated no completed effects. If isolation remains unproven, report the recovery limit before authorizing any wider repetition. Treat accepted results as the source of truth when summaries disagree with completed evidence.
The sources show durable recovery works
These sources connect durable plans with compact recipes, exact reconstruction, saved restart points, and completed-work skipping. They support reusing verified stages while isolating the smallest uncertain, stale, or failed portion. They do not establish that every stored result is complete, fresh, or safe for automatic reuse.
- Dexter Horthy, video, From RPI to QRSPI - Lessons Learned Rolling out Research/Plan/Implement to thousands of engineers, at 26:26. "you can always resume from where you left off"
- Greg Kamradt, repo, needle-in-a-haystack, at Each row in the JSONL is small (a. "We don't store the rendered 200k-token context per row"
- Greg Kamradt, repo, needle-in-a-haystack, at niah reconstruct walks the recipe and produces a. "produces a byte-identical string of what the model actually saw"
- Greg Kamradt, repo, needle-in-a-haystack, at run_name: "uuid-chain-opus" model: "anthropic-opus-4-medium" # resolved. "runner: concurrency: 2 retries: 2 resume: true"
- Harrison Chase, blog, How to think about agent frameworks, at Besides allowing the user to affect the agent. "go back to earlier steps and then rerun"
- Ryan Lopopolo, blog post, Harness engineering: leveraging Codex in an agent-first world, at Plans are treated as first-class artifacts. Ephemeral. "complex work is captured in execution plans with progress and decision logs"
Mark the last accepted stage in your current work and attach the evidence needed to reuse it.