headersHelper, #37 tool_choice: "any".
This lesson answers all of them.
/compactThis answers your flagged #10 directly. Long sessions degrade: the model starts giving inconsistent answers and referencing "typical patterns" instead of the specific classes it discovered earlier. The guide's fix is to move knowledge out of the conversation.
| Tool | What it is | Solves |
|---|---|---|
| Scratchpad file | A file the agent writes key findings into as it explores, and re-reads for later questions. | Context degradation across a long session — findings survive past the context boundary. |
| Manifest | A structured state export to a known location. On resume the coordinator loads the manifest and injects it into agent prompts. | Crash recovery. Work already completed isn't repeated. |
| Subagent delegation | Verbose exploration happens in an isolated context; only the summary returns. | Keeping the main agent's context clean while it coordinates. |
/compact | Reduces context usage mid-session. | Context filling with verbose discovery output. |
| Phase summaries | Summarize phase N's findings before spawning phase N+1's subagents; inject as initial context. | Carrying knowledge across phases without carrying the transcript. |
So, #10 answered: before spawning a subagent to investigate the caching layer, check the scratchpad / manifest records from earlier phases — that's where prior findings were persisted. It isn't jargon from nowhere; it's guide 5.4's named mechanism.
Exam tell: "the agent contradicts what it found earlier" or "references typical patterns rather than the actual code" → persist findings outside the conversation. Not a bigger context window, not re-reading everything.
Exam tell: if the scenario names a lost number — a refund amount, a date, a percentage — the answer is the structured facts block, not "summarize more carefully."
| Escalate | Don't escalate |
|---|---|
| The customer explicitly asks for a human — immediately, without investigating first | Merely complex cases |
| Policy gap or ambiguity — policy is silent on this request | Negative sentiment / frustration alone |
| Cannot make meaningful progress | Low self-reported confidence |
The two unreliable proxies: sentiment-based escalation and self-reported confidence scores are explicitly named as poor stand-ins for actual case complexity. Frustration alone → acknowledge it and offer resolution if it's within capability; escalate only if the customer reiterates.
Multiple matches from a tool → ask for additional identifiers. Never pick heuristically.
A subagent failure should reach the coordinator as structured error context: failure type · what was attempted · partial results · alternative approaches.
Two anti-patterns, both named: silently suppressing errors (returning empty results as success) and terminating the whole workflow on a single failure.
The distinction that gets tested: an access failure (timeout — needs a retry decision) is not the same as a valid empty result (the query succeeded, nothing matched). Collapsing both into "search unavailable" hides what the coordinator needs.
Subagents should attempt local recovery for transient failures and propagate only what they cannot resolve — with what was attempted and any partial results.
This is your #49 miss and a 0% objective on the 761 report.
Why your answer lost: you chose reviewing whatever reviewers happen to flag during ad-hoc spot checks. That's a convenience sample — it only finds failures someone already suspected, which is exactly the opposite of detecting novel modes. "Ongoing monitoring for unknown failures" → stratified random sampling, every time.
| Problem | The guide's answer |
|---|---|
| Attribution lost during summarization | Structured claim-source mappings (source URL, document name, excerpt) that downstream agents must preserve and merge |
| Two credible sources give different statistics | Annotate the conflict with attribution — keep both values. Never arbitrarily select one. |
| Figures that look contradictory but aren't | Require publication / collection dates in structured output, so temporal differences aren't misread as contradictions |
| Reporting mixed content | Render by type — financial data as tables, news as prose, technical findings as lists — not everything into one uniform format |
Recurring shape: in Domain 5 the answer is almost always preserve and annotate, never resolve and simplify.
@ mentionTools are for actions. Resources are for content. The guide frames resources as exposing content catalogs — issue summaries, documentation hierarchies, database schemas — so the agent can see what data exists without burning exploratory tool calls.
Real examples from the docs — the certsafari item used the second one verbatim:
Typing @ lists available resources from all connected servers, alongside
files, with fuzzy search.
Exam tell: "reference that specific document inline, the way you'd reference a
local file" → the @ mention. "Ask in plain language and trust it
infers which resource" is the distractor — that's exploratory guessing, the thing resources
exist to eliminate.
Verbatim from the guide (2.4): "tools from all configured MCP servers are discovered at connection time and available simultaneously to the agent."
Your #30 miss. With Postgres, Sentry and Slack servers all connected, a single request can call across all three in the same turn. There is no sequencing gate, no "finish one server's calls before another's tools become selectable."
Careful — the real constraint is elsewhere. Guide 2.3 warns that giving an agent too many tools (18 instead of 4–5) degrades selection reliability. That's a design concern about crowding, not a runtime availability rule. Don't let one become the answer to the other.
| Need | Where |
|---|---|
| Shared team tooling, version-controlled | .mcp.json — project scope |
| Personal / experimental servers | ~/.claude.json — user scope |
| Credentials without committing secrets | Env var expansion: ${GITHUB_TOKEN} inside .mcp.json |
headersHelper: a command Claude Code runs at connection time whose stdout (header JSON)
is merged into the connection headers. It runs fresh on every connection and the
result is not cached.
headers value and rules out the oauth block entirely. Docs-verified,
not in the exam guide — treat as bonus.
tool_choice — your flagged #37Lesson 0002 taught this in June; you flagged it as hard to recall. One table:
| Setting | Guarantee | Use when |
|---|---|---|
"auto" | Model may return text instead of calling a tool | Conversation where a tool call is optional |
"any" | Must call a tool, model chooses which | Structured output is required and several schemas exist — the model picks the matching one |
{"type":"tool","name":"…"} | Must call that tool | A specific extraction must run first (e.g. extract_metadata before enrichment) |
The #37 insight worth keeping: "any" is what makes
several small, purpose-specific tools better than one oversized combined schema. Three tools
(extract_invoice / extract_receipt / extract_purchase_order) plus
"any" lets Claude select the schema matching the actual document. One giant schema covering
all three forces the model to reason about irrelevant fields on every call — the same
splitting-over-consolidating principle as guide 2.1.
Exam guide v1.0 (guides/) — Domain 5 in full (5.1 context, 5.2
escalation, 5.3 error propagation, 5.4 codebase exploration / scratchpads / manifests / /compact,
5.5 human review & calibration, 5.6 provenance) and 2.3–2.4 (tool distribution, MCP scoping,
resources vs tools). Read 2026-08-24.
Docs-verified the same day: the @server:protocol://resource/path
mention form and headersHelper
(MCP reference). headersHelper is
not in the exam guide — included because certsafari tested it.
Evidence: feedbacks-from-other/2026-08-24-761*.png (0% on 5.1 and 5.5)
· tries/2026-08-24-wrong-answers.md (#9, #12, #30, #49) ·
tries/2026-08-24-marked-questions.md (#10, #14, #37).