Lesson 13 · Domain 5 — Context Management & Reliability (15% of exam)
The final domain, and the lightest-weighted at 15% — but don't mistake that for "less tested carefully." These two task statements come up constantly disguised inside the other four domains' scenarios, because context and reliability problems are what production actually looks like.
Models reliably attend to the beginning and end of a long input; information buried in the middle is where things get dropped. Progressive summarization compounds this — condensing a conversation's history repeatedly tends to blur exactly the details that matter most: exact amounts, dates, order numbers, what the customer specifically said they expected.
The fix is structural, not "try harder to remember": keep a persistent case-facts block, included verbatim in every prompt, sitting outside whatever gets summarized.
interface CaseFacts {
orderId: string;
orderTotal: number;
orderDate: string;
customerStatedExpectation: string;
refundStatus: "none" | "pending" | "processed";
}
function buildPrompt(facts: CaseFacts, history: string, latestTurn: string) {
return `CASE FACTS (always accurate, do not summarize):
${JSON.stringify(facts, null, 2)}
CONVERSATION SO FAR:
${history}
LATEST MESSAGE:
${latestTurn}`;
}The same principle applies to tool output: a full order lookup might return 40+ fields when only 5 are ever relevant downstream. Trim before it accumulates in context rather than after — verbose, mostly-irrelevant tool results consume tokens disproportionately to what they're worth, and they're exactly the kind of "middle" content that gets lost anyway.
The official guide's sample question is a direct hit here: an agent achieves only 55% first-contact resolution against an 80% target — because it escalates simple cases (standard damage replacements with photo evidence) while trying to autonomously push through cases that actually need a real policy exception. Both are miscalibration, in opposite directions.
The fix isn't a confidence score or sentiment detection — both are unreliable proxies for actual case complexity, and in this exact scenario the agent is already confidently wrong on the hard cases. The fix is explicit escalation criteria with few-shot examples demonstrating the boundary directly: escalate immediately on an explicit customer request for a human, on a policy gap or exception (not just "this seems hard"), on genuine inability to make progress, or on multiple ambiguous matches that need clarification rather than a guessed selection.
Primary source: Anthropic's Claude API docs and the Agent SDK overview cover context window management directly — this lesson compresses Task Statements 5.1 and 5.2.
Want to sketch escalation criteria for a system you're actually designing? Describe the domain and we'll draft the boundary together.