Rubric
Contents — domains, guide and mocks

Preserving facts in long conversations

CCAR-F 5.111 min read · checked 21 September 2026

Task statementManage conversation context to preserve critical information across long interactions

What a long-running request is made of

most protected → most disposable

  1. System promptrole, rules, tools — sent with every request
  2. Case facts blockamounts, dates, IDs, commitments — never summarised
  3. Summary of older turnscompaction output — lossy by design
  4. Recent turnskept verbatim
  5. Tool resultstrimmed on arrival, cleared when stale
Protect the top layers; let the bottom layers be summarised or cleared. Everything here counts toward the same context window.

Why long conversations lose things

Every request carries the whole conversation: the system prompt, every message, every tool result and the tool definitions all count toward the context window. As that grows, two separate problems appear. The first is capacity — eventually it will not fit. The second arrives much earlier: the documentation calls it context rot, the tendency for accuracy and recall to degrade as token count grows. Anthropic’s context-engineering guidance describes a model as having a limited attention budget, where every extra token competes for it. A conversation can be well inside the limit and still be too noisy to answer reliably.

The usual response to the capacity problem is summarisation: replace older turns with a shorter account of them. That is necessary, and it is also where critical information disappears. A summary keeps the gist and drops the specifics. “Customer disputes the 3 March charge of $1,240 on card ending 4417 and was promised a callback by Friday” becomes “customer is disputing a charge”. Summarise a summary a few times over a long session and precise values degrade into vague ones — the conversation still reads coherently, which is exactly why nobody notices until the agent gets a number wrong.

Information typeSurvives summarisation?Protect it by
General goal, tone, topicUsuallyNothing special needed
Exact amounts, dates, order or account IDsOften notA structured case facts block
Promises and decisions already madeOften notRecording them as facts when they happen
What the user said they expectRarely verbatimQuoting it into the facts block
Raw tool output from twenty turns agoDoesn’t need toTrimming it, or clearing it once used

Pattern 1: keep a case facts block outside the history

The most dependable technique is also the simplest. Extract the transactional facts into a structured block as they arrive — customer, account, amounts, dates, order numbers, what has been promised, what is still open — and send that block with every request, outside the part of the conversation that gets summarised. The system prompt is a natural home for it, because it is sent separately on every call. Summaries can then be as short as they like: the facts the task depends on are never inside them.

Facts pinned in the system prompt; history compacted server-sidepython
case = {                                   # updated by your code as facts arrive
    "customer_id": "C-88213",
    "disputed_charge": {"amount": "1240.00", "currency": "USD", "date": "2026-03-03"},
    "card_last4": "4417",
    "promised": ["callback by Fri 2026-03-13"],
    "open_questions": ["merchant has not replied"],
}

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model=MODEL,
    max_tokens=2048,
    system=f"{BASE_PROMPT}\n<case_facts>{json.dumps(case)}</case_facts>",
    messages=messages,
    context_management={"edits": [{
        "type": "compact_20260112",
        # Replaces the default summary prompt entirely, so say what to keep.
        "instructions": "Summarise the conversation. Preserve every decision, "
                        "commitment and unresolved question. Do not call tools.",
    }]},
)
messages.append({"role": "assistant", "content": response.content})

Two details in that example matter. Server-side compaction returns a compaction block; you append the whole response as usual, and on later requests the API ignores everything before that block. And the instructions field replaces the default summarisation prompt rather than adding to it — the documentation recommends saying what the summary must retain and telling the model not to call tools during the summary step.

Pattern 2: keep noise out in the first place

Much of what fills a long agent session is tool output. An order lookup might return forty fields when the task needs four; a search might return ten pages when one paragraph matters. Every one of those tokens is carried on every later request. Trim tool results to the fields the task needs before appending them — in your tool handler, or in a post-tool hook if you are on the Agent SDK (hooks are covered in 1.5).

For results that were useful once and are now stale, the API offers context editing. The clear_tool_uses_20250919 strategy clears older tool results once a trigger threshold is passed, keeps the most recent few, and replaces each cleared result with placeholder text so Claude knows something was removed. exclude_tools protects tools whose output must stay. Anthropic’s context-engineering post describes clearing old tool results as one of the lightest-touch ways to reclaim context: once a result has been used, the agent rarely needs the raw version again.

A tool result, before and after trimming

Raw tool resultjson

{
  "order_id": "A-1042",
  "status": "delivered",
  "delivered_at": "2026-03-02",
  "total": "89.00",
  "warehouse": "DC-7",
  "picker_id": "u-5521",
  "carrier_raw": { ...40 lines },
  "audit_log": [ ...120 lines ],
  "marketing_flags": { ... },
  "tax_breakdown": { ... }
}

What the agent receivesjson

{
  "order_id": "A-1042",
  "status": "delivered",
  "delivered_at": "2026-03-02",
  "total": "89.00"
}
The agent only ever needed four fields. The rest would have been re-sent on every turn for the rest of the session.

Pattern 3: put important material where it is read best

Position matters in a long prompt. Anthropic’s long-context guidance is to put long documents at the top and the question or instructions at the end; in their tests, queries at the end improved answer quality by up to 30%, most of all with several documents. Wrap each document in its own tagged block with its source as metadata, and for long-document tasks ask Claude to quote the relevant passages before answering. When you assemble many results for a final step, lead with a short list of the key findings and give each section a clear heading, rather than hoping a detail buried in the middle of a long block is noticed.

Which tool for which problem?

What is going wrong?
  • Exact facts get lost
    Case facts blockoutside summarised history
  • Old tool output piling up
    Trim, then clearclear_tool_uses_… + exclude_tools
  • Whole conversation too long
    Compactionwith instructions on what to keep
  • Must survive a new session
    Memory or notes filememory tool, NOTES.md, CLAUDE.md

Memory outside the window

Some state must outlive the context window altogether — a multi-day task, an agent that may be interrupted. Anthropic’s guidance calls this structured note-taking: the agent writes progress to a file outside the conversation and reads it back later. The API’s memory tool formalises it: Claude issues file commands against a /memories directory that your application stores, and when used with context editing Claude is warned before results are cleared so it can save what it needs first. The trade-off is that memory is only as good as what the agent chose to write, so critical facts should still be written deterministically by your code rather than left to the model’s judgement.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Relying on progressive summarisation to keep amounts, dates and IDsExtract them into a structured case facts block sent with every request.
Appending full tool responses to historyTrim to the fields the task needs before they enter context; clear stale results.
Solving forgetfulness with a bigger context windowCurate context — a larger window delays overflow but not context rot.
Custom compaction instructions that only say “summarise”Name what must be retained; the instructions replace the default prompt.
Burying the key question or finding in the middle of long inputDocuments first, question last, key findings summarised up front with headings.

You should now be able to

  • Identify which information types are lost by summarisation and protect them explicitly.
  • Design a case facts block that persists outside summarised conversation history.
  • Trim verbose tool output and configure tool result clearing for long agent runs.
  • Choose between compaction, context editing, memory and /clear for a given problem.
  • Order long inputs so documents come first and the query and key findings are easy to find.
  • Say what survives compaction in Claude Code and where lasting rules should live.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    An insurance claims assistant handles conversations that often exceed 80 turns. Late in long conversations it sometimes quotes the wrong policy number or claim amount, even though both were stated clearly near the start. The team uses automatic summarisation when context gets large.

    Which change most directly fixes the errors?

    1. AMove to a model with a larger context window so summarisation happens less often.
    2. BAdd “always remember policy numbers and amounts” to the system prompt.
    3. CExtract key facts into a structured block sent with every request, outside summarised history.
    4. DSummarise more often so each summary covers fewer turns and is more accurate.
    Show answer and reasoning
    1. AIncorrect. It postpones summarisation but the lossy step still happens eventually, and a longer context degrades recall anyway.
    2. BIncorrect. The model cannot remember what the summary has already removed; the instruction does not change what is in context.
    3. CCorrect. The exact values never pass through the summary, so compression cannot degrade them.
    4. DIncorrect. More frequent summarisation means more summary-of-summary passes, which tends to lose more detail, not less.

  2. Question 2

    A research agent calls a search tool and a document-fetch tool dozens of times per task. Each fetch returns an entire web page. By mid-task, answers are slower and the agent starts contradicting findings it made earlier.

    Which two changes best address this? (Select 2.)

    1. ATrim fetched pages to the relevant passages, with their source, before appending them.
    2. BEnable tool result clearing so older fetch results are replaced once a threshold is passed.
    3. CRaise max_tokens so the agent has room to reconcile the earlier findings.
    4. DMove the full search results into the system prompt so they are never cleared.
    5. EInstruct the agent to reread all earlier results before each answer.
    Show answer and reasoning
    1. ACorrect. Keeps noise out of context from the start while preserving what the task needs and where it came from.
    2. BCorrect. Stale results stop competing for attention; the most recent results are kept and the agent can re-fetch if needed.
    3. CIncorrect. max_tokens limits the response, not the input; it does nothing about a noisy history.
    4. DIncorrect. That keeps all the noise permanently — the opposite of curation.
    5. EIncorrect. Rereading everything multiplies the noise and cost without removing anything stale.

  3. Question 3

    You set instructions on the server-side compaction edit to “Keep it short.” What is the likely effect?

    1. AThe default summary prompt still runs, and your text is added to it as an extra hint.
    2. BYour text replaces the default prompt, so the summary may drop state and next steps.
    3. CThe API rejects the request because instructions must be at least 50,000 tokens.
    4. DNothing changes until you also set pause_after_compaction to true.
    Show answer and reasoning
    1. AIncorrect. Tempting, but the documentation says custom instructions replace the default prompt entirely.
    2. BCorrect. The default prompt asks for state, next steps and learnings. Replacing it with “keep it short” removes that guidance.
    3. CIncorrect. Confuses the instructions field with the trigger threshold, which has a minimum token value.
    4. DIncorrect. pause_after_compaction only controls whether the API stops after writing the summary; it does not gate instructions.

  4. Question 4

    A team keeps a rule “never edit generated files under src/gen/” as a path-scoped rule in Claude Code. After long sessions compact, Claude occasionally edits those files.

    What is the best fix?

    1. ARepeat the rule in each prompt the engineers type.
    2. BDisable automatic compaction so the rule is never summarised away.
    3. CMove the rule to the project-root CLAUDE.md, which is reloaded after compaction.
    4. DRun /clear whenever the session gets long so the rule reloads.
    Show answer and reasoning
    1. AIncorrect. Works while someone remembers, but it depends on people rather than on configuration.
    2. BIncorrect. Sessions would then hit the context limit; it trades one failure for another.
    3. CCorrect. Path-scoped rules load into message history and get summarised; the project-root CLAUDE.md is re-injected from disk.
    4. DIncorrect. /clear discards the whole conversation, including the work in progress.

Practise every question in Domain 5 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.