Context: compaction, resets, and anxiety

Every agent task that lasts longer than a few minutes hits the same wall: the model has a context budget, and a real piece of work overflows it.

The harness has two ways to deal with this. The choice between them is one of the most consequential in the whole system.

The two strategies

Compaction keeps the same agent running. The harness summarizes earlier conversation in place (turns 1-3 collapse into a ∑ block), and the same model continues with a shortened history. Continuity is preserved. The model knows it's the same agent, working on the same task, with a memory of what it did before, even if the memory is fuzzier.

Context reset clears the window entirely. A fresh agent starts with no conversational memory of the previous one. The handoff lives on disk: a progress file, a feature list, a git history, an init.sh to bring up the dev server. The new agent reconstructs context from those artifacts.

Each has a real cost.

Context anxiety

This is the lever that makes the choice non-obvious. From Anthropic's engineering writeup (source: 2603.harness-design-for-long-running-apps.md):

"Some models also exhibit 'context anxiety,' in which they begin wrapping up work prematurely as they approach what they believe is their context limit."

Compaction preserves this. Even after the summary, the same agent keeps cumulative awareness of how much has happened. It can panic and declare victory early. A reset gives the next agent a clean slate with no sense of how long this has been going on.

This is one of those things that's hard to believe until you see it in your traces. The agent isn't stopping because it ran out of room; it's stopping because it thinks it's about to.

When the handoff is the cost

Choose resets and the handoff artifacts become the harness's main correctness surface. Whatever the next agent doesn't read on disk is gone forever.

This is why the artifacts take a specific shape. Anthropic's long-running-agents harness uses four:

JSON is used for the feature list because the model is empirically less likely to silently rewrite or delete entries from JSON than from Markdown. Strong-constraint > strong-suggestion when the artifact carries correctness.

A heuristic

From the source material, a defensible default:

• If your model exhibits context anxiety or degrades sharply near its limit, reset with structured handoff.
• If the model holds up at long context and you have a good context manager, compaction is simpler.
• Either way, anything that needs to survive should be in files, not in the conversation. Compaction may eat conversational state; a reset definitely will.

The third bullet is the durable lesson. Even if you choose compaction today, write the handoff artifacts anyway. If you upgrade your model in six months and switch to resets, you'll already have the surface to do it.

This is one face of a more general move. The 2026 externalization survey treats memory, skills, and protocols as parallel ways the harness moves cognitive burden out of the model: state lives in memory, repeated procedure lives in skills, and interaction structure lives in protocols. Progress files are the simplest case of externalized memory, where what survived a session becomes what tomorrow's session can read. (source: 2604.externalization-llm-agents.pdf, §3 and §6)

What about retrieval?

Retrieval is a different question. Compaction and resets are both about dealing with a context window that's already full. Retrieval is about what to put in it in the first place: pulling a few relevant files, docs, or memory entries instead of the whole repo.

Retrieval is a C-component concern. Compaction and resets are also C, but they're time-shaped; they decide what to do when the window overflows. Retrieval is space-shaped; it decides what to load into the window each turn.

A real harness does both.

Quick check

Why might a harness designer choose a context reset over in-place compaction?