A long conversation or agent session accumulates context that eventually has to be managed, not just resent forever — both because the context window has a hard token ceiling and because a very long, undifferentiated context degrades output quality well before it hits that ceiling. Two specific failure modes matter for the exam: the progressive summarisation trap, where repeatedly summarising an already-summarised history compounds information loss until important details are quietly gone; and the lost-in-the-middle effect, where content placed in the middle of a very long context gets weighted less reliably by the model than content near the start or end.
Why progressive summarisation compounds loss
Summarising a conversation once is a reasonable compression step — you trade some detail for a much smaller token footprint, and for most agent tasks the tradeoff is worth it. The trap is doing it repeatedly, using each summary as the input to the next: summary-of-summary-of-summary. Each pass only has access to what the previous summary chose to keep, not the original source material, so anything that got compressed away on pass one can never come back on pass two — there's no mechanism to recover it. Worse, there's no visible failure signal when this happens. The agent doesn't error; it just quietly starts reasoning from a thinner and thinner version of its own history, and the first sign of trouble is often the agent contradicting or forgetting something it correctly established many turns earlier.
Lost-in-the-middle: why position matters
Within a single very long context, content near the beginning and content near the end tend to be attended to more reliably than content buried in the middle — a well-documented pattern across long-context language models generally, not a quirk unique to any one system. The practical implication for prompt and context design: don't assume a fact stated once, early in a long conversation, will carry equal weight forty turns later just because it's technically still present in the context. If something genuinely matters late in a long session — a hard constraint, a corrected fact, a user preference — consider re-stating it near the end of the context (e.g. folding it into a system-reminder-style message just before the final turn) rather than trusting it to still carry full weight from wherever it first appeared.
Trimming stale tool results: the highest-leverage technique
In an agentic loop specifically, tool results — not conversational text — are usually the biggest driver of context growth. A large file read, a verbose API response, or a long search result gets appended to history once and then resent, unchanged, on every subsequent API call, even long after the agent has extracted what it needed and moved on. Deliberately trimming or summarising specifically stale tool results — replacing a large, no-longer-needed result with a short placeholder — is usually the single highest-leverage technique for keeping a long agent session's context under control, and it's more surgical than summarising the whole conversation (which risks the progressive-summarisation trap above if applied repeatedly to the same content).
// After the agent has moved past needing this tool result's full content:
messages[toolResultIndex] = {
...messages[toolResultIndex],
content: [{
type: "tool_result",
tool_use_id: originalToolUseId,
content: "[full file contents omitted - previously read in full, 4,200 tokens]",
}],
};Keep enough of a placeholder that the model still knows the step happened and roughly what it returned — deleting the turn outright can confuse a model reasoning about what it has and hasn't already done.
The prompt-caching interaction
Prompt caching keys off a stable prefix: everything up to a cache_control breakpoint has to match exactly, byte for byte, for a cache hit. Trimming or rewriting a tool result earlier in the message list changes that prefix, which invalidates the cache for every turn from that edit point onward — the next call re-processes (and re-pays for) everything after the edit as an uncached prefix. This is a real cost tradeoff, not just a mechanical detail: aggressive per-turn trimming can save input tokens on one call while quietly destroying cache savings on the next. The practical pattern is to trim in batches at natural checkpoints (e.g. after a phase of the task completes) rather than on every single turn, and to place your cache breakpoint after the stable system prompt/tool-definitions block and before the volatile, frequently-trimmed tail of the conversation.
Common exam distractor
Trimming the oldest messages indiscriminately (a simple sliding window over turns) is a common but imprecise answer — it can just as easily discard a short, still-relevant early instruction while leaving a huge, already-stale tool result sitting untouched several turns later. The exam favours targeting the actual driver of token growth (large stale tool results) over blindly trimming by recency alone.
Key concept
Manage context deliberately, not reflexively: trim large stale tool results specifically rather than summarising the whole conversation repeatedly, restate genuinely important late-session facts near the end rather than trusting mid-context recall, and remember that editing earlier turns has a prompt-caching cost, not just a token-count benefit.