Preserve exact facts through every summary

Learning objective

Persist exact amounts, dates, percentages, statuses, and customer expectations in a case-facts block outside lossy summaries.

Core idea

A summary can retain the topic while losing the commitment. “A refund was discussed” says nothing about its amount, deadline, destination, or execution status. Repeatedly summarizing that sentence cannot recover details that an earlier compression removed.

The exam guide calls for a persistent case-facts block included in each prompt outside summarized history. This is an application-owned representation, not a named Messages API feature. Anthropic’s context-engineering guidance supports the underlying pattern: store structured notes outside the context window and pull them back into context when needed.

Separate a compact narrative of what happened from an exact record of what must remain actionable. The summary provides continuity; the record preserves values whose paraphrase would change a decision. See 5.1.1 for history assembly and 5.1.3 for extending this record to several concerns.

How it works

Identify facts that cannot tolerate paraphrase

A support case can depend on several distinct kinds of information. Preserve them with enough qualification to remain meaningful after the original exchange is compressed:

These are illustrative case values, not Anthropic limits or product fields. Define their representation in your application. In particular, do not combine a requested refund, an eligible refund, and a completed refund into one unlabeled amount. They can differ without any source being wrong.

A date also needs meaning. “Friday” might be a customer’s requested deadline, the agent’s promise, or an estimated settlement date returned by a payment system. Preserve which one it is. If the conversation does not resolve a relative date unambiguously, retain the original wording and mark the date unresolved rather than inventing an absolute value.

Customer expectations deserve their own fields because they are not necessarily commitments or policy entitlements. “I need this before my trip” is evidence of the customer’s requirement. It does not establish that the merchant guaranteed delivery before that date.

Persist the record outside summarization

Keep the authoritative case-facts record in application storage separate from the text passed to a summarizer. The request builder reads that record and renders it afresh alongside the managed conversation. In a Messages integration, this rendering becomes supplied content in messages; a heading such as Case facts labels the application data, rather than creating an API parameter.

Do not generate the next exact record solely from the previous narrative summary. Extract values from their original evidence while that evidence is available, then preserve them independently. If a later tool result changes the refund status, update the corresponding status from that result. A failed submission should not turn “approved” into “issued” merely because a summary says the agent processed the case.

The exact record reaches the request builder beside the summary, never through it.

The source should remain identifiable. Preserve whether a value came from the customer, a policy decision, or a tool result. This helps the next response distinguish a request from a verified outcome without reading the whole archive. The record is compact because it excludes narrative detail, not because it collapses these distinctions.

Reintroduce facts at a documented boundary

With the Claude Agent SDK, automatic compaction summarizes earlier history near the context limit. The agent-loop documentation explicitly warns that specific early instructions may not survive. That warning does not state that every transactional value is lost; it establishes why a summary is an unsuitable exactness guarantee.

The SDK also lets you put preservation instructions in a CLAUDE.md section, run a PreCompact hook to archive the transcript, and observe compaction through a stream message with type: "system" and subtype: "compact_boundary". PreCompact is available in both SDKs and receives trigger: "manual" or trigger: "auto". These controls shape, precede, or report summary creation; they do not replace an exact record kept outside the summarizer.

Both the Python and TypeScript SDKs support UserPromptSubmit callbacks through the hooks option. A synchronous callback can read your persisted record and return hookSpecificOutput with hookEventName: "UserPromptSubmit" and additionalContext containing the rendered facts. The hook documentation defines these output keys. systemMessage displays information to the user; it is not the field for delivering facts to the model.

This hook runs at prompt submission, not at every internal tool-following model call. Use it to refresh facts when a customer sends another prompt. In the TypeScript SDK, a synchronous PostToolBatch hook runs once after all tool calls in a batch resolve, before the next model request. It receives the batch in tool_calls and can return hookSpecificOutput with hookEventName: "PostToolBatch" and additionalContext to inject refreshed facts once before that call. The Python SDK does not support this event. In a direct Messages integration, the request builder controls inclusion on every call.

Key distinctions and trade-offs

Persistence versus visibility: Saving a record protects it from summary loss. Including the record in supplied context makes it useful to the next inference. You need both.

Exact facts versus narrative: A narrative explains the dispute and tone; the record carries the values that determine the next action. Asking a summarizer to be more careful is weaker than removing these values from its replacement path.

Expectation versus outcome: A requested collection window, a booked pickup, and a completed pickup describe different states. Preserve their labels instead of giving every statement equal evidential weight.

Fresh injection versus stale accuracy: A perfectly formatted block can still contain obsolete facts. Rendering it repeatedly works only if the application updates it from the relevant source evidence.

Architecture / decision scenario

A customer requests a USD 67.35 refund for order ORD-731, asks for processing by 2026-10-16 and courier pickup after 18 rather than drop-off, and receives approval for a 12% fee waiver. The refund is approved but has not been submitted. After two summary passes, the transcript says only “refund agreed; customer wants it soon.”

Store the order number, exact requested amount and currency, fee rate and waiver decision, dated customer expectation, pickup preference, and execution status in the independent case record. Keep the processing deadline labeled as requested until an agent commitment or system estimate supplies a different basis. Render that record into subsequent Messages requests before answering whether the refund has been issued.

In an SDK implementation, register a synchronous UserPromptSubmit hook that reads the same record and supplies additionalContext. When the submission tool later reports success, update the execution status from its result. In TypeScript, return hookSpecificOutput.additionalContext from PostToolBatch to re-inject the refreshed record before the next model call; both SDKs can refresh it on the next customer prompt through UserPromptSubmit, even after compaction has replaced the early exchange with a summary.

The resulting answer can distinguish “approved” from “submitted” and a customer deadline from a guaranteed settlement date. Increasing the summary length alone would not establish those distinctions as reliably.

Common exam traps

• Preserving only amounts while losing percentages, deadlines, and expectations.
• Treating a customer’s request as an approved promise.
• Reconstructing exact facts from a summary that has already discarded them.
• Updating execution status from the agent’s intent rather than the tool result.
• Saving a record without supplying it to the next call.
• Assuming UserPromptSubmit runs before every internal model request.

What to remember

Keep exact, qualified case values outside lossy summaries and supply them from persisted state. Preserve the distinction between requested, promised, and executed, then refresh the record from evidence at the integration boundary you actually control.

Knowledge check

References

• Anthropic, Effective context engineering for AI agents
• Anthropic, How the agent loop works
• Anthropic, Intercept and control agent behavior with hooks
• Anthropic, Hooks reference
• Anthropic, Claude Certified Architect – Foundations Exam Guide