Workflow Recovery

Four in the afternoon, a session two hours into restructuring how a service authenticates its internal calls — three approaches tried, one settled on, half the call sites updated — and the engineer running it has somewhere else to be. A kid needs picking up, or a meeting neither the engineer nor the agent can attend runs long. The laptop closes. Nothing about the moment feels risky. Tomorrow, the plan is to open the session back up, right where it left off, and keep going.

That plan works, more often than not, because “pick it back up” is the easiest of four genuinely different problems this instinct gets applied to without anyone noticing the difference. Coming back to your own paused session tomorrow is not the same problem as a teammate picking up your session because you are now on a plane. Neither is the same as opening a brand-new session next week, informed by what a completed one taught but not literally continuing it. And none of the three is the same as realizing, twenty minutes into today’s session, that the decision made at minute five was wrong, and wanting to go back to exactly that point without discarding everything built since. Four shapes, one word — resume — casually covering all of them, which is exactly how a team ends up surprised when the tooling built for the easy case turns out not to help with the other three.

One word for four different problems

Naming them precisely earns its keep, because the support each one needs differs in kind, not just in degree. Resume means the same person, the same session, the same approach — paused, then continued, with nothing about the plan or the reasoning behind it changing in the gap. Handoff means a different person, or a different AI session, taking over someone else’s in-progress work, and needing context a plain resume never has to reconstruct, because the original person already had it in their head and never had to write it down for themselves. Continuation means starting over: a genuinely new session, not a literal resumption of the old process’s state, but one deliberately informed by what a completed or abandoned session learned. And mental rollback means backing up to an earlier decision point inside a session’s own history and exploring a different path from there — not a git-level code revert, which Chapter 4’s checkpoints already cover, but a chance to ask what would have happened at minute five without losing the record of what actually happened when the session went the way it went.

The four recovery shapes

The cost column is where the four stop looking like variations on a theme. A botched resume mostly wastes a little time re-reading a plan that never went anywhere. A botched handoff can cost far more, because the person now holding the work has no way to distinguish a decision that was carefully considered from one that was arbitrary — both look, from outside, like a file that changed. Continuation sits in between: nobody is actively confused, but a team that starts every retry from a blank page is quietly paying, session after session, to relearn lessons a prior session already earned. Mental rollback is the strangest of the four, because getting it wrong produces no error at all — it just produces amnesia. The abandoned path simply stops existing the moment someone commits to the new one, and nobody notices the loss until they want to compare the two and cannot.

What actually has to survive the gap

Underneath the differences, the four shapes share a premise easy to miss: a session’s real state was never just the code diff. Anthropic’s own guidance on managing a growing context window makes a version of this point from a different angle, warning that trimming a session’s history too aggressively can quietly drop details whose importance nobody notices until later. That caution was written about a context window filling up mid-task, not about a session ending — but it names the same fragile thing this chapter is about losing across a gap instead of across a window. Not the files, which version control already tracks durably. The decisions, and the reasoning behind them, that explain why the files ended up the way they did.

This chapter’s four shapes should not be confused with the crash-and-deploy durability Volume IV covers in its chapter on memory and state in the harness. That chapter’s subject is a process dying underneath a session nobody chose to interrupt — a reboot, an unhandled exception, a harness redeploy — and its answer is durable checkpointing: a plan, a progress log, and a commit history that survive the process that wrote them, so a freshly spawned process can pick the work back up without a human involved at all. Every shape in this chapter is, by contrast, a voluntary interruption. Nobody’s process died. The engineer closed the laptop on purpose, or handed the session to a teammate on purpose, or decided on purpose that a decision five steps back deserved a second look. A harness that only solves crash recovery can still fail all four of these ordinary cases, precisely because none of them is a crash — they are what happens when work continues across a boundary nobody was forced to cross.

Handoff is where the missing half is most expensive, and software engineering already has a name for the version of this problem that has nothing to do with AI. Architecture decision records exist specifically because the reasoning behind a choice — as opposed to the choice itself — is one of the hardest things a project loses track of over time, easily enough that a later engineer either follows an outdated decision blindly or reverses a sound one for no good reason, both for the same underlying cause: nobody wrote down why. An AI session accumulates exactly that kind of untracked reasoning, just faster, and across more decisions per hour than most human teams make in a week. Resume never has to solve this, because the person coming back is the person who made the decisions, and the reasoning is still wherever their own memory left it. Handoff does not get that shortcut. The person picking up someone else’s session was never in the room for any of it, so anything not written down might as well not exist for them.

A handoff inherits the diff for free. It only inherits the reasoning if someone made a point of writing it down.

Continuation looks like it should be the easy case, since it involves no other person and no interrupted process — just a new session, started fresh. It is not automatically easy, because “fresh” can mean informed or it can mean ignorant, and nothing about opening a new session guarantees which. A session that abandoned an approach after discovering it did not work has produced exactly the information a second attempt needs most: not the code, most of which gets thrown away, but the knowledge of what was tried and why it failed. A harness that discards that information the moment the first session ends is not starting the second one fresh. It is starting it blind, and billing for the privilege of relearning what the first session already knew.

Mental rollback is not a checkpoint rollback

It is worth being precise about what mental rollback is not, because Chapter 4 already covers something that sounds similar and answers a different question. A checkpoint gate pauses a session between plan steps and lets someone approve, reject, or roll back to a prior snapshot — a mechanism aimed at catching a step whose results turned out badly once they were visible. Mental rollback is not about a step turning out badly. It is about deciding, possibly with no error anywhere in sight, that an earlier choice — which library to use, which of two workable designs to pursue — deserves reconsidering, and wanting to explore the alternative without first declaring the original approach wrong. The two mechanisms can even target the same moment in a session’s history and still be asking different things: one asks whether a step’s output passed inspection; the other asks whether the plan itself, several decisions back, still deserves the confidence it was given at the time.

The tool this maps onto is not novel, and it does not need to be. It is the same idea version control has offered for two decades under the name branching: diverging from a line of work to try something else, without touching or discarding the line that was already there. What is new is applying that idea to a session’s decision points rather than to a codebase’s commit history — forking a new line of work from an earlier moment in an AI session’s reasoning, rather than from an earlier commit, and being able to compare what happened down each path afterward instead of being forced to pick one and lose the other.

What a recovery dashboard should show

None of the four shapes is hypothetical inside Operon’s own harness — each has a real, shipped mechanism behind it, though no volume-wide dataset yet exists connecting how often each is used to how well it holds up. The figures below are illustrative rather than measured, in the same spirit as this Library’s other field-data sidebars: the kind of telemetry a durability claim in this territory should eventually be checked against, not a result to cite.

What to check on your own harness

1. Ask a teammate to take over one of your own in-progress sessions, cold, with nothing but what the harness hands them automatically. Time how long it takes before they are guessing instead of reading.
2. Check what an abandoned session leaves behind. If the honest answer is “a diff and nothing else,” the next session attempting the same goal is starting from zero, not from a lesson.
3. Find the last time someone wanted to reconsider an early decision mid-session. Did the harness let them explore the alternative while keeping the original, or did exploring it require deleting the original first?
4. Separate “did the session come back” from “did the session come back with its reasoning intact.” The first is easy to verify. The second is the one that actually matters, and the one most harnesses never check.

None of this requires exotic machinery. It requires treating a session’s decisions as data worth persisting in their own right, not as a byproduct that happens to survive only if the transcript does. The previous chapter covered what happens when a session stalls without anyone noticing; this one has been about what happens when a session stops on purpose, and how much of what made it valuable survives the stopping. The next chapter turns from any single session’s fate to the shapes whole sessions take — named working patterns with their own cost and quality profiles, visible only once enough interrupted, handed-off, and rolled-back sessions have been compared side by side.