CCA-F Domain 5 Study Guide: Context Management & Reliability

A context window is finite. Every token — the system prompt, all prior turns, tool definitions, tool results, and files you read — competes for the same fixed budget. Large codebase exploration blows past that budget quickly: read a dozen whole files and you have crowded out the very reasoning space you need. The failure mode is context rot — as the window fills with low-value material, the model's attention degrades, it loses track of earlier goals, and answers get vague or contradictory. Objective 26 is about three complementary strategies that keep an agent coherent across work that exceeds what fits at once.

• Subagent isolation — delegate a focused subtask (run the test suite, grep a sprawling module, summarize a log) to a subagent that runs in its own fresh, isolated context window. Its verbose intermediate tool calls and results stay inside that subagent; only a distilled final message returns to the parent. The main thread stays clean and on-mission.
• Scratchpad files — persist findings to disk instead of holding them all in the window. Write notes, a partial map of the code, or a running checklist to a file, then read back only what you need later. Disk is durable and effectively unbounded; the context window is neither.
• Targeted file reading — use Grep/Glob to locate the exact functions, symbols, or line ranges that matter and read only those slices, rather than loading entire files 'just in case.' You pull in signal, not bulk.

Concrete scenario: a multi-agent research system maps an unfamiliar 400-file service. An orchestrator dispatches one subagent per subsystem (auth, billing, ingestion). Each subagent greps for its entry points, reads only the relevant handlers, and writes a short findings/auth.md summary to the scratchpad. Each returns two paragraphs — not its 50k tokens of file reads — to the orchestrator, which composes the architecture overview from the summaries plus the notes on disk. No single context ever held the whole codebase, yet the final answer is coherent and grounded.

Orchestrator (main context)
  ├─ dispatch subagent: "Map the auth subsystem"
  │     grep 'login|session|token' src/  -> 6 files
  │     read only the matched handlers (targeted, not whole files)
  │     write findings/auth.md   (scratchpad — persisted to disk)
  │     RETURN: 2-paragraph summary   (isolation — verbose reads stay behind)
  ├─ dispatch subagent: "Map billing"  -> same pattern
  └─ compose overview from returned summaries + findings/*.md
        (main window never held all 400 files)

The Claude Messages API is stateless: the server keeps no memory between calls. It does not store your conversation, associate requests by a session ID, or 'remember' the last thing it said. Each request is evaluated entirely on the payload you send. That is why multi-turn state exists only if you create it — by resending the entire conversation on every request.

The mechanism is the messages array. To continue a conversation you append the model's previous reply and the new user turn to the full history and send all of it again. Roles alternate user / assistant, and every prior turn must be included — including any tool_use blocks the model emitted and the corresponding tool_result blocks — or the model loses the thread. The client (your application) is the sole keeper of conversation state; the API is a pure function from messages to the next message.

# Turn 1
messages = [{"role": "user", "content": "List the users table columns."}]
resp = client.messages.create(model=MODEL, max_tokens=1024, messages=messages)

# Persist BOTH sides before the next turn.
messages.append({"role": "assistant", "content": resp.content})

# Turn 2 -- resend everything so the model 'remembers' turn 1.
messages.append({"role": "user", "content": "Now write a migration to add an index."})
resp = client.messages.create(model=MODEL, max_tokens=1024, messages=messages)

# If a turn used tools, the assistant's tool_use block AND the
# user-role tool_result block must both stay in `messages`, or the
# model can't see what the tool returned.

A reliable agent knows when to stop acting on its own. Objective 28 is a decision boundary: when should the agent immediately honor a human escalation and when should it attempt autonomous resolution with its tools? The default for routine, in-policy, reversible work is to resolve autonomously — that is the point of an agent. But certain signals override that default and demand an immediate handoff.

The single most important rule: when a human explicitly asks to take over — 'stop, let me handle this,' 'escalate to a manager,' 'I want to speak to a person' — the agent honors it immediately. It does not relitigate the request, run one more tool call, or try to satisfy the underlying need itself first. An explicit escalation request is a stop condition, not an input to weigh against continuing.

Scenario: in a support agent, a customer writes 'this is the third time — just escalate me to a human.' The correct behavior is to stop attempting fixes and route to a person now, acknowledging the request. Continuing to troubleshoot autonomously 'because the agent might still solve it' is the classic wrong move: it ignores an explicit human instruction and erodes trust. Contrast that with a customer asking to resend a receipt — reversible, in-policy, fully within the agent's tools — which the agent should simply do.

In a human-in-the-loop extraction pipeline, reviewer time is the scarce resource. Objective 29 is about spending it where errors are most likely and most costly. The strong design routes work by risk — confidence scores, document characteristics, and field-level ambiguity — so scrutiny concentrates on the outputs most likely to be wrong. The weak design is random sampling, which spreads attention uniformly and, by construction, misses the systematically hard cases as often as it catches them.

• Confidence scores — route low-confidence extractions to review and auto-accept high-confidence ones above a calibrated threshold. This is the primary signal.
• Document characteristics — flag whole documents that are structurally risky: scanned/handwritten, poor OCR quality, unusual template, a vendor never seen before, or a total above a value threshold.
• Field-level ambiguity — route at the field granularity, not just the document. A single ambiguous tax_id or a date that parsed two ways should trigger review of that field even when the rest of the document is clean and high-confidence.

Scenario: an invoice pipeline extracts vendor, date, line items, and total. Documents where every field clears the confidence threshold and the vendor is known auto-post. Anything with a low-confidence field, a first-time vendor, an amount over the approval limit, or a total that fails to reconcile against the line items is routed to a reviewer — and the queue surfaces exactly the suspect fields, pre-highlighted, so the human corrects them in seconds rather than re-keying the page.

def route(doc):
    reasons = []
    if doc.min_field_confidence < 0.85:
        reasons.append("low-confidence field")
    if doc.total > APPROVAL_LIMIT:
        reasons.append("amount over limit")
    if doc.vendor_is_new or doc.ocr_quality == "poor":
        reasons.append("risky document characteristics")
    if not doc.total_reconciles_with_line_items():
        reasons.append("field-level inconsistency")

    if reasons:
        return review_queue(doc, highlight=reasons)   # human sees WHY
    return auto_accept(doc)

# A random 10% sample would review confident, correct docs while
# waving through the genuinely ambiguous ones -- the opposite of the goal.