Reseed, don't compact

Every long-running agent eventually fills its context window. What happens next is usually automatic. As the window nears full, the harness summarizes the conversation and carries on with the summary.

The trouble is what it forgets, and it's one of the most common runtime alignment failures there is. A summary keeps the gist and drops the specifics, and in structured work the specifics are what matters. Which version did I last review? Which objections are still open? What conditions did I attach to my approval? Those are the details a summarizer treats as noise, and losing them doesn't raise an error. The agent just keeps working, slightly wrong. Long before that point, a nearly full window has already started to dull the agent's judgment.

The usual answer is a bigger window. That only moves the cliff. The better answer is to decide up front what must never be lost, and to make keeping it a property of the system instead of something you hope survives a summary.

A small, fixed core

In the design I use, every agent works from a protected core that stays resident the whole time. It's small, and it holds only what the agent can't afford to lose. That means the role's job, the task as the person actually stated it, the binding instructions that came with it, and the current state of the work: what was last reviewed, which objections are open and what conditions are outstanding.

The core is never written by the agent. The state section is derived mechanically from the record of what actually happened, so it can't drift from reality the way an agent's own recollection can. It's also byte-stable. The same inputs always produce the same text, with fixed ordering, capped sections and no timestamps. That makes the core a stable prefix the model provider can cache, and in my measurements it was served from cache on nearly every call. It also means rebuilding the agent from the core always gives you the same starting point.

Everything else, on demand

The bulky material, like the actual changes to review and the history of the discussion, doesn't get pasted into the core. The core holds pointers to it instead, meaning the exact query to run or the exact place to read, and the agent pulls what it needs for the task in front of it.

Pulling material on demand doesn't keep the window from filling. Whatever the agent pulls stays in context until it's cleared. What it buys is a smaller permanent footprint and, more importantly, the ability to pull it all again. The reseed keeps the window bounded, and the pointers make the reseed cheap.

Rebuild on purpose

Before each new piece of work, the agent's context gets measured. If it's still comfortably under a threshold, the agent picks up where it left off with its warm context intact. If it's past the threshold, set well below the point where the automatic summary would kick in, the agent doesn't resume at all. It starts fresh from the core and pulls what it needs again.

The measurement has to be how full the window actually is, not how many tokens you were billed for, because cached tokens are cheap to pay for but still take up room. And any uncertainty should tip toward rebuilding. A fresh start only costs some recent detail, because everything that matters lives in the core. A wrong resume can carry an overfull window straight into the summarizer and lose what the core was protecting.

An agent's notes are claims

Agents write things down as they work, like summaries of what they've reviewed or assessments of a colleague's progress. Those notes are useful, but they're claims. In that design, each note is stamped with the version of the work it describes, and when the work moves on, the note is marked stale and checked again against the actual changes rather than trusted. Memory is kept short, too. The running log of decisions is capped and condensed as it's written, so it never turns into a second, unbounded history.

There's also an escape hatch. Sometimes a resumed session carries a wrong conclusion, like believing it's still blocked on a question that was answered an hour ago, and it will faithfully repeat that every time it wakes up. An operator can evict that session so the next start rebuilds from the true state of the work.

Why not sub-agents?

The other way to keep a window from filling is to split the work across sub-agents, each with its own throwaway context, and only pass back what they found. That keeps the main agent's window small, though each sub-agent can still fill its own. I don't make it the default because it adds latency, means more prompts to keep cacheable, and introduces a new kind of error in how the work gets divided. In this design it's an escalation for the rare task that's too big for one context.

Why this needs structure

This only works because there's something stable to rebuild from. In intentional agentic work, the intent lives in a contract and the state of the work lives in a record, so the core can be derived from them at any time. In a free-form chat, the only record of what matters is the chat itself, and that's the thing the summarizer is about to compress.