Ask an engineer how their agent handles a long task and you will usually hear about the model, the tools, maybe the memory store. Ask what happens at minute forty when the context window is 80% full, and you will usually get a shrug and the word “compaction.” That shrug is the most consequential unexamined decision in long-horizon agent design, because compaction is not a housekeeping detail. It is a lossy transformation applied repeatedly to the agent’s entire understanding of what it is doing, and like everything else applied repeatedly, it compounds.
The previous post was about per-step reliability compounding over steps. This is the same disease one level up: per-compaction fidelity compounding over compactions. And it is nastier, because the thing being degraded is not one action but the context every future action is conditioned on.
01The window is a budget, not a container
The mental model most people carry is that a context window is a container: it has a size, you put things in it, and the engineering problem is making it bigger. Bigger windows have duly arrived, and the problem has not gone away, because the actual dynamics are a flow, not a volume. A long-running agent generates tokens continuously — tool results, reasoning, file contents, errors — at some rate. Any fixed window, however large, is a bathtub with a tap running.
Which turns the design question from “how much fits” into something much more like cache policy: at the moment the window is full, what do you evict, and where does it go? There are only a handful of real answers, and they have wildly different consequences.
02Five policies, one task
| Policy | What happens when the window fills | How it fails |
|---|---|---|
| Append everything | Nothing. It fills, and the run stops. | Loudly and early — the one honest failure mode on this list. |
| Sliding window | Drop the oldest tokens. | Silently. The plan scrolls out first, and the agent keeps going with perfect recall of the last ten minutes and no idea what it was asked to do. |
| Compaction | Summarize the history into a smaller block and continue. | Gradually, and invisibly. Each pass is plausible; the twentieth is a summary of a summary of a summary. |
| Write, then compact | Persist load-bearing facts to durable notes first, then compress; reload on demand. | At the boundaries — whatever the agent failed to recognize as worth writing. |
| Sub-agent offload | Push sub-tasks into their own fresh windows; only summaries return. | At the seams. Facts discovered inside a sub-agent exist only if its summary happened to mention them. |
Most production systems run some blend of the last three, usually without having chosen deliberately. The lab below runs all five against an identical task — same length, same facts, same moments those facts are needed — so the only variable is the policy.
03The lab
A long task. Some steps produce a load-bearing fact — a credential, a constraint, a decision, a thing the user said — that a later step will need. The green area is context in use, blue lines are compactions, and each red dot is a step that executed while missing a fact it required. That last one is the category that matters: not a crash, just an action taken on a wrong premise.
Click through the five policies and watch the shape of the failure change. Append everything ends the run outright, and note the trap in its numbers — near-perfect recall, because it died before most facts were needed. That is precisely how this policy passes a short demo. Sliding window survives forever and accumulates red dots, while carrying a full window on every step, which makes it both the leakiest and the most expensive option on the list.
Then compaction: the sawtooth everyone recognizes, the run completes, and recall falls to 62% — twenty-five steps executed on information the agent no longer had. Finally write, then compact — same sawtooth, same number of compactions, same cost, and almost every red dot is gone.
One detail in the compaction chart is the whole argument in visual form: the red dots get denser as the run goes on. The first stretch is nearly clean, the second has a few, the last is a spray of them. That gradient is not noise — it is fk drawn on a screen. Early in the run few compactions have happened and most facts are intact; by the end, every surviving early fact has run the gauntlet three or four times. An agent degrades slowly and then constantly.
The result worth staring at
Compaction and write-then-compact compress exactly the same amount, at the same cost, and differ by twenty-three steps that did or did not execute on information the agent had lost. The compression was never the problem. Doing it without first writing anything down was.
Note that write-then-compact does not reach zero either — two misses survive. Those are the boundary cases from the table above: facts the agent never recognized as worth writing. That residue is the honest floor of this approach, and it is a much better problem to have than the twenty-five.
04Why compaction compounds
Here is the arithmetic the lab is dramatizing. Let f be fidelity — the probability that a given load-bearing fact survives one compaction intact. A fact created early must survive every compaction that follows it, so after k of them its survival probability is fk.
Now note that k is not a constant. Compaction fires whenever the window refills, so the number of compactions grows linearly with task length. Doubling the length doubles the exponent — which squares the survival probability:
| Task length | Compactions | f = 90% | f = 70% | f = 50% |
|---|---|---|---|---|
| 100 steps | 1 | 90% | 70% | 50% |
| 200 steps | 2 | 81% | 49% | 25% |
| 400 steps | 4 | 66% | 24% | 6% |
| 800 steps | 8 | 43% | 5.8% | 0.4% |
Survival of a fact created in the first stretch of the run, at a 200k window and ~1.2k tokens per step.
Read the f = 90% column first, because 90% sounds like a summarizer doing a good job. Over an 800-step task it retains 43% of what it started with. A summarizer you would describe as excellent loses more than half the early context of a long run, and it does so without ever producing an output that looks wrong.
Inverted, the bar is brutal. To keep 90% of your earliest facts across a 400-step run, you need 97.4% fidelity per compaction — a summarizer that preserves ninety-seven of every hundred load-bearing details, repeatedly, with no idea which ones will matter later. Nobody’s summarizer does that, and asking for it is the wrong move anyway.
And the loss is ordered exactly backwards
Compaction pressure is a function of age: the older a fact, the more compactions it has had to survive. But importance is also a function of age, in the same direction and for the same reason. The oldest things in the window are the task description, the plan, the constraints, the user’s stated preference, the decision made in hour one that everything since depends on.
So the policy applies maximum compression to maximum-value context, and minimum compression to the tool output from ninety seconds ago. Sorted by what you would choose to lose, it is almost exactly upside down — which is why the characteristic long-run failure is not an agent that forgets a detail, but an agent that is still working, still confident, still producing plausible output, on a task it no longer correctly remembers.
› Go deeper: this multiplies with the per-step failure rate, it doesn’t add to it
These two compounding processes are not independent problems to be budgeted separately. A step that executes while missing a fact it needed is a step with a much higher failure probability — so degraded context raises the per-step error rate, which the horizon math then raises to the power of the number of steps. Memory loss feeds the exponent.
That interaction explains something otherwise puzzling about long runs: quality does not decay smoothly, it falls off a shelf. For a while, the facts still in the window are enough; then a compaction takes one that matters, the agent starts reasoning from a wrong premise, and every subsequent step is both more likely to fail and more likely to write new wrong facts into the context that the next compaction will faithfully preserve. The window fills with confident, well-summarized error.
05What actually works
The lab collapses to one instruction — write before you compress — but it is worth unpacking into the things you would actually build.
Externalize before you compact, not after. The moment to persist a fact is when it is created and still in full fidelity, not at the compaction boundary when it is competing for space with everything else. A compaction routine whose first action is “append anything load-bearing to the notes file” converts an irreversible loss into a retrieval.
Make the plan immune. The task description, constraints, and current plan should be structurally exempt from compaction — pinned, re-injected verbatim each cycle, or held in a file that is re-read on every compaction. They are the highest-value, most-compressed region in the window, and the fix is to simply take them out of the game.
Treat compaction as an evaluable component. Fidelity is a number you can measure: seed a run with known load-bearing facts, compact, and ask whether they survived. Almost nobody does this, which is why almost nobody knows their f — and everything in this post is a function of f.
Prefer fewer, larger compactions to many small ones. Survival is fk, so k is the exponent and deserves more attention than it gets. A policy that compacts at 90% full and down to 20% does fewer rounds than one that compacts at 60% down to 40%, and the exponent is where the damage is.
Use sub-agents to reduce k, and mind the seam. Offloading work to fresh windows means the main context grows slowly and compacts rarely. That is real leverage, and the lab shows it — but the leak simply moves to the summary boundary, where a sub-agent discovers something important and doesn’t mention it. The same rule applies one level down: the sub-agent should write to the shared notes, not just report.
06Where this model is wrong
The lab is a model, and its knobs are chosen, not measured. Three places it is too kind and one where it is too harsh.
Too kind: it treats fidelity as a fixed probability per fact, when in reality summarizers have systematic biases — they preserve narrative and drop specifics, which means the facts most likely to be lost are precisely the exact strings (paths, IDs, versions, thresholds) that are hardest to re-derive. It assumes a lost fact is simply absent, when a summary can instead preserve a distorted version, which is worse than absence because nothing triggers a re-read. And it assumes facts are needed once; real constraints are needed continuously, so one loss damages every later step rather than one.
Too harsh: real agents can often re-derive a lost fact — re-read the file, re-run the command — at a cost in steps rather than a hard failure. That recovery path is real and this model ignores it, though note what it does to the other equation: re-deriving lost context is more steps, and more steps is more compactions.
Takeaways
- Context management is a policy, and you already have one — the only question is whether you chose it. Write it down, then argue with it.
- Compaction fidelity compounds. Survival of early context is
fk, andkgrows with task length, so each doubling of the task squares the loss. - 90% fidelity is not good. It is 43% retention over an 800-step run. Holding 90% of early facts across 400 steps demands 97.4% per compaction.
- The compression is not the problem. Writing load-bearing facts down first costs nothing extra and, in the lab, closes the entire gap.
- Exempt the plan. The oldest context is the most valuable and the most compressed. Pin it, re-inject it, and remove it from the policy entirely.
Related reading
The compounding horizon: the arithmetic underneath this · Agent memory: what to store and where · Four kinds of memory · Memory needs forgetting · Loop infrastructure
The simulation is a model with stated parameters, not a measurement of any shipping system. Its arithmetic — fk, the compaction counts, and every figure in the tables — was verified independently before publication and is reproducible in a few lines of JavaScript.