Persistent coding agents need verifiable handoffs

What makes a coding agent useful after the session ends?

I don't mean after the task ends. I mean after the session breaks: the laptop closes, the connection drops, the context window fills, or a process restarts. Work in progress rarely stops at a clean boundary. The agent worth having is one whose work survives that break.

My position is that the model doesn't give you continuity. You build it around the model, from three pieces: scoped ownership, durable state, and handoffs that the next session can check rather than trust. This is a design argument. I haven't measured it.

Why session-based continuity is fragile

I've described my own setup publicly. At the time, I said I still used the terminal, but mostly to talk to a few long-running agents. Each one owned a part of my work and kept its own memory. They lived on a hacky remote box that I reached from my laptop. The thing I said I still missed was better remote persistence. That describes the setup when I wrote about it, and it may change.

That gap matters. If continuity depends on a remote session staying alive, it is fragile in exactly the place where it needs to hold. So the useful question isn't how to keep sessions alive longer. It's how to make losing one cheap.

How ownership narrows recovery

When an agent owns a defined slice of work, a fresh session doesn't have to reconstruct the whole project. It only has to rebuild one area: these files, this goal, these open questions. I expect tight scope to make recovery more tractable. Vague scope risks turning every restart into archaeology.

Ownership also decides who writes the record. With one owner per slice, there is one place to look for that slice's state, and probably fewer conflicting accounts of what happened.

Keeping state outside the conversation

Anthropic has written about harnesses for long-running agents, and the report describes a failure mode that comes from session resets. A new session starts without the previous session's context, so it has to work out what already happened. It can misjudge the state of the work, for example by treating unfinished work as complete. In Anthropic's setup, the report credits incremental progress and structured handoff artifacts with helping. That report tells me nothing about how well my approach would work. It does describe a failure worth designing against.

The rule I take from it is this: if state exists only in a transcript, it isn't durable. It has to live in files, commits, and test results that outlive any single process. That's also why remote persistence matters to me. Losing a session on a remote machine shouldn't mean losing the work's state. That is the goal of the design, not something I've shown.

What makes a handoff verifiable

"Auth refactor mostly done" is a readable handoff note. It's also nearly useless, because the next session has to take it on faith. A verifiable handoff gives the next session something to check:

• the commit where work stopped
• a command that shows current status, such as a specific test target
• what passed, what failed, and what was never attempted
• the single next step, with a condition for when it counts as done

The test is whether a fresh session can confirm these claims before acting on them. Its first move should be verification, not continuation.

A hypothetical example: migrating a configuration loader

Suppose an agent owns the migration of a configuration loader to a new format. Partway through, the connection drops. Here is how recovery would go under the proposed workflow.

After each meaningful step, the agent runs the relevant tests, then commits its changes with a short progress file that records the result and next step. In this case, the file records that three of five call sites are migrated, the loader's unit tests pass, and two integration tests fail for a known reason. It names the next call site and the command that reproduces those failures.

A new session reads the file and runs the command. It sees the same passes and the same two failures. The handoff holds, and the session continues from the stated next step.

The cost is overhead. Writing that file after each meaningful step takes time, and on short tasks it may cost more than it saves.

When the handoff is wrong

Now suppose the progress file was written before the last edit instead of after it. The new session runs the command and sees three integration failures, not two.

A note the session simply trusts would hide that. The session would continue from a false premise and build on it. A checkable note shows the mismatch immediately. The right response is to stop, diff the working tree against the recorded commit, and repair the record before changing anything else.

This kind of checking has a limit: it only catches what the recorded command exercises. If the last edit touched code the status command doesn't cover, a stale note can still pass. Verification can only be as good as the check the previous session chose to record.

Verification doesn't prevent bad handoffs. Its job is to keep one bad handoff from spreading into everything that comes after it.

The same rule applies between agents

I've also mentioned publicly that I was having two agents exchange opinions and results, and that intuitively it seemed to work. I haven't measured it, so I won't claim it's better.

What I can say is what it would need: the same discipline. When one agent passes results to another, those results should be as checkable as a handoff between sessions. Otherwise you may just have built a faster way to spread unverified claims.

Designing for the break

Continuity is less about making sessions last and more about making the break survivable. Scope what each agent owns. Put state somewhere durable. Write handoffs the next session can test.

When I wrote about my setup, better remote persistence was the piece I said was missing. Even with better persistence, sessions will still break, so the handoff record is the part of this approach I'd least want to skip.