Your customer support agent tracks complex cases over many turns. On turn 1, a customer states: "My order #44872 for $312 was supposed to arrive on March 14 but it's now March 22 and tracking hasn't updated since the 16th."
By turn 12, after the agent has gathered details, looked up policies, drafted resolution options, and processed two tool calls, the agent's summary reads: "Customer is reporting a delayed shipment from earlier this month."
The financial detail, dates, and order number have been compressed away.
What's the best architectural fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Progressive summarization is one of the major reliability hazards in long-running agentic conversations. Models compress legitimately long histories but tend to lose precise facts (numbers, dates, identifiers) in the process. The architectural fix is to extract critical facts into a structured, persistent block that's included in every prompt — separate from the summarized conversation flow. The summary handles narrative; the case facts block handles precision. This separation gives you both compression and fidelity on what matters.
max_tokens controls output length, not how the agent summarizes context. And even if you somehow disabled all compression, eventually conversations exceed any context window — compression has to happen somewhere.
Asking the model to "never compress numerical details" relies on probabilistic compliance for a property that compression dynamics will violate. The model is summarizing because it's optimizing the use of context — it can't both summarize and preserve every detail.
Larger context windows help, but they don't prevent the lost-in-the-middle effect, and they don't fix the underlying issue: facts that need to be referenced repeatedly across many turns should not be buried in conversation history at all. Architecture beats raw capacity.