Context compaction is lossy compression — choose your loss function

Every context compaction strategy is a lossy compressor. Summarisation, truncation, tool-result clearing, selective retention — each one throws information away, and the only real design decision is which information you have agreed to lose. Most teams never make that decision explicitly. They adopt whatever compaction their framework ships, watch the agent grow vague fifty tool calls into a task, and conclude that models can't handle long horizons. The model didn't fail; an unexamined loss function did.

The benchmark evidence for this is unusually clean. AMA-Bench decomposes agent memory into four capabilities — recall, causal inference, state updating, state abstraction — and different compressors fail different capabilities. MemoryBank-style lossy summarisation drops 41.3% of needle information when applied to agent trajectories. HippoRAG2's similarity retrieval loses 43.2% end to end. Neither result says compression is bad. It says these compressors carry loss functions tuned for human dialogue: summarisation preserves gist and discards exact identifiers; embedding similarity preserves topical relatedness and discards causal structure. Agent trajectories are machine-generated, information-dense, and causally grounded — so those are precisely the wrong things to lose. The same benchmark found that scaling the base model from 8B to 32B moved scores by 0.038 while memory architecture choices spanned 0.45. What you choose to lose matters more than how smart the model reading the survivors is.

Loss functions you can actually choose

The compaction spectrum makes the choice concrete. At the light end sits tool-result clearing: drop raw observations once the agent has acted on them, keep the decisions. Its loss function is "raw evidence is disposable after use" — often true, occasionally catastrophic. From there the techniques escalate through layered pipelines — tool-result budgets, message snipping, targeted microcompaction, conversation collapse, and finally a full auto-compact fork of the conversation — each layer a progressively more aggressive compressor with a progressively broader class of casualties. LLMLingua's budget controller is the pattern stated in code: allocate near-lossless treatment to instructions, moderate compression to few-shot examples, aggressive compression to retrieved documents. And the ratio itself is a dial with known behaviour — around 2–4× compression costs under 5% quality; push toward 20× and the degradation is significant. None of these is the right compressor. Each is right for a specific answer to "what can this task afford to forget?"

What production agent runtimes have since made explicit is that these layers fire earlier and more often than teams assume. A harness advertising a 200K context window typically operates in a 60–80K effective envelope, with auto-compaction triggered around a default threshold — roughly 100K in current SDKs, holding back only a ~13K buffer before the hard limit. Both numbers are configuration, which means both are parameters you own, not physics: where the compressor fires is as much a loss-function decision as what it discards. And the newest runtime primitive is the most honest one — a pre-compaction hook that lets you inject the state the summarizer must preserve, file paths, the current plan, user constraints, before the compressor runs. That hook is the loss function made executable: the runtime asking you, in code, what you refuse to lose. The same declaration now extends across time, too — production memory stacks attach TTL tiers and refresh-on-read decay to what survives compaction, which is the loss function scheduled: what you keep today, you still choose to forget on a calendar.

So answer it per task. A coding agent lives on exact identifiers and current file state — recall and state updating — which makes summarisation the wrong compressor; keep a structured scratchpad of decisions and clear stale tool output instead. A research agent lives on causal chains across sources — which makes blunt truncation the wrong compressor; summarise aggressively but preserve claim-to-source links. Active Context Compression ("Focus") pushes the decision into the loop itself: the agent prunes its own dead ends mid-task, producing a sawtooth context that grows during exploration and collapses during consolidation, cutting tokens 22.7% at accuracy parity. That number isn't magic — it's what happens when the pruning decision is made task-aware rather than at a fixed threshold.

When not to compress

The honest counter-case: compression itself has a cost, and sometimes it doesn't pay. The Focus paper's own pylint task is the counterexample — compression overhead ran to +110%, the cognitive tax of generating summaries exceeding everything saved. Short tasks, cheap long-context models, or workloads that finish before the window fills are all better served by append-only and a hard truncation at the end. And the ground-truth paradox — generated summaries sometimes outperforming golden human ones — is a reminder that loss can be signal-improving denoising, not just damage. The argument is not "compress more" or "compress less."

It's this: write the loss function down. "This agent may lose raw tool output and exploratory dead ends; it must never lose file paths, user constraints, or the causal chain behind the current plan." One sentence like that, decided before you pick a mechanism — and wired into the pre-compaction hook, where the runtime will actually enforce it — converts compaction from a slow silent failure into an engineering decision you can review — the same way a schema converts data loss from an accident into a choice.