Memory & State in the Harness

An agent session is two hours into a multi-file refactor — a dozen files touched, several decisions made and revisited, a plan roughly half-executed — when something entirely ordinary happens. The machine it is running on reboots for a routine patch. Or the harness process managing the session hits an unhandled exception and dies. Or, on the platform team’s own schedule, an engineer ships a new version of the harness software itself while a hundred other sessions are still running against the old one. None of these involve the model reasoning badly. None are prompting problems, or context problems, or anything Volume II’s chapters on memory and drift have vocabulary for. They are the mundane operational hazards every piece of long-running software eventually hits, and the question they raise has nothing to do with the model at all: what happens to the two hours of work?

For a chat interface, the honest answer used to be “the conversation is gone, open a new tab.” That answer does not survive contact with what a coding harness has become. A harness managing sessions that run for hours, touch dozens of files, and accumulate real, unretraceable decision-making is not a stateless request handler anymore — it is closer to a database or a running batch job, and it needs the same operational seriousness those systems demand. Volume I priced what an AI session costs; this chapter is about the infrastructure discipline that decides whether that cost survives the ordinary accidents of running long enough for something, eventually, to go wrong.

Two different problems called memory

It is worth being precise about which problem this is, because the word “memory” already carries a full chapter’s worth of meaning from Volume II. Context engineering is a design decision about content: what an agent should carry forward, how much of it fits in a window, what gets compacted or dropped when the window fills. Anthropic’s own engineering writeup on harnesses for long-running agents is explicit that compaction, by itself, "isn’t sufficient" — but the boundary it is describing there is the context window filling up mid-task, a volume problem. This chapter is about a different axis entirely: whether a session’s state persists past the process holding it. A session that fills its window and gets compacted still has the same operating-system process behind it, still running, still able to act on the summary it just produced. A session whose process gets killed by a machine reboot has nothing behind it at all, and no amount of clever context curation touches that, because the thing doing the curating is gone.

What a checkpoint has to contain

The mechanism a harness reaches for here is durable checkpointing: writing enough of a session’s state to a medium that outlives the process — disk, a database row, a git branch — so a freshly spawned process can pick the work back up without re-deriving it from nothing. Anthropic’s harness writeup, describing a pattern built for a different problem (crossing context-window boundaries within one long task, not surviving a crash), lands on exactly this mechanism anyway. It describes a `claude-progress.txt` file that keeps a log of what agents have done, a feature-requirements file the agent updates as work completes, and — the most durable of the three — instructing the model to "commit its progress to git with descriptive commit messages," specifically so that it "allowed the model to use git to revert bad code changes and recover working states." None of that state lives in the process’s memory. All of it survives the process ending, which happens to be exactly the property a crash needs, even though crash survival is not the problem the writeup set out to solve.

What has to be in a checkpoint, concretely, is more than a transcript. It is the session’s position in whatever multi-step task it is executing — which step, what is confirmed done, what is still pending. It is the accumulated file changes, ideally as something as durable as a commit rather than an uncommitted working-tree diff that a dead process can no longer be asked about. And it is the plan itself, if one exists, because a session that comes back with its file changes intact but no record of the plan those changes were serving is a session that has to re-derive intent from artifacts — a strictly harder problem than reading the intent off a file that was written down on purpose.

Recovery is not the same claim as continuity

A well-designed harness treats a crashed session as a resumable one, not a lost one: on restart, it reloads the last durable checkpoint and continues, rather than starting the task over from zero or — the worse failure mode — silently discarding the last several minutes of unsaved work with no signal to anyone that anything was lost. This is exactly the distinction Volume II’s Context Recovery chapter draws between continuity and recovery, and it applies to a process crash with unusual precision. Successfully reloading a checkpoint after a restart is continuity — the state came back, the session is running again, nothing throws an error. Whether that reloaded state is still trustworthy is a separate question entirely, and continuity answers none of it. A checkpoint written thirty seconds before the crash might describe a plan that no longer matches a file some other process touched in the interim, or a “confirmed working” claim about code that was never actually verified before the process died mid-check. Reloading it faithfully does not make any of that true.

Reloading a checkpoint proves the state came back. It does not prove the state is still true — and a harness that treats the two as the same claim will recover confidently into a session that was already wrong.

Deploying the harness underneath a running session

The crash case at least has a clear failure mode: something broke, and the harness has to notice and react. The deployment case is harder, because nothing is broken — an engineer is deliberately shipping a change to the harness itself, and the challenge is doing that without breaking every session already in flight. A stateless API server does not have this problem in any serious form: a request that fails mid-deploy gets retried against the new instance, and the cost is a few hundred milliseconds nobody notices. A coding harness increasingly does not look like that server. It looks like a system with long-lived, stateful sessions — closer to an open database connection or a running batch job than a request — and killing one mid-task to roll out a new harness version destroys real, non-retryable work, or at best forces an untested crash-recovery path to fire across an entire fleet of sessions at once.

Borrowing rainbow deployment

The pattern most teams reach for, once they hit this problem, is not new — it predates AI agents by well over a decade and was never designed with them in mind. Blue-green deployment runs two full copies of a system side by side and switches traffic from one to the other once the new copy has been verified. Its generalization, sometimes called rainbow deployment, extends the same idea to more than two versions running simultaneously, with traffic — or, for a harness, session ownership — shifted gradually rather than flipped all at once. Applied here: a new harness version comes up alongside the old one, new sessions start landing on the new version as confidence grows, and — the detail that actually matters for a stateful system — sessions already running keep running against the version they started on, rather than being killed or force-migrated mid-task. Vendors offering this pattern specifically for AI-agent version rollouts describe the same shape: gradually increasing traffic to the new version while "simultaneously begin draining traffic from the underperforming instances" once its behavior earns the confidence, which is the same graceful-drain discipline general infrastructure has used against stateless services for years, aimed here at something considerably harder to drain safely.

The genuinely novel part is not the deployment mechanics — those are a solved problem borrowed wholesale from general distributed-systems practice, the same discipline behind Kubernetes giving a terminating pod a grace period to finish in-flight work rather than killing it outright, or the durable write-ahead logs that let a database recover to a consistent state after a crash instead of an arbitrary one. The novel part is what counts as “state” for a session being drained. A database connection or an open socket can be described completely enough to hand off or safely close. A session two hours into a task cannot — there is no way to serialize “what the model was about to decide next” the way a TCP buffer can be serialized. What can be handed off is a proxy for that reasoning: the same checkpoint artifacts already described — plan, progress log, last completed step, the commit history. Which is why durable checkpointing and harness deployment turn out to be the same infrastructure problem wearing two different hats, not two separate concerns a team can solve independently.

Operon Field Data

What to check on your own harness

1. Kill the harness process by hand, mid-session, in a non-production environment, and watch what actually comes back — not what the design doc claims should come back.
2. Confirm the checkpoint includes the plan, not just the file diffs. A session that recovers its edits but not its intent will re-derive the plan badly, or not at all.
3. Before the next harness deploy, ask whether sessions already running will finish on the version they started on — and if the honest answer is “they get migrated,” treat that as a known risk, not a solved one.
4. Log every crash-recovery and every mid-deploy session as its own distinct event, separate from a normal session end. If that data does not exist yet, it is the first thing worth adding.

None of this requires exotic infrastructure. It requires accepting that a harness running multi-hour sessions has quietly become a stateful system with the reliability obligations that come with the category, whether or not anyone designed it that way on purpose. Chapter 6 covered the deterministic control points a harness can enforce mid-session — hooks, gates, checkpoint approvals. This chapter has been about the layer underneath those: whether a session survives long enough to reach them at all. The next chapter takes the same durability question and stretches it across days instead of hours, into agents designed to run unattended overnight.