Preserving critical information across long interactions

The context window

Every request includes the instructions, prior turns, and tool results. A model can read only a limited amount of text at once. That limit is the context window, measured in tokens, which are roughly the pieces of words the model reads.

When a conversation outgrows its context window, some information must be removed or condensed. The techniques in this domain help you decide what to keep instead of letting that happen by accident.

What summarization can remove

Progressive summarization reduces the amount of conversation history sent on later turns. It can also make exact details less precise. Amounts may become "a refund," dates may become "recently," and a customer's stated expectation may become "they were unhappy."

Keep facts that must remain exact in a separate structured block that is not summarized.

Extract transactional facts — amounts, dates, order numbers, statuses — into a persistent case facts block included in each prompt, sitting outside the part that gets summarized. For multi-issue sessions, persist the structured issue data in its own context layer.

A case facts block is plain text you assemble and place in the prompt yourself. Nothing here is an API field:

CASE FACTS (re-sent verbatim each turn, never summarized)
order:     A-4417-92
refund:    $86.40, requested 2026-08-03
status:    approved, not yet issued
promised:  "refunded by Friday" (turn 6)

The backend can't restore the last line because it came from the conversation, not from stored order data. Keeping it in the case facts block preserves it when the rest of the conversation is summarized.

Re-querying the backend recovers only what the backend stores. What the customer said they expected, what an earlier turn promised them, and what they have already agreed to exist nowhere but the conversation. If summarization blurs those, no lookup fetches them back.

Lost in the middle

Models process the beginning and end of a long input reliably, and may omit findings from the middle. It's a property of position, not of importance, so a critical finding buried mid-input can simply not surface.

A model may pay less attention to information in the middle of a long input, even when the entire input fits in its context window.

Two mitigations:

• Put key findings at the beginning of aggregated inputs.
• Organize details under clear section headings so the model can locate relevant information more easily.

Tool output also uses context space

Tool results remain in the conversation and use tokens. If an order lookup returns forty fields when only five matter, the other thirty-five fields take up context space without helping the task.

Trim verbose tool output to the relevant fields before it enters context.

Structure what flows between agents

When a downstream agent has a limited context budget, upstream agents should return structured data — key facts, citations, relevance scores — rather than verbose content and reasoning chains.

Telling the receiving agent to skim and discard doesn't save context space. The text already occupies tokens when it arrives. Filter unnecessary material before the sending agent passes it along.

Require subagents to include useful metadata such as dates, source locations, and research methods. The next agent can use those details to verify and combine the findings accurately.

Keep history coherent

Later API requests need enough history to continue the task, but they don't always need every earlier turn word for word. Preserve role ordering and unresolved decisions. Store exact facts in structured state, and remove or summarize material that no longer affects the task.