Context Management & Reliability

5.1 Prompt caching for cost and latency

Every request to the Claude API is stateless — the full prompt is reprocessed from scratch each time. Prompt caching changes that trade-off: you mark a portion of the prompt, a long and stable prefix (a system prompt, a set of tool definitions, a large reference document), as cacheable. If a later request sends that exact same prefix again, Claude reuses the cached processing instead of redoing it — the repeated portion is billed at a steep discount and returns faster.

The exam framing: caching is a reliability lever, not just a cost trick

The scenario the exam reaches for is a high-volume production workload with a stable, repeated context prefix — the textbook example is a coding agent that re-sends the same large codebase context on every turn of a session. The win comes entirely from prefix stability: caching only pays off when the cached bytes are identical between requests.

That has a direct architectural consequence: restructure prompts so volatile content comes last. Put the system prompt, tool definitions, and any large stable documents at the front — cached once, reused many times. Put the thing that changes every request (the latest user message) at the end. A prompt built the other way around — volatile content mixed into or ahead of the stable prefix — invalidates the cache on almost every request and pays full price every time.

# Cache-friendly ordering
messages = [
  # stable: system prompt + tool defs + large docs, marked cacheable
  {"role": "system", "content": [
      {"type": "text", "text": SYSTEM_PROMPT},
      {"type": "text", "text": CODEBASE_CONTEXT, "cache_control": {"type": "ephemeral"}}
  ]},
  # volatile: the one thing that changes this turn, always LAST
  {"role": "user", "content": latest_user_message}
]

Cached entries also expire: by default after 5 minutes of inactivity, refreshed at no extra cost on every hit (a 1-hour TTL is available at double the write cost for less frequent access patterns). A byte-identical prefix that arrives after too long a gap still misses the cache — a dropped hit rate doesn't always mean the prefix changed, it can just mean the requests spread out too far.

5.2 Handoff patterns between agents and sessions

Domain 1 covered how a subagent reports back to its coordinator inside one running system. This section is about a different kind of handoff: transferring a long-running task from one session or agent instance to another entirely — for example, a session that hits its loop-iteration cap and must reseed a fresh session to continue, or a support case that transfers from a bot to a human agent.

The failure mode the exam tests is the same shape in both directions: the handoff payload is either too much (the raw conversation history, dumped wholesale, forcing the receiver to re-derive everything) or too little("start over with no context," throwing away confirmed work). The correct pattern sits in between:

• What's been tried— actions already taken and their outcomes, so the new session/agent doesn't repeat failed approaches.
• What's confirmed — durable facts already established (identity verified, account number, case category) that must not be re-derived or re-asked.
• What's still open — the unresolved part of the task, framed as the actual next step.

5.3 Escalation: deterministic thresholds, not self-reported confidence

This is anti-pattern #2 from Domain 1, deepened: escalation and handoff triggers must be objective and enforced in code, never based on the model self-reporting how confident it is. Concrete, deterministic triggers the exam expects you to recognise:

• A refund or transaction amount exceeds a policy limit (a fixed dollar threshold your code checks).
• N consecutive tool failures — a counted, code-enforced ceiling, not a vibe.
• The customer makes an explicit request for a human — a detectable, unambiguous signal.
• A loop-iteration cap being hit — the same bound that stops runaway agent loops doubles as an escalation trigger.

The anti-pattern the exam plants over and over: routing escalation off the model saying something like "I am only 60% confident in this answer." LLM self-reported confidence is poorly calibrated— a model can be very confidently wrong, and just as easily unconfident about an answer that is actually correct. A confidence score generated by the same model that might be wrong is not an independent check on that model; it's the fox reporting on the henhouse.

5.4 Error propagation across multi-agent systems

Domain 1's anti-pattern #5 (silent subagent failure) covered a single subagent swallowing an error. This section is about what happens across multiple hops: if subagent A fails partway through and its (partial) output feeds subagent B, B needs to know that A's output is incomplete or degraded — not treat it as a normal, complete result.

A subagent that hits an error partway through its work must propagate that error to the coordinator (or the next subagent in the chain) as structured information:

• What failed — the specific step or tool call, and the error category.
• What was completed before the failure — so downstream steps know exactly how much of the result is trustworthy.
• Whether it is safe to retry — transient vs. terminal, so the coordinator can decide the recovery path.

Two failure modes bracket the correct behaviour. On one side, a subagent that returns an empty or success-looking report after a partial failure launders the error into false confidence — everything downstream reasons over incomplete data as if it were whole, and the mistake compounds hop over hop. On the other side, letting the whole system crash uninformatively destroys the work that did succeed and gives operators nothing to act on. The correct middle path is a structured, partial/degraded report that downstream agents are designed to check for.

5.5 Provenance: tracking where claims come from

In systems that synthesize information from multiple sources or subagents — the Multi-Agent Research System scenario's core pattern — every claim in the final output should be traceable back to the source that produced it. Provenance is what lets a reader (or a downstream system) tell the difference between a well-supported fact and a guess.

When two sources disagree, or a claim shows up with no source at all, the synthesis step's job is to surface that conflict, not resolve it invisibly. Two ways synthesis quietly manufactures false confidence:

• Majority vote across correlated, non-independent sources.If subagents share an upstream input or a common blind spot, "2 out of 3 agree" is not independent confirmation — it can launder a single shared error into apparent consensus.
• Blending contradictory claims into one confident-sounding statement. Hedged language that mashes two disagreeing dates or facts together reads as authoritative while communicating nothing verifiable.

The correct handling: flag the conflict or unsourced claim explicitly in the output, and either exclude it or route it for separate verification — never majority-vote it away, and never re-run subagents repeatedly until they happen to agree, which manufactures consensus rather than finding the truth.