Lesson 1 of 4 in Context Management & Reliability

5.1 · Context window fundamentals

Long contexts degrade reasoning even below the hard token limit. This lesson covers the 'lost in the middle' effect, the priority order for what stays in context, compaction strategies, and the 'case facts' pattern that protects transactional data from being paraphrased away.

It's a budget, not a bucket

Every token in context costs latency, money, and attention. Long contexts degrade reasoning even below the hard limit. Filling the window because you can is not a strategy.

Lost in the middle

The start and end of a long context get more attention than the middle. Documents you buried in the middle of a packed context effectively vanish from the model's reasoning. This is a well-documented failure mode.

Good to know — If a critical fact must be attended to, put it near the top or near the end of the context, not the middle.

Priority order for what stays

System prompt → task instructions → essential reference → working memory (recent tool results) → optional retrieved context → older turns. Cut from the bottom under pressure. Never truncate the top.

Compaction strategies

Summarize older turns into a compact recap. Drop completed subtasks entirely. Persist long-lived facts to external memory (a database, a scratchpad file) and re-fetch when needed. Trim verbose tool outputs at the source rather than after the fact.

Every 20 turns: summarize the last 15 into 500 tokens, keep the most recent 5 verbatim.

The 'case facts' pattern — for transactional data

Progressive summarization is dangerous when the conversation contains transactional data (amounts, dates, order IDs, customer identifiers). Paraphrase drift turns '$1,247.83 refund on order #A-4482 dated Jan 15' into 'a small refund on a recent order' — technically true, operationally useless. The fix: extract transactional specifics into a persistent 'case facts' block, include it verbatim in every prompt, and NEVER let it be summarized.

Good to know — Case facts are exam bait. If a scenario mentions transactional data + long conversations + progressive summarization, the answer almost always involves this pattern.
# Every prompt to the agent includes:
<case_facts>
  Order ID: A-4482
  Order date: 2026-01-15
  Refund requested: $1,247.83 CAD
  Customer: [email protected]
  Ticket ID: TKT-9921
</case_facts>

<conversation_summary>
  [older turns can be summarized here safely]
</conversation_summary>

<recent_turns>
  [last N verbatim]
</recent_turns>

Takeaways

  • Context is a budget; long context degrades reasoning
  • Lost in the middle: start and end get most attention
  • Priority order: system > task > reference > working > optional
  • Compact aggressively; persist externally

Exam traps

Filling the context because the limit allows it
Long contexts degrade reasoning. Just because 200K tokens fit doesn't mean you should send 200K tokens.
Burying critical facts in the middle of a long context
The middle gets less attention than the ends. Put critical facts at the top or the bottom.
Using progressive summarization on transactional data
Amounts, dates, and order IDs get paraphrased into vague summaries. Use a persistent 'case facts' block for transactional data — never let it be summarized.

Practice scenario

A long-running customer support conversation about a refund starts producing wrong dollar amounts around turn 30. Investigation shows progressive summarization has paraphrased '$1,247.83 refund on order A-4482' into 'a small refund.' What's the correct architectural fix?

Next →