CCAR-F - Context Management & Reliability (15% of the exam) - Section 5.1
Manage conversation context to preserve critical information across long interactions.
Progressive summarisation quietly destroys numbers, percentages, dates and stated customer expectations, and the lost in the middle effect means long inputs are processed reliably at their start and end while middle findings get omitted. Candidates should hold transactional facts in a persistent case-facts block outside summarised history, trim verbose tool output to the relevant fields before it accumulates, and place key findings at the start of aggregated input.
progressive summarisation risklost in the middle effectpersistent case facts blocktool output trimmingposition-aware input ordering
Each get_customer call on the Customer Support Resolution Agent returns a full 24 month order history averaging 18,000 tokens of JSON. Sessions now compact after roughly 12 turns, median handling latency has risen to 31 seconds, and reviewers note that the agent loses the customer's earlier statements once compaction starts. A typical contact uses two or three fields from that payload. Which change most effectively addresses it?
ARaise the compaction threshold so the harness tolerates a much larger transcript before it begins summarising the earlier turns.
BInstruct the agent in the system prompt to disregard the order history fields it does not need when it reads a get_customer result.
CChange get_customer to return the account summary and the recent order identifiers, with the full history fetched on demand by a separate call.check_circle Correct
DDelegate every get_customer call to a subagent through the Task tool so that the large payload lands in a separate context window.
Trim verbose tool results at the tool boundary so that bulky payloads never enter the conversation context in the first place. Everything a tool returns becomes part of the input on every subsequent turn, so an oversized result is paid for repeatedly and pushes the session into compaction where genuinely irreplaceable material, the customer's own words, is summarised away. Reshaping the tool contract to return a summary plus identifiers, with detail available on request, is the only option that reduces the token load rather than relocating or deferring it.
Why A is wrong: Tempting because compaction is where the customer statements are lost, so deferring it appears to protect them. It is wrong because the payload still consumes the same share of every input, so latency and cost stay high and the loss returns as soon as the higher threshold is reached.
Why B is wrong: Tempting because ignoring irrelevant fields is exactly what a human would do and the instruction is easy to write. It is wrong because the tokens are already in the context once the result is returned, so reading behaviour changes nothing about compaction pressure, latency or spend.
Why C is correct: Correct because it removes the tokens at their source: the tool returns what a contact actually consumes, the rare case that needs deep history retrieves it explicitly, and compaction pressure, latency and cost all fall together.
Why D is wrong: Tempting because subagent isolation is a real technique for keeping bulky work out of a coordinator's context. It is wrong because it is over-engineered for a payload the tool itself should shrink, and it adds a round trip and a summarisation boundary to every identity lookup.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.
Reduce the case facts block to the customer identifier alone, so that less material sits in the weakly attended region of the input.
errorWhy it is wrong: Tempting because a shorter block does compete with less surrounding text and the identifier is the anchor fact. It is wrong because the disputed order and amount are exactly the values the recommendation turns on, so removing them replaces a contradiction with a missing fact.
It guarantees the agent stops misreading the disputed amount on long disputes, because a fact stated most recently in a request takes precedence over any conflicting figure appearing earlier in the same conversation.
errorWhy it is wrong: Tempting because recent content is genuinely more salient and the change does reduce this class of error. It is wrong because salience is a tendency rather than a precedence rule, so a conflicting figure earlier in the transcript can still win on some proportion of turns.
Drop the earliest customer messages from the context, on the grounds that later turns carry the current state of the dispute.
errorWhy it is wrong: Tempting because the oldest turns feel least relevant and dropping them is simple to implement. It is wrong because those messages are 9 percent of the spend and carry the customer's original intent, so it targets the smallest saving at the highest cost to resolution.