Long-Running Agents: Checkpoints, Resume, and Steering

You launch an agent on a big refactor and go make coffee. Three hours later you come back to find it stopped forty minutes in. The reason is never interesting: your laptop slept, an API timeout went unhandled, the process died with the terminal. The agent had done good work. None of it was recoverable, because nothing was saved.

This is where harness engineering stops being about intelligence entirely. A model that could run ten hours unattended existed in 2025; runs that survive ten hours are mostly a durability problem, and durability is plumbing. It’s also the payoff of everything earlier in this series: the loop from part one, the context discipline from part two, the safety rails from part three. Put those together and the only thing left between you and overnight agents is making the run itself crash-proof.

Think of it like a mountaineering expedition. The summit push gets the glory, but what actually enables it is base camp: cached supplies, fixed ropes, marked routes. Long-running agents are a logistics problem wearing a fancy hat.

---

Checkpoints: git already solved this

The naive approach to durability is a bespoke state file: task lists, progress counters, serialized plans. Every team builds one. Most of them rot within a month, because they’re a parallel source of truth that drifts from reality the first time something edits files without updating the ledger.

The lazy-and-correct answer: the repository is the state. Commit at every meaningful milestone and the checkpoint story falls out for free:

# ❌ Custom progress tracking
# progress.json: { "step": 4, "filesDone": ["a.ts", ...] }  <- always stale

# ✅ The repo is the ledger
git add -A && git commit -m "wip: migrate auth module to sessions"

A resumed run doesn’t need to be told what happened. It can git log and git diff its own history, which is exactly how you’d onboard a human contractor. Claude Code ships built-in checkpointing along these lines, tracking file states so you can rewind a session after a bad turn, and I consider that feature table stakes now. If your harness of choice can’t do it, a post-turn hook committing to a scratch branch gets you eighty percent of the way.

One rule makes this safe: keep checkpoint commits cheap to undo. Work on a branch, or tag milestones, so abandoning attempt three means git reset instead of archaeology.

Resume: separate the conversation from the process

Checkpoints preserve work product. Resume preserves momentum. The distinction matters when a run dies: restarting from scratch wastes the completed work, but resuming badly replays old mistakes with fresh confidence.

What a resume actually needs is the conversation state (messages, tool history) plus a truthful account of the world (git status, test results). Notice the second half. A transcript alone lies, because the world moved on while the process was dead. Decent harnesses re-ground on resume: re-run the test suite, check the working tree, then let the model reconcile its plan against measured reality rather than its memories.

This is also why my rule-files philosophy insists on deterministic verification. When “done” is defined by tests and type checks, a resumed agent can rebuild trust in its own progress mechanically. When “done” is vibes, every resume starts with a leap of faith.

Steering: correct course without landing

The most underrated capability in modern harnesses is the ability to talk to an agent while it works. Not interrupting it into oblivion, queuing guidance that lands at the next safe point.

Without steering, your options during a long run are binary: let it continue down a wrong path, or kill it and eat the restart cost. With steering, the interaction looks like reviewing a junior engineer’s PR comment: “skip the migration script for now”, “that helper exists in utils/, use it”. Two minutes of input saves two hours of confident wandering.

The failure mode to avoid is steering as micromanagement. If you’re messaging the agent every five minutes, the run wasn’t ready for autonomy; fix the brief or the rules file instead. Steering is for course corrections, not joystick control. The whole point of everything in this series is buying back your attention, not spending it differently.

---

What it adds up to

Assemble the pieces and the shape of a serious long-run setup emerges. Here is that stack as a walkthrough. Step through one overnight run, from launch to morning, to see where each layer earns its place.

1. Sandboxed autonomy so unattended doesn’t mean unsafe.
2. Compaction and pinned decisions so hour nine has the context hour one had.
3. Commit-per-milestone so any crash costs minutes, not hours.
4. Re-grounded resume so the agent trusts measurements over memories.
5. Queued steering so you invest seconds of attention exactly when they matter.

None of these require a frontier model. All of them are code you can read, write, and improve. That’s been the argument of this whole series: the harness is where agentic capability actually lives, and engineers who treat it as infrastructure, versioned, tested, iterated, get results that prompt-tinkerers don’t.

So here’s the question I’ll leave you with, the same one I ask myself before every big run: if this agent worked all night without you, would your setup let it? If the honest answer is no, you now know exactly which layer to fix first.

Thanks for reading the series. Tell me how your longest run went (and whether it survived) on Twitter/X.