Keeping Critical Facts Intact in Long Conversations

1.Full history every turn, and what it costs

Every context-management decision starts from one fact: the model keeps no memory between requests. The Messages API is stateless. To keep a conversation coherent, your application sends the whole conversation every time, including earlier user turns, earlier assistant replies, and tool results. If you drop a turn, the model has never seen it. A customer who gave their order number in turn 2 will be asked for it again in turn 9.

message = anthropic.Anthropic().messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello, Claude"},
        {"role": "assistant", "content": "Hello!"},
        {"role": "user", "content": "Can you describe LLMs to me?"},
    ],
)

"Complete" history means each request's input holds everything said so far plus the new user message. The context-windows documentation describes each turn as an input phase that contains all previous conversation history plus the current user message, followed by an output phase whose response becomes part of the input for the next turn. The history includes the assistant's own earlier replies and the tool results in messages, not only what the user typed. The practical rules follow from that. Append every new user message and every assistant response to the list you send next. Never trim turns silently to save tokens, because a missing turn can't be recovered by the model and the conversation stops being coherent. When you do need to shrink the history, use a deliberate mechanism such as compaction or context editing. Even with server-side context editing, your own application keeps the full, unmodified history and keeps sending it.

The history therefore grows with every turn, and all of it counts against the window: the system prompt, every message, every tool result and the tool definitions. A large window does not make this free. The context-windows documentation states that more context isn't automatically better, because accuracy and recall degrade as token count grows. Anthropic's context-engineering guidance calls this an "attention budget": every new token uses some of it. You can't fix the problem by dropping history, since coherence depends on it. You fix it by controlling what goes into the history. The rest of this page covers the places where that control matters most: tool output, summaries, the facts a case depends on, and what subagents hand back.

Sources123

2.Tool results: the biggest source of waste

Tool results grow context faster than anything else, and they are often the least useful part of it. Suppose an order-lookup tool returns 40-odd fields per order, but a return request only needs five of them: order ID, status, amount, purchase date and return eligibility. (These numbers are an illustration, not from the docs.) Each lookup adds all 40 fields to the history, and because the history is re-sent on every request, those tokens are paid for on every later turn too. The docs state the general problem: accumulated tool results consume the window, and long-running agents can run out of context before the task is finished.

There are two places to cut. The first is before the result enters the history. Your own tool handler can map the raw response down to the fields that matter for the task before returning it. Programmatic tool calling does something similar for chains of calls: Claude writes one script that runs in a sandbox, and the intermediate results never enter the conversation history. The second is after a result has served its purpose. Context editing's tool result clearing removes the oldest results once a threshold is crossed. Each one is replaced with placeholder text, and the record of the tool call is kept, so the model knows it made the call and can call the tool again if it needs the data.

Use exclude_tools to protect results you can't afford to lose. If one tool records the facts the whole case depends on, list it there and clearing will never touch it. Clearing also runs on the server, before the prompt reaches Claude. Your application should keep storing the full, unmodified history locally, as before.

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Search for recent developments in AI"}],
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    betas=["context-management-2025-06-27"],
    context_management={"edits": [{"type": " ? "}]},
)

Sources456

3.What progressive summarization loses

Clearing removes tool output. Compaction goes further: it rewrites the whole conversation. When the history nears a threshold, Claude summarizes it and the summary replaces the history. Each later compaction summarizes a summary, which is why the loss is called progressive.

The cookbook says plainly that a compaction summary may drop specific numbers or exact phrasing. Four kinds of detail are most at risk. Numerical values such as amounts and quantities, percentages such as a discount or fee, and dates such as a promised deadline are exact by nature, so a vaguer paraphrase is simply wrong. Customer-stated expectations, such as what the customer said they would do if the issue isn't resolved, are easy to flatten into a neutral description. The examples here are illustrations, not from the docs. "$247.83 refund promised by 14 March, customer said they'd cancel otherwise" can become "customer requested a refund." "A 15% restocking fee was waived" can become "fees were discussed." "Customer expects a reply within two days" can become "customer wants a quick answer." Each version is plausible and each has lost the part the next agent action depends on. Because each compaction summarizes the previous summary, the loss compounds.

Anthropic's guidance warns that aggressive compaction can lose context whose importance only becomes apparent later. The default SDK summary prompt addresses part of this with a "Context to Preserve" section covering user preferences, domain-specific details, and promises made to the user. A custom summary prompt can go further and require exact figures, percentages, dates and the customer's own stated expectations to be copied verbatim. Still, any summary loses something by design, so the facts you can't afford to lose should not depend on the summary at all.

Sources536

4.A case-facts layer outside the summary

The fix is to store transactional facts somewhere summarization can't reach. Pull amounts, dates, order numbers and statuses out as they come up, keep them in a structured "case facts" block, and include that block in every prompt separately from the summarized history. The sources don't use the term "case facts". What they describe is the same pattern under the name structured note-taking: the agent writes notes that persist outside the context window and are read back in later. The memory tool supports this with file-based storage that survives context resets.

Multi-issue sessions need one more step. If a customer raises two problems, a single running narrative merges them, and a later "the amount" could mean either one. Keep one structured record per issue, each with its own ID, amount and status, in its own context layer. That way every reference resolves to exactly one issue.

Sources536

5.Subagents: structured outputs with metadata

Subagents are another way to keep context small. A subagent runs in its own conversation, and the SDK documentation says its intermediate tool calls and results stay inside it while only its final message returns to the parent. That final message is therefore the only channel the coordinator has, so what it contains decides how accurate the downstream synthesis can be. Anthropic's context-engineering guidance says a subagent may use tens of thousands of tokens exploring but should return only a condensed, distilled summary of its work.

Two design rules follow. First, ask for structured findings, not verbose content or reasoning chains. The orchestration example in the docs tells its subagents to finish by calling a report_findings tool and to "Return findings, not narration." When the coordinator has a limited context budget, this keeps its window for synthesis. Second, require metadata with every finding. The multi-agent research post says each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without that, subagents duplicate work, and its example shows why timeframe matters: one subagent explored the 2021 automotive chip crisis while others investigated current 2025 supply chains. The docs don't list required metadata fields, so treat the following as a design recommendation built on those principles. Have each finding carry its date or time period, its source location (URL, document or section), and the method or scope behind it, for example what was searched and what was excluded. With those fields the coordinator can reconcile two figures that differ because they come from different years, cite which source backs which claim, and spot gaps instead of averaging mismatched numbers.

If outputs are large, there is a second option. The research post describes subagents storing their work in an external system and passing lightweight references back to the coordinator. This avoids the information loss of a multi-stage "game of telephone" and the token cost of copying large outputs through the conversation history.

Sources789

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.With a 1M-token window you can keep every tool payload and transcript line, because more context always means better answers.Why is that wrong?

   Recall and accuracy degrade as token count grows, so a bigger window only means more space that needs curating.

   Covered in Full history every turn, and what it costs

2. 2.A good compaction summary keeps exact refund amounts and promised dates, so a separate facts block is redundant.Why is that wrong?

   Summaries keep decisions and the gist but may drop specific numbers and exact wording. Store those facts outside the summarized history.

   Covered in What progressive summarization loses

3. 3.Once server-side context editing clears old tool results, you should delete them from your local history too, to keep the two in sync.Why is that wrong?

   Context editing runs on the server before the prompt reaches Claude. Your client keeps and sends the full, unmodified history.

   Covered in Tool results: the biggest source of waste

4. 4.A subagent should return its full tool output and reasoning chain so the coordinator can check everything itself.Why is that wrong?

   The point of a subagent is to keep detailed exploration in its own context and return only a condensed result, which should be structured and carry the metadata the coordinator needs.

   Covered in Subagents: structured outputs with metadata