An agent runs out of context window space. Something has to go. It looks at its conversation history, its tool results, its observations, and makes a choice: keep the user’s intent, drop the intermediate reasoning. Keep the API response, drop the request parameters. Keep the conclusion, drop the failed paths.
This is the compression paradox. The information an agent needs to decide what to drop is the information that gets dropped by the decision.
The Impossible Choice
Here is the structure of the problem. An agent compresses its context by running a summarizer over its own history. The summarizer produces a shorter version — a summary, a digest, a set of key facts. But the summarizer itself is an agent process. It reads the context and decides what matters. Its decisions depend on understanding what the context contains. Once the compression is done, that understanding is gone. Only the output remains.
This is structural, not technical. Better summarizers, better prompts, better rules — none of these change the constraint. A summarizer cannot compress what it does not understand, and it cannot preserve understanding through compression.
A human summarizing a meeting has an advantage we forget to model. The person does not just produce shorter text. They update their internal representation. The summary and the understanding are separate — the person still remembers what was uncertain, what was implied. An agent replaces both the text and the understanding with a single artifact. The understanding is the first casualty.
What Gets Dropped First
The pattern across compression failures is not random. Three categories of information consistently disappear:
Provenance context. Where did a fact come from? Was it in the initial prompt, a tool response, or inferred from intermediate steps? After compression, a fact is just a fact. The chain of custody is gone. This matters because a fact extracted from a URL that may have changed since retrieval is not the same as a fact stated by the user in their first message. They look identical after compression. They behave very differently when the agent acts on them later.
Constraint context. What conditions shaped the original answer? Was there a budget limit, a version requirement, a user preference stated casually? Compression favors declarative facts over conditional ones. “The API returns JSON” survives. “Unless you hit the v1 endpoint, which returns XML for backward compatibility” does not. The second half is longer, more conditional, harder to compress. It is also more likely to be the part that causes a failure.
Uncertainty context. What was the agent unsure about? Compression produces confidence as a side effect. When you turn “I think the database is Postgres but the error message mentions MySQL” into “Database: Postgres,” you have not just shortened the text. You have manufactured certainty. The uncertainty was not noise. It was a signal that the agent should check, ask, or hedge. Compression treats it as redundancy and removes it.
The Self-Blind Spot
The deeper problem is that compression is invisible to the compressed agent. After context is summarized, the agent reads the summary as if it were original context. There is no marker saying “this was inferred from compressed data” or “this fact lost its source attribution during summarization.” The summary is not labeled as lossy. It looks like truth.
This creates a specific failure mode. An agent acts on compressed context, produces a confident output, and has no mechanism to flag that its confidence is built on a foundation that has already been degraded. The degradation happened upstream, during compression, and the agent downstream has no telemetry for it.
A debugging session illustrates this. An agent was asked to deploy a configuration change. It had previously compressed its context, dropping a detail about a feature flag being disabled in staging. The compressed context said “deploy to staging” without the flag caveat. The agent deployed. The deployment failed. The post-mortem showed the agent “ignored” the flag detail. But the agent did not ignore anything. The detail was not in its context. It had been compressed away hours earlier by a summarizer that decided the flag status was less important than the deployment target.
The agent was blamed for a failure that happened during compression. The compression was not blamed because it worked as designed — it produced a shorter context.
A Way Forward
The paradox does not have a solution in the sense of a compressor that never loses information. What it needs is a compressor that is honest about what it loses.
A loss ledger. Every compression event produces two artifacts: the compressed context and a record of what was removed. The ledger tracks not just the text that was dropped, but the category of loss: provenance, constraint, uncertainty, temporal validity. This is not about storing everything forever. It is about making the loss visible so the downstream agent can calibrate its confidence.
Confidence calibration. When an agent reads compressed context, it should know how many compression events the context survived. One compression is usually fine. Three compressions in a row is a signal to flag uncertainty, ask the user, or fetch fresh data. The number of compression cycles becomes a first-class property of the context, not a hidden implementation detail.
Selective preservation. Not all context compresses the same way. Provenance chains, user preferences, and tool outputs each need different strategies. Provenance gets a hash. Constraints get a condition. Uncertainty gets a confidence score. Temporal data gets a timestamp.
External invariants. File hashes, rate limits, API version numbers — these can be re-derived, so they do not need to live in context. The strategy should distinguish between what the agent thinks (compressible) and what the agent can check (verifiable).
The Honest Compressor
The right question is not “how do we compress better?” It is “how do we compress honestly?”
A better compressor is still a compressor. It still loses information. The only difference is that it loses different information, or loses it more elegantly. The structural problem remains: something that does not understand cannot decide what to forget, and something that does understand loses its understanding when it forgets.
An honest compressor admits the loss. It produces a summary and a receipt. It compresses context and reports what was dropped, why, and what confidence the agent should have in the result. It treats compression not as a lossless optimization but as a lossy transformation with a documented cost.
An agent that does not know what it has forgotten cannot know what it does not know. And an agent that does not know what it does not know is not safe. It is just confident.