Preserving critical context in long interactions

What you’ll be able to do

• Extract amounts, dates, order numbers, and statuses into a persistent case-facts block kept outside summarized history
• Trim verbose tool results to the fields the task needs before they accumulate in context
• Order aggregated inputs to counter the lost-in-the-middle effect: key findings first, detail under explicit headers
• Have upstream agents and subagents return structured data with metadata instead of verbose prose and reasoning

What you need to know

Progressive summarization loses exactly the wrong things

When a conversation runs long, the common move is to summarize older turns so the history fits. Summaries are good at keeping the gist ("customer is unhappy about a late order and wants a refund") and bad at keeping the specifics: the refund was $247.18, not "around $250"; the order was placed on March 3, which matters for a 30-day return window; the customer said they expected the replacement before Friday. Numbers, percentages, dates, and customer-stated expectations are the details most likely to be rounded off or dropped, and they're usually the ones the next action depends on.

The fix is to stop asking the summary to carry them. Extract transactional facts into a persistent "case facts" block that's included in every prompt, separate from the summarized history. The history can be compressed as aggressively as needed; the facts block is never summarized, only updated.

In a multi-issue session the same idea becomes a separate context layer of structured issue data, one entry per issue with its order ID, amount, and status, so that resolving issue 2 doesn't blur the details of issue 1.

Tool results eat context out of proportion to their value

Every tool result you append stays in the conversation and is re-sent on every later turn. An order-lookup tool might return 40+ fields (warehouse codes, internal flags, full address history) when a return decision needs five: order ID, items, purchase date, delivery status, amount paid. A few lookups like that and most of the context is noise, which costs tokens and makes the relevant fields harder for the model to find.

Trim tool output to the relevant fields before it's appended to the history, not after it has piled up. This can happen in the tool itself, in a post-processing step in your loop, or in a PostToolUse hook that intercepts tool results before the model sees them. The principle is the same: what goes into context should be what the task needs.

The “lost in the middle” effect

Models reliably use information at the beginning and end of a long input, but can miss findings buried in the middle. This matters most when you aggregate many results into one prompt, such as a coordinator passing ten subagent reports to a synthesis step. If the critical finding is report six of ten, it's at risk.

• Put a key-findings summary at the beginning of the aggregated input, so the most important points sit where attention is strongest.
• Organize the detail with explicit section headers (one per source or subtask), so the model can locate specific results instead of scanning an undifferentiated block.

Upstream agents should hand over data, not narration

When a downstream agent has a limited context budget, verbose upstream output is the problem to fix at the source. Modify upstream agents to return structured data (key facts, citations, relevance scores) instead of full content and the reasoning chain that produced it. The downstream agent needs the conclusions and their support, not the path taken to reach them.

That structured output should also carry metadata: dates, source locations, and methodological context. A synthesis step can't tell whether two figures conflict or just come from different years, or how much weight a finding deserves, if the subagent stripped that information out. (Lessons 5.3 and 5.6 build on this.)

Send the whole conversation every time

The Messages API is stateless: each request carries the conversation the model will see. To keep a conversation coherent, send the complete conversation history on every subsequent request, with prior user turns, assistant turns, and tool results in order. Dropping earlier turns to save tokens makes the model contradict itself or re-ask questions it already has answers to. When history must shrink, shrink it deliberately: summarize old turns while the case-facts block keeps the specifics intact.

Key concept

Don’t trust a summary to carry facts that have to stay exact. Pin transactional facts in a case-facts block outside the summarized history, trim tool output to the fields that matter before it accumulates, and put key findings at the start of long inputs.

When a scenario describes an agent that "forgets" an amount, misstates a date, or ignores a finding that was present in its input, ask where that fact lived: inside a lossy summary, inside an untrimmed tool dump, or in the middle of a long aggregated block.

Practice scenario

Build exercise — Add a case-facts layer to a long-running agent

Intermediate · 30 min

What you’ll learn

• Separating durable transactional facts from compressible conversation history
• Trimming tool results to relevant fields before they enter context
• Structuring aggregated inputs so position effects don’t hide findings

1. Pick a multi-turn agent (real or sketched) and list every fact a later turn depends on: IDs, amounts, dates, statuses, customer-stated expectations. Build a structured case-facts block for them, one entry per issue, and include it in every request outside the history.

   • Why: Facts that must stay exact shouldn’t depend on a summarization step that rounds and paraphrases.
   • You should see: A compact block that stays the same size as history grows, and that still shows exact values after older turns are summarized.

2. For the agent’s most verbose tool, write a filter that keeps only the fields the task uses, and apply it before the result is appended to the conversation.

   • Why: Untrimmed results are re-sent on every later turn and dilute the relevant fields.
   • You should see: Tool results shrinking from dozens of fields to a handful, with no change in the agent’s decisions.

3. Take a prompt that aggregates several sub-results and restructure it: a key-findings summary first, then each result under its own explicit header, with dates and source locations kept.

   • Why: Findings in the middle of long inputs are the ones most likely to be missed.
   • You should see: A finding that was placed in the middle and previously missed now showing up in the output.

Exam traps

Relying on progressive summarization to carry exact amounts, dates, and customer-stated expectations

Summaries keep the gist and blur the specifics. Keep transactional facts in a persistent case-facts block that isn’t summarized.

Appending full tool responses to history when only a handful of fields are relevant

Every appended field is re-sent on every later turn. Trim to the relevant fields before results accumulate.

Burying the most important findings in the middle of a long aggregated input

Models attend most reliably to the beginning and end. Lead with a key-findings summary and use explicit section headers for detail.

Sending only the latest user message instead of the complete conversation history

Each request carries the conversation the model sees. Without the full history it loses coherence and repeats itself.

Letting subagents return verbose reasoning chains to a downstream agent with a tight context budget

Change the upstream agent to return structured data (key facts, citations, relevance scores) instead.

Dropping dates and source locations from subagent outputs, leaving the synthesizer to guess

Downstream synthesis needs metadata to weigh and reconcile findings. Require it in the structured output.

Sources

• Claude Developer Platform Docs
• Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)