Long-conversation context management
Manage conversation context to preserve critical information across long interactions.
This subtopic (5.1) sits in Context Management & Reliability (D5) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 16 practice questions here — 4 easy, 7 medium, and 5 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- progressive summarization risks — numerical values, dates, percentages lost
- persistent case facts block — transactional data outside summarized history
- lost-in-the-middle effect — findings in middle sections missed
- tool results accumulate and consume tokens disproportionately
Free practice questions: Long-conversation context management
During a billing dispute, the agent calls process_refund after summarizing a long conversation. Which data type is most at risk of being lost during progressive summarization?
Show answer & explanation
Correct answer: D. The specific refund amount and transaction date
Progressive summarization tends to preserve narrative context but loses precise numerical values, dates, and percentages — exactly the data needed for process_refund to execute correctly. 'Account status and tier level' is categorical and survives summarization. 'Category of the original complaint' is qualitative and typically retained. 'List of tools invoked' is structural metadata, not conversational content.
Your support agent calls get_customer, lookup_order, and process_refund across a long dispute session. After 15 tool calls, the context window is nearly full. What is the primary reason tool results consume tokens disproportionately in long sessions?
Show answer & explanation
Correct answer: B. Tool results include full raw API payloads that accumulate in the conversation history with each call
Each tool result is appended to the conversation history as a full message, and raw API payloads from tools like lookup_order can be large — they accumulate across every tool call in the session. 'Verbose reasoning after each call...' may occur but is not the primary accumulation pattern. 'System-level overhead tokens...' describes a fixed overhead per call, not disproportionate accumulation. 'Tool definitions re-injected...' is not how the API works — definitions are sent once.
Your team uses Claude Code for a multi-hour refactor session. Midway through, the agent documents a critical constraint (a shared mutex in module X) in its working context, then continues through many files. Near the end, it reintroduces a race condition in module X. What change to your CLAUDE.md workflow best mitigates this lost-in-the-middle failure?
Show answer & explanation
Correct answer: C. Record durable invariants like the module X mutex in CLAUDE.md so they are reloaded into every turn's context window.
Findings buried mid-conversation decay in influence; promoting the mutex invariant into CLAUDE.md makes it a persistent preamble reloaded every turn, bypassing lost-in-the-middle entirely. 'Switch long refactor sessions' addresses planning discipline, not stale findings. 'Add a /checkpoint slash command' appends more middle content, worsening the effect. 'Increase the context window budget' enlarges the very region where attention degrades.
2 more free questions on this subtopic in the practice stream, plus 11 in the full bank. Keep practicing →