Context Recovery

Every team that has run agents long enough has watched a session go sideways. It proposes a fix it already tried twenty minutes earlier. It insists a file exists that was deleted an hour ago. It re-reads the same three files for the fourth time, contradicts a decision it made in this same conversation, and starts narrating confidence about a plan that no longer matches the code on disk. Nothing has crashed. Nothing has thrown an error. The session is still running, still responding, still technically working — it has simply stopped being grounded in what is actually true, and the engineer watching it has to make a call: keep pushing, or cut losses and start over.

Starting over feels like the expensive option. There is a real session sitting there with real accumulated context — decisions made, files read, a partial diff — and closing it feels like throwing that investment away. But Volume I’s Session ROI chapter already made the sharper point: “done” and “worked” are not the same thing. A thrashing session that eventually limps to a working diff is not obviously cheaper than a clean restart three exchanges earlier would have been; it is just a cost that never gets logged next to the token bill, because nobody tags “eventually worked, but wasted forty minutes getting there” as a distinct outcome. This chapter is about the deliberate practice on the other side of that decision — what it actually takes to recover from context loss well, instead of either pretending the session is fine or discarding it and re-deriving everything from zero.

The instrument that reads wrong

The obvious plan — ask the session whether it is still on track — does not work, for the same structural reason Volume I’s perception-gap finding does not go away with practice. In METR’s randomized trial, experienced developers using early-2025 AI tools were measurably slower while believing they had been faster; self-report and ground truth pointed in opposite directions. A degraded session has the same blind spot turned inward. It is generating fluent, confident text about its own state, and fluent confident text is exactly what a drifting model produces most reliably. Asking a session to self-assess whether it needs to restart is asking the one component least equipped to notice.

The deeper problem is structural, not incidental. Anthropic’s engineering writeup on long-running agent harnesses opens from the plain fact that “each new session begins with no memory of what came before” — any task that spans more than one context window is, by construction, going to hit a boundary where something has to carry forward and something does not. Recovery is not an edge case bolted onto sessions as an afterthought. It is a requirement built into the shape of any task too large for one window, which by 2026 describes most real engineering work.

Continuity is not recovery

Teams that have already built session persistence tend to conflate two things that only look alike. Session continuity is a session surviving the restart of the underlying process — the daemon crashes, the app reopens, the connection drops — by reloading its own saved state: same goal, same accumulated context, same open files, picked back up where it left off. It is an engineering achievement, and Anthropic’s harness writeup documents exactly this kind of mechanism: a progress log and a feature-status file that let a freshly spawned agent resume a multi-session task without re-deriving where it stood. But continuity only proves the state loaded. It says nothing about whether the state that loaded was trustworthy in the first place.

That gap is easy to miss because a successful reconnect feels like relief — the session is back, nothing was lost — and relief reads as confirmation. It is not. A session that reconnects with a stale understanding of the codebase, or with context that had already crossed into Chapter 3’s warning or critical health band before the crash, comes back exactly as degraded as it left. Continuity restored the session. It did not recover it. Recovery is a separate, deliberate act, and the rest of this chapter is about what that act actually consists of.

The handoff summary

The artifact that makes deliberate recovery possible is a handoff summary: something one session writes specifically so the next one — a genuine restart, a human resuming the next morning, or a parent session hard-splitting into a child — can re-ground quickly instead of re-deriving everything from scratch. The design constraint that matters most is what a handoff summary is not: it is not a transcript. Dumping the full conversation into the next session’s context defeats the purpose entirely, because it just re-imports the same context rot risk the volume’s second chapter already named — more tokens, not more grounding, and a fresh session that inherits the noise along with whatever signal was buried in it.

Anthropic’s context-engineering writeup states the underlying principle plainly: the goal at every point is “the smallest set of high-signal tokens that maximize the likelihood of the desired outcome,” and its description of compaction is a useful model for what a good handoff selects. Claude Code’s own compaction, per that writeup, “preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages.” A handoff summary is the same triage, applied deliberately at a session boundary rather than automatically at a token limit: goal, decisions made and why, what is confirmed working, what is still open — and, critically, what has already been tried and ruled out, so the next session does not spend its first twenty minutes rediscovering a dead end that was already paid for once.

Human on-call practice solved a version of this problem long before agents needed it, and the analogy is closer than it first looks. Google’s SRE book treats the incident document as the load-bearing artifact of a handoff: a live, curated record — not a chat log — that keeps confirmed facts separated from working hypotheses so that whoever picks up the incident next does not have to re-litigate what has already been ruled out. A shift handoff that consisted of the full pager transcript would be worse than no handoff at all; the value is entirely in the curation. A session handoff summary is that same discipline, aimed at an agent instead of a human responder.

A handoff summary is not a transcript. It is the ten percent of the session worth keeping, and the deliberate decision to drop the rest.

Restart-with-handoff

Put continuity and the handoff summary together and the chapter’s actual recommendation follows: restart-with-handoff, not push-through, once a session’s context health has crossed into a band it is not going to recover from on its own. The pattern is deliberate on purpose — end the degraded session cleanly, have it (or the engineer watching it) write the goal, the decisions, what is confirmed, what is open, and what not to repeat, and start a genuinely fresh session against that summary rather than the old session’s accumulated, already-compromised context. This is not the same operation as compaction summarizing a conversation in place; it is closer to a full amputation, with a note left behind for whatever comes next.

The reason teams delay this longer than they should is not usually a lack of tooling — it is a well-studied cognitive bias. Sunk-cost reasoning treats the effort already spent on a session as a reason to keep spending on it, even though the only question that should matter is whether the next token is best spent continuing or restarting. The psychology of sunk cost has been documented since the 1980s and it applies here without modification: an engineer watching a session that has already cost forty minutes and $6 feels the restart as a $6 loss, when the honest accounting is that the $6 is already spent either way, and the only live decision is which path is cheaper from this point forward. A thrashing session rarely announces the moment it crossed that line; a context health score is the closer thing to an objective signal a team has for calling it.

What a handoff keeps, and what it drops

Operon Field Data

Building the habit

1. Treat writing the handoff as part of ending a session, not an afterthought once things have already gone wrong — the best handoffs come from sessions that finished cleanly, too.
2. Trigger restart-with-handoff on an objective signal, such as a context health band crossing, rather than waiting for a human to notice the session has been circling for ten minutes.
3. Record the dead end even when the session eventually succeeded. The session that benefits from “we tried X, it does not work” is usually a different session entirely.
4. Keep the same three fields available for a human-initiated handoff: goal, what is confirmed, what is still open. An engineer ending a session manually at 6pm should be able to write it in under a minute.

None of this requires new infrastructure so much as a decision that ending a session well is part of the job, not a courtesy owed to whoever happens to pick it up next. Chapter 6 takes up the other half of the recovery problem — drift, where the session’s own understanding quietly diverges from a codebase that changed underneath it without ever crashing at all.