The Four Layers a Harness Has to Hold Together
A harness is not one polished system prompt — it is a tool registry, a context manager, a safety-supervision layer, and a feedback loop wired together into a runtime environment. Anthropic's Applied AI team frames the design principle as finding "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome." One redundant tool description or one unnecessary example quietly eats into a finite attention budget, so a harness is not a prompt-writing skill — it is an architecture decision about exactly what gets exposed to the model.
Context Is a Resource You Can Run Out Of
The longer an agent runs, the more each step feeds the next, and without compaction, pruning, or offloading the context window simply overflows. Anthropic splits the response into three strategies: compaction, which summarizes older interactions down to the decisions that still matter; structured note-taking, which persists state outside the context window and re-injects it on demand; and sub-agent isolation, which pulls deep exploration out of the main loop. None of the three shrinks the total context you need — each one is a rule, decided in advance, for what gets dropped and what survives.
From Design to Operations: A Checklist for Long-Running Harnesses
Planning starts with splitting the harness into an initializer agent and a coding agent. The initializer runs once at project start, expands requirements into a structured file such as feature-list.json, and writes an init.sh that documents the boot sequence — so every later session reads that file instead of re-discovering the project from scratch. A reasonable target metric to fix in code from day one: trigger compaction automatically once context usage crosses 70% of the available window.
Continuity across sessions is never carried by a single document — it needs a progress log alongside commit history to actually restore state. Saving a short progress note (in the style of a claude-progress.txt) together with each commit — what got done, what's left — lets the next session reconstruct state from the git log and the note alone, with no conversation history required. Treat one checkpoint commit per session as the floor, and gate commits so they only land once tests pass.
Long-running loops tend to fail in three recurring ways. First, early stopping — the agent decides it's done before the goal is actually met. Second, decomposition failure — a complex task never gets broken into sub-steps, so the agent tries to force it all into one context window and collapses. Third, incoherence across context windows — as work stretches across sessions, earlier decisions and later judgment calls start to contradict each other. The symptoms differ, but the root cause is the same: the harness never had a rule for compacting and carrying state forward.
Recovery takes more than a retry. Once context crosses the threshold, run compaction immediately to keep only the decisions that matter, and re-inject anything compaction would otherwise lose by writing it into the structured progress note first. Isolate sub-tasks that need deep exploration into sub-agents so a failure there never contaminates the main context. And declare an abort condition in code ahead of time: once repeated failures cross a threshold, roll back to the last checkpoint commit and escalate to a human instead of continuing to retry.
Before shipping, reproduce two scenarios directly: a session restarting after an interruption, and context being force-compacted mid-task — in both, confirm the progress note alone is enough to restore state. Standardize log fields around session ID, per-turn context token usage, checkpoint commit hash, and compaction event count, and mask any user-identifying information out of progress notes and logs before they're persisted.
When the agent that generates the work also grades its own output, pass rates tend to run inflated — evaluation is safer as a separate subagent's job. Splitting the generator from the evaluator turns a biased, overly generous self-check into an honest feedback loop where one side catches what the other side would let slide.
Don't carry a harness forward unchanged every time you swap in a new model — autopsy it first. Strip out instructions or tools that were only there to work around the previous model's limitations and no longer earn their keep, then fill the gap with whatever the new model handles well instead. Pulling the top recurring failure types into a separate harness changelog every week gives the next autopsy something concrete to start from.
The Short Version
Long-running agents survive across sessions when the harness itself is the design target, not a single polished prompt. Trigger compaction at a 70% context-usage threshold, leave a progress note and a commit as a checkpoint every session, keep generation and evaluation as separate roles, and autopsy the harness whenever the underlying model changes.