5.1 Managing Conversation Context

Domain 5 is about reliability — making agents behave correctly over the long haul. Task Statement 5.1 starts with a problem every long conversation hits: the context window fills up. Recall from Domain 1 that the API is stateless, so every request carries the full history — and as a customer-support chat or a multi-hour session grows, that history gets large. The instinct is to SUMMARIZE older parts to save room. And that instinct, applied carelessly, quietly destroys the very details the agent needs.

Here's the danger, made concrete. Early in a support chat the customer says: '$247.83 was charged for order #8891 on March 3rd.' Summarize that history and it becomes 'the customer wants a refund for a recent order.' The exact amount, the order number, the date — gone. Later, when the agent needs to process that refund, it no longer knows the amount or which order. Progressive summarization is like turning a detailed receipt into the note 'bought some stuff' — fine for the gist, useless when you need the specifics.

This lesson is about managing context so the critical facts SURVIVE. The central technique is elegant — pull the hard facts OUT of the summarizable history into a protected block — and there's a second effect (where in a long input the model actually pays attention) that shapes how you arrange things. Let's build both up.

Here is the single most important pattern in this lesson. Instead of trusting summarization to preserve the important details, you EXTRACT the transactional facts — customer ID, order numbers, amounts, dates, statuses — into a structured 'case facts' block, and you include that block in EVERY prompt, OUTSIDE the summarized history, where it is NEVER summarized. The history can be condensed freely to save space; the case facts ride alongside it, always intact, always exact.

Think of it as a sticky note on the case file. The long conversation is the file — you can skim, summarize, and compress it. But the sticky note on the front always shows the essentials: customer ID, order #8891, $247.83, charged March 3rd, status: disputed. No matter how much the file is condensed, the sticky note is untouched, so the agent never loses the facts it needs to act. This pattern resolves the tension from Domain 1.1: the API is stateless and you want to trim history to save tokens, but trimming would lose facts — so you protect the facts separately and trim the rest freely.

For multi-issue sessions (a customer with several problems at once), the same idea scales: extract each issue's structured data — order IDs, amounts, statuses — into a separate context layer so none of them gets blurred together during summarization. The principle is constant: identify the facts that must survive, and give them a home outside the part you compress.

A second effect shapes how you ARRANGE a long input: 'lost in the middle.' Models reliably attend to information at the BEGINNING and the END of a long input, but are more likely to overlook things buried in the MIDDLE. It's like a long meeting — people remember how it opened and how it closed, but the bit in the middle blurs. So WHERE you place information matters: put key findings and the case-facts block at the START, use explicit section headers and clear boundaries so important content stands out, and don't bury something critical in the middle of a wall of text.

The third practice attacks bloat at the source: tool-result trimming. Tool outputs accumulate in context and consume tokens out of all proportion to their relevance — an order lookup might return 40+ fields when only 5 matter for a return. Trim each tool result down to the relevant fields BEFORE it enters the conversation history, rather than letting the full payload pile up. This keeps the context lean so the facts that matter aren't crowded out — and it pairs naturally with the case-facts block (extract what matters, discard the rest).

The 5.1 traps test whether you protect critical facts rather than trusting summarization, and whether you account for position effects and tool bloat.

• •Trusting summarization. ✗ Assuming progressive summarization safely preserves details. ✓ It destroys transactional specifics — use a persistent case-facts block.
• •Prompt reminders for position. ✗ Telling the model 'pay attention to everything' to fix lost-in-the-middle. ✓ Use STRUCTURE — front-load key info, add section headers.
• •Keeping full tool results. ✗ Letting 40-field tool payloads accumulate in history. ✓ Trim to the relevant fields before they enter context.
• •Selective truncation that loses facts. ✗ Truncating history in a way that drops the amounts/dates. ✓ Protect facts in the case-facts block, then trim the rest.

You now know why summarization loses critical facts, the persistent case-facts block, the lost-in-the-middle effect, and tool-result trimming. The exercise has you build the case-facts pattern and feel how it survives aggressive summarization.

Protecting facts keeps a long conversation reliable. The next lesson, 5.2, turns to a different reliability decision: when an agent should resolve a request itself versus escalate it to a human.