Summarization Preserves the Story and Silently Drops the Facts

Long conversations outgrow the window that holds them. A session that runs for hours, an agent that works a task across dozens of turns, a support thread that keeps accumulating, all of them eventually carry more history than the model can take in at once. The standard answer is to compress the older part of that history into a shorter narrative and keep going. It works. The compressed version reads cleanly, the relationships between ideas survive, and the model continues responding as if nothing changed.

What does not survive is the exact detail. The specific threshold a user set, the identifier tied to their account, the name of the tool that was chosen, the number that a downstream branch depends on. Those get compressed away, and they get compressed away without a trace. This is the failure mode behind a large share of long-session unreliability, and it is not a flaw in any particular summarizer that a better one would fix. It is structural. The operation that makes a summary readable is the same operation that removes the facts. You cannot tune your way out of it. You have to design around it.

A summary is optimized for coherence, not exactness

Compression forces a choice about what to keep, and a summarizer resolves that choice in favor of meaning. Its objective is a shorter passage that still reads as a faithful account of the longer one, and faithfulness there is measured in narrative terms: does the arc survive, do the relationships between ideas hold, can the model continue from this and stay coherent. On that objective the summary succeeds. The result is fluent, and it preserves the shape of the conversation.

Exact values contribute almost nothing to that objective, which is exactly why they are the first thing spent. An account identifier, a rate limit of a particular number, a version string, these carry their meaning by identity rather than by narrative role. To a process optimizing for a coherent retelling, an opaque string is close to noise. It occupies tokens, it does not advance the story, and dropping it costs nothing that the objective can see. The same logic that makes a summary compact makes it discard precisely the high-entropy, low-redundancy detail that carries no narrative weight and all of the operational weight. The passage reads more smoothly in precise measure as it grows less exact, and those two moves are not independent effects. Specificity is what smoothness is purchased with.

This reframes the problem in a way that matters for how you respond to it. Fact loss is not the summarizer making a mistake about importance. It is the summarizer succeeding at the job it was given, which was to preserve meaning under a size constraint. The facts you care about are the ones whose meaning does not live in the narrative, so a process that preserves the narrative has no reason to keep them. Expecting a better prompt or a stronger model to hold onto them is expecting compression to stop compressing. The information you most need to survive is, by its nature, the information a summarizer has the least reason to protect.

Four kinds of fact go first

The vulnerability is not uniform, and knowing which categories degrade first tells you where the risk concentrates. Four recur across essentially every long session.

Identifiers go earliest. The token that names an account, the number stamped on a support case, the string that pins a build, the opaque handle for a session. They look like arbitrary strings to a summarizer because that is what they are, and arbitrary strings have no narrative function to justify their tokens. They are also the values that application logic keys on most directly, so the gap between how a summarizer weights them and how your system depends on them is at its widest here.

Numeric limits follow. A token budget, a ceiling on requests per minute, the count of retries allowed before a call is abandoned, a hard cap on spend. A summary reliably preserves that a limit was discussed while discarding the digits, because the fact that a constraint exists is narratively meaningful and its exact value is not. The model is then unable to tell a budget of eight from a budget of eight thousand, and it will not signal that the distinction was lost. It answers with whatever it reconstructs, confidently.

Named entities generalize or vanish. The specific dataset, the particular service, the exact tool, get softened into a role or a category, because a summary preserves relationships between kinds of things rather than the identity of any one instance. The conversation still reads as being about a tool and a dataset. Which tool and which dataset is what has gone.

Decisions erode into direction. A committed choice, made explicitly several turns back, gets absorbed into a loose sense of the general direction things had taken rather than kept as a settled constraint. The distinction between a matter still under discussion and one already settled is exactly the kind of thing a narrative summary blurs: compressed into prose, an open question and a closed one look identical.

The unifying property is worth stating directly, because it is what lets you recognize a fifth or sixth category on your own: a fact is vulnerable in proportion to how much of its meaning lives in its exactness rather than in its role in the story. That is the axis compression works along, and it predicts what will be gone before you ever inspect a summary.

Nothing signals what the summary dropped

The categories describe what disappears. The property that makes it dangerous is that the disappearance is silent. A summarizer does not annotate what it compressed. It does not return a list of values it judged unimportant. It produces a clean, coherent passage and hands it forward, and the model continues from that passage as though the full history were still present. There is no error, no warning, no gap in the output where a missing fact would show. The system behaves exactly as it does when nothing is wrong, which is what makes the failure so expensive to diagnose after the fact.

The symptoms surface later and at a distance from the cause. A constraint a user stated early stops being applied, not with an announcement that it was forgotten but by simply no longer shaping the output. A value the user provided gets quietly replaced by a plausible substitute, stated with the same confidence as everything else and wrong. A choice that was settled gets reopened as if still live, and the model starts re-evaluating an option the user already ruled out. Each of these reads, in the moment, like a reasoning error or a model that is being inconsistent. All of them trace to the same root: a fact that was compressed out of the history before anything durable held onto it, so the model is now reasoning correctly over a record that is missing a piece it does not know is missing.

The absence of a signal is the core of the problem, not an incidental property of it. A failure that announces itself gives you something to act on the moment it happens. Silent fact loss gives you nothing to act on until the damage is already sitting in the output. It degrades the answer continuously and invisibly, and by the time its effects are visible, the fact that would explain them is already gone from the context you would inspect to find it.

Each pass compresses the previous summary

Fact loss in a single compression is a bounded problem. What makes it a long-session problem is that the passes compound. The second summarization does not run against the original turns. It runs against the output of the first summarization, a text that is already lossy. The third runs against the second. Each pass inherits a record that has already had detail removed and removes more, and it does so with less raw material to work from than the pass before it had.

The consequence is that loss accelerates rather than accumulating linearly. A fact stated plainly at an early turn is not simply less likely to survive as the session grows. It faces a compounding filter, thinned at every pass, so its probability of surviving decays faster than the number of passes alone would suggest. A constraint that was unambiguous near the start of a session can be entirely absent well before the session ends, and no single pass was careless. Each merely had a little less to preserve than its predecessor, and the erosion multiplied.

This is why a long conversation is not just a longer version of a short one. It is qualitatively different. A short session runs on history that is at most lightly compressed, close to the raw record. A long session runs on a summary of a summary of a summary, a record several steps removed from what was actually said. Reliability that holds for the first case can degrade steadily through the second, and a system that was tested on short interactions can fail on long ones in ways the short tests could never have surfaced. The behavior changes as the history compounds, and it has to be designed for on its own terms.

Facts and narrative need different custody

If the loss is structural, the response has to be structural too. It cannot be a better summarizer, because a better summarizer is still a summarizer. It has to be a change in what the summarizer is allowed to hold on its own.

The move that works is to stop asking one lossy process to hold two kinds of information with opposite requirements. The narrative wants to be compressed; that is what keeps the session inside its window, and compression serves it well. The facts want to be preserved exactly; compression is actively hostile to them. Handing both to the same operation guarantees that protecting one damages the other. So you separate them. You pull the facts out of the raw history before the compressor ever sees it, write them into a durable region that the summarization pass does not touch, and let the summarizer compress the narrative as aggressively as it likes. Order matters here and it is the whole trick: the extraction has to happen before the compression, so that by the time the summarizer runs, it is no longer the only thing holding anything that needs to survive exactly. It can flatten the story freely, because the facts are already somewhere it cannot reach.

That reordering is the entire principle, and it is nearly free once the extraction step exists. It converts fact loss from an inevitable side effect of compression into a design decision about what to extract and where to keep it. What the four vulnerable categories give you is the specification for that extraction: they are the checklist of what to pull out first, because they are exactly what the summarizer will otherwise discard. The mechanics of the durable store itself, how facts are structured, how conflicting values are reconciled, how the region is kept from growing without bound, and how the model is made to actually consult it, are a substantial design problem in their own right, and a real one. But they all sit downstream of the single decision that breaks the loss cycle: extract before you compress, and give facts a custody the compressor does not share.

When to let the summary lose facts

The discipline has a boundary, and treating it as unconditional is its own mistake. Lossy summarization is not a defect to be eliminated everywhere. It is the correct behavior for the narrative, and there are whole classes of interaction where it is the correct behavior for the entire history.

The failure only bites when something downstream depends on an exact value. A conversation that is genuinely narrative, an open-ended exploration, a discussion whose worth is in its arc rather than in any specific figure it produced, loses nothing that matters when it is compressed to its gist. There is no identifier a later branch keys on, no threshold a computation reads, no committed decision that constrains a future step. Extracting facts from such a session would be effort spent protecting values that nothing consumes, and the extracted store would be pure overhead. The question that decides whether extraction earns its place is not how long the session is. It is whether the correctness of a later step depends on a value stated exactly in an earlier one.

Extraction also is not free of risk, and pretending otherwise oversells it. An extraction step can pull the wrong value, or miss one, or capture a number attached to the wrong entity. It moves the point of failure rather than removing failure from the system. The reason it is still the right move where facts matter is not that it is infallible. It is that its failures are inspectable in a way that silent summarization loss is not. An extracted store is a concrete artifact you can validate against the source, check for the wrong type or the impossible value, and correct. A fact that dissolved into a summary offers no such surface. You are trading an invisible, unrecoverable failure mode for a visible, checkable one, which is a good trade precisely because it makes the remaining failures ones you can actually catch.

The other boundary is over-extraction. Pulling everything out of every turn does not preserve facts, it rebuilds the bloat the compression was there to relieve, and a durable store that grows without discipline reintroduces the exact window pressure that started the problem. Extraction is selective by design. The four categories are the discipline that keeps it selective, a specification for what to protect, not a license to protect everything.

The loss is optional even though the compression is not

Compression is not negotiable. A conversation that outgrows its window has to give something back, and turning older turns into a shorter narrative is a reasonable way to give it. The loss of facts, though, is not part of that bargain. It only looks inevitable because the default arrangement asks a single lossy process to hold both the story and the values, and under that arrangement the values always lose. Change the arrangement and the inevitability goes with it.

What that requires is recognizing that a summarizer is aligned against the facts by construction, not by accident, and that no amount of prompting turns a process built to compress meaning into one that preserves exact detail. The facts survive when they are lifted out of the compressor’s reach before it runs, and the categories that go first tell you exactly what to lift. Get that ordering right and a summary is free to do the one thing it is good at, which is keeping the story readable, while the facts your system actually runs on are held somewhere that compression was never allowed to touch.