/p/2026-07-30 · explainer
Paper explainer · 2607.25066 · Dang, Ichikawa, Fatima, Shirahata

Don't summarise it.
Give it an address.

A long-running agent always outgrows its window, and every standard repair is lossy in the same way: drop the oldest turns, paraphrase them, or push them to a vector store and hope similarity search finds them again. This paper keeps the bytes. Every tool observation goes into an append-only log under a short id; when the window fills, the old ones are replaced in the transcript by a stub — head, tail, size — and the agent gets a _recall command that puts the original back exactly, without re-running the tool. Asked afterwards for a fact buried in the compacted history it scored 99.0% against 79.6% for the best baseline on an 8B model. And the recall budget has a peak, not a ceiling: pull too much back and you have simply refilled the window.

01 · The problem

Compaction is a decision about what you will never see again

The window fills, something has to go, and whichever strategy you picked makes a silent bet: that nothing in the discarded material will matter later. Three observations, three ways of losing them. Step through the cases and switch how the transcript was compacted — the question at the end is the same each time.

Interactive · what survives compactionthe same observation, kept two ways

None of these are exotic. They are a test log, an API response and a directory listing — the ordinary output of a coding agent's first twenty minutes, and exactly the material a summariser compresses first because it looks like noise.

Interactive · buried-fact recall after compactionexact-answer accuracy · 1,000 attempts per seed
0%50%100%

Note where the gap lives. On the roomier 32B setup every strategy looks fine — 93.9% to 96.7% — and you would conclude the choice barely matters. Squeeze the window and the same five strategies spread across forty points. Compaction policy is invisible until the window is tight, which is precisely when you are shipping.

02 · The mechanism

A stub in the transcript, the bytes in a log

Nothing here is a model change. When a tool returns, the harness hashes the command signature together with the output and files the full text under the first eight hex characters of that hash — extended four at a time only if two different observations collide. The transcript keeps a stub. The agent is given one extra command, intercepted before it ever reaches the shell, that swaps the stub for the original. Step an observation through its life:

Interactive · one observation, four stateswhat the model actually sees in context
tokens in context
3,900
the full observation, inline
recoverable exactly
yes
it is right there

What the log keeps per observationthe store record, not the transcript

Two design choices carry most of the weight. The compaction routine is deterministic — no model call, so it cannot hallucinate the summary it is writing — and a bad id returns the nearest match rather than an empty result, so a mistyped address costs one turn instead of derailing the run.

03 · The budget

Recall has a peak, not a ceiling

The obvious next move is to let the agent pull back as much as it likes. It does not work, and the reason is worth sitting with: every recalled body is real tokens in a window that was already full, so a generous budget quietly reconstructs the problem compaction was solving. The paper sweeps the total recall budget and the per-recall cap together; the curve turns over.

Interactive · sweep the recall budgetaccuracy on hard long-document questions
accuracy at this budget
29.3%
the peak
vs the peak budget
0.0
points of accuracy

Both models peak in the middle. The smallest budget is the one place the paper reports ARC failing to lead — there is not enough room to build a useful memory structure — and the largest gives back most of the gain on the 8B model. If you build this, the budget is a tuned parameter, not a maximum.

04 · The bill

The cheap option is also the accurate one

Retrieval-based memory pays twice: it holds a full index and it re-injects retrieved chunks into a window that then has to be attended over again. Addressing pays once, and only when the agent actually asks. Under the paper's hardware cost model the difference is not marginal — switch the measure and the model.

Interactive · what the strategy costs to servesame tasks, same hardware model
0

The comparison that matters is the middle bar against the top one. A sliding window is the cheapest thing that isn't free, and it loses 43 points of buried-fact accuracy on the 8B setup to buy that. Addressing is cheaper and keeps the bytes, because a stub costs a hundred tokens and an index scan costs a pass over everything.

05 · Your agent

Price it against your own transcripts illustrative

The question this turns into for a real system: how much of what your agent saw is still reachable at the end of a long run, and what does keeping it reachable cost you in context. Set the shape of your workload and switch the strategy. The stub overhead is the honest part — at high observation counts the stubs themselves start eating the window, which is the same force that bends the curve in section 03.

Interactive · reachability and context costillustrative — a stub is charged at ~110 tokens
still recoverable exactly
120
window spent on history
42%

The shape to take away: summarising has a hard reachability cliff that arrives the moment the window fills, while addressing degrades gently and only ever costs you stub overhead. Push the observation count high enough with a small window and even the stubs stop fitting — which is the paper telling you, honestly, that this buys headroom rather than infinity.

The numbers

What the paper actually reports

What this does not show

In practice