Domain 1 — Agentic Architecture & Orchestration 27% · ~16 items · 7 task statements Priority

The largest domain and your weakest. Everything here is Agent SDK mechanics: how the loop terminates, who runs tools, how subagents get context, and where enforcement lives.

1.1 — Design and implement agentic loops

Four steps, forever: Claude reasons → requests a tool → your code executes it and appends the result → loop. Claude never executes anything itself; that gap is where approvals and hooks live.

// the entire loop, and the only correct termination test
messages = [{ role: "user", content: goal }];
while (true) {
  res = await claude.messages.create({ model, tools, messages });
  messages.push({ role: "assistant", content: res.content });

  if (res.stop_reason !== "tool_use") break;   // "end_turn" -> done

  results = await runTools(res.content);          // YOUR code runs them
  messages.push({ role: "user", content: results }); // MUST append, or Claude goes blind
}

Three loop-killing anti-patterns — the exam keys against all three

• Anti-pattern Parsing Claude's natural language for phrases like "I'm done". Inexact, and a tool_use response can contain text too.
• Anti-pattern Using an iteration cap as the primary stopping mechanism. A cap is a runaway safety net, not a completion signal.
• Anti-pattern Treating "the response contains text content" as completion.

1.2 — Coordinator–subagent orchestration

Hub-and-spoke. Every message routes through the coordinator. Subagents never talk to each other — that's what gives you observability, consistent error handling, and controlled information flow.

The coordinator's four jobs

1. Decompose the task into subtopics that actually span the topic.
2. Delegate to the right specialists.
3. Aggregate results.
4. Decide who's even needed — dynamically select subagents based on query complexity rather than always running the full pipeline.

Two more coordinator responsibilities the exam tests: partition scope across subagents to minimise duplication (distinct subtopics or distinct source types), and run an iterative refinement loop — evaluate the synthesis for gaps, re-delegate targeted queries, re-synthesise until coverage is sufficient.

1.3 — Subagent invocation, context passing, spawning

agents: {
  synthesis: {
    description: "Combines findings into a cited report.",
    prompt: systemPrompt,
    tools: ["verify_fact"]           // scoped, not all 18
  }
},
allowedTools: ["Task", "Read"]        // without "Task": no subagents

1.4 — Multi-step workflows: enforcement and handoff

The central distinction: programmatic enforcement (hooks, prerequisite gates) gives deterministic compliance; prompt-based guidance has a non-zero failure rate. When identity verification must precede a financial operation, non-zero is not acceptable.

Structured handoff on escalation

The human agent has no access to the transcript. The handoff summary carries: customer ID, root cause analysis, refund amount, recommended action.

Multi-concern requests

Decompose into distinct items → investigate each in parallel over shared context → synthesise one unified resolution. Not: handle the first and ask them to write back.

1.5 — Agent SDK hooks

Choose hooks over prompt instructions whenever the rule is a guarantee. Reciprocally: don't propose a hook for stylistic or judgment-based behaviour — that's over-engineering, and the exam penalises it.

1.6 — Task decomposition strategies

Splitting per-file avoids attention dilution — the same principle that keys item 12 in the guide, and the reason a larger context window is Wrong problem.

1.7 — Session state, resumption, forking

Deck additions From Domain 1 slides

Detail that appears in the Domain 1 lecture deck but not in the guide's own summary. All of it is fair game.

The Task tool has two names

The exam guide calls it the Task tool. The current SDK also exposes it as the Agent tool. Same mechanism — recognise both in an option list, and don't reject a correct answer because it says "Agent".

Omitting a subagent's tools field is the named security anti-pattern

If you define a subagent and leave the tools field out, it inherits everything the parent has — including Bash, Write and Edit. The deck's worked case: a read-only review agent inherited write access and modified source files. Scoping is not an optimisation; it is the safety boundary.

// risky — inherits Bash, Write, Edit...
{ description: "Reviews code", prompt: p }

// safe — can't misuse what it doesn't hold
{ description: "Reviews code", prompt: p, tools: ["Read", "Grep"] }

Read the description field as a job posting

Three parts to an AgentDefinition, with three distinct jobs: the description is how the coordinator decides which specialist to pick; the system prompt is how that specialist behaves; the tools list is exactly what it may touch. A weak description causes mis-selection between subagents in the same way a weak tool description causes mis-selection between tools.

The four categories that demand enforcement

When an option asks whether a prompt is sufficient, check whether the stem falls into one of these. If it does, the answer is programmatic.

Hooks: the airport model

Security screening happens before you board — that is PreToolUse, inspecting the call and allowing, blocking or redirecting it. Baggage gets re-tagged into a standard form on the belt after the flight — that is PostToolUse, transforming the result before Claude sees it. Both run in your code, outside Claude's conversation, which is exactly why they are deterministic.

Why one agent isn't enough

A single agent doing search, reading and writing at once fills its context with clutter and quality drops. The planner-plus-specialists split exists to keep each context clean, not merely to parallelise.

Resume versus fresh start, side by side

The stale-results trap is named as the number-one resume pitfall: the saved context includes the file contents it read earlier, so the agent may confidently discuss a function that no longer exists.

Currency check Verified Aug 2026

Domain 2 — Tool Design & MCP Integration 18% · ~11 items · 5 task statements

Your strong domain — but note where the exam's canonical answer is smaller than what you'd build. Descriptions before architecture; scoped tools before consolidation.

2.1 — Tool interfaces and descriptions

Descriptions are the primary mechanism the model uses to select tools. Minimal descriptions ("Retrieves customer information" / "Retrieves order details") are the root cause of misrouting, not a symptom of it.

A description that passes

• Purpose, and when to use it versus the similar tool
• Accepted input formats and identifier patterns
• Example queries
• Edge cases and explicit boundaries
• What it returns

Three fixes, in order of exam preference

1. Expand the descriptions — the low-effort, high-leverage first step.
2. Rename to remove overlap — analyze_content → extract_web_results with a web-specific description.
3. Split a generic tool into purpose-specific tools with defined contracts — analyze_document → extract_data_points + summarize_content + verify_claim_against_source.

Also audit the system prompt for keyword-sensitive instructions that create unintended tool associations and override otherwise good descriptions.

2.2 — Structured MCP error responses

MCP signals failure with the isError flag. Uniform "Operation failed" responses prevent recovery decisions — return metadata the agent can act on.

{
  isError: true,
  content: [{ type: "text", text: "Refunds over $500 require manager approval." }],
  errorCategory: "business",   // transient | validation | business | permission
  isRetryable: false            // stops the agent wasting retries
}

Two more distinctions the exam keys on: subagents perform local recovery for transient failures and propagate upward only what they can't resolve (with partial results and what was attempted); and an access failure (needs a retry decision) is not the same as a valid empty result (a successful query with no matches).

2.3 — Tool distribution and tool_choice

Too many tools degrades selection reliability — the guide's example is 18 tools where 4–5 suffice. Agents holding tools outside their specialisation misuse them (a synthesis agent starting to run web searches).

Scoping sets the menu; tool_choice sets the order. Note that any and forced tool cannot be combined with extended thinking.

Scoped cross-role tools are the keyed pattern for high-frequency needs: give synthesis a narrow verify_fact for the 85% simple case, keep complex verification flowing through the coordinator. Also prefer constrained tools over generic ones — replace fetch_url with load_document that validates document URLs.

2.4 — MCP servers in Claude Code and agent workflows

// .mcp.json — committed; the secret is not
{ "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    } } }

• Tools from all configured servers are discovered at connection time and are available simultaneously. Project and user servers coexist.
• Resources expose content catalogues — issue summaries, documentation hierarchies, database schemas — so the agent can see what exists without exploratory tool calls. Tools do actions; resources expose content.
• If the agent keeps preferring built-in Grep over a better MCP tool, the fix is a richer MCP tool description explaining capabilities and outputs.
• For standard integrations like Jira, use the existing community server. Build custom only for team-specific workflows.

2.5 — Built-in tools

• Edit fails on non-unique text → Read then Write. That's the keyed fallback.
• Build understanding incrementally: Grep for entry points, then Read to follow imports and trace flows. Reading every file upfront is the anti-pattern.
• Tracing usage through wrapper modules: first identify all exported names, then search each name across the codebase.

Deck additions From Domain 2 slides

The four-part anatomy of a description

Write it for Claude, not for yourself — Claude cannot see inside your function.

• What it does — the action, in one clear line.
• When to use it, and when not to — the part people skip, and the part that stops the wrong-tool error.
• Each parameter — explained in plain words.
• A short example — one tiny sample call.

Right-sizing: size tools around the choices Claude has to make. Split distinct actions; consolidate steps that always go together; avoid both extremes. The deck's worked case is travel booking — handle_travel(action, ...) forces Claude to guess an action string, whereas search_flights, book_flight and cancel_booking are picked unambiguously.

The cost of a vague interface is silence. Bad tool design does not crash. Claude picks the wrong tool, fills the wrong parameters, or gives up and answers in text. You see subtly wrong production behaviour and no error at all.

Return the error — don't throw it

A thrown exception becomes a low-level protocol error that Claude handles poorly. Return a successful response carrying isError: true plus details, so Claude sees the failure and can react to it.

Sanitise before returning. Say enough to recover and nothing that leaks internals. Never return a raw stack trace; wrap no such table: users_v2 as "the requested resource could not be accessed". A good message reads: "Couldn't fetch order #4471: database timed out after 5s. Transient — safe to retry."

Wider category vocabulary. The guide names transient, validation, business and permission. The deck also uses not_found and rate_limit as finer labels for the same distinctions. If an option offers those names, they are not wrong — judge on whether the retry decision they imply is right.

MCP in full

MCP is the USB-C of AI tooling: build the server once and any MCP client plugs in, instead of a bespoke connector per system. Tools are verbs Claude calls; resources are nouns it reads — a file, a schema, an issue summary. In Claude Code you pull a resource in by typing @.

Precedence: local > project > user. When the same server name exists at two scopes, the higher one wins, so your local override beats the team's shared entry. Running in a sub-folder also merges in parent .mcp.json files. Picking the wrong scope is named as the number-one MCP mistake — a personal token in project scope leaks to the whole team.

Transport is separate from scope. stdio means a local program Claude launches, configured with command and args. http means a remote server, configured with a url. Secret expansion — ${VAR}, with ${VAR:-default} for a fallback — works in command, args, env, url and headers.

/mcp reports connection status. Several servers run at once; name them meaningfully (github, stripe-prod) rather than server1.

Read before Edit, and prefer built-ins over Bash

Edit requires a prior Read, and the target text must match exactly and uniquely. If it is not unique, widen the surrounding text or use replace_all; only if you still cannot pin one spot does Read plus Write become the fallback. It is a last resort, not a default — a precise Edit produces a clean diff, whereas Write rewrites the file.

Use Read not cat, Grep not grep. Built-ins give better permission handling, a clearer audit trail, and are cacheable; Bash one-liners trigger extra permission prompts that cannot be cached. Save Bash for what it is uniquely good at — actually running things, like your tests or a build.

Currency check Verified Aug 2026

Domain 3 — Claude Code Configuration & Workflows 20% · ~12 items · 6 task statements Priority

Your second priority. This domain is almost entirely which file, which scope, which flag — memorisable, and therefore the cheapest points on the paper. Learn the file map until it's reflex.

3.1 — CLAUDE.md hierarchy, scoping, modularity

Keeping it modular

• @import references external files so CLAUDE.md stays small — each package imports the standards files its maintainers judge relevant.
• .claude/rules/ holds topic-specific rule files (testing.md, api-conventions.md, deployment.md) as the alternative to a monolithic CLAUDE.md.
• /memory is the keyed answer for inspecting memory files. Currency Today /memory lists locations, opens files for editing and toggles auto memory, while /context is what reports which files actually loaded this session. Answer /memory on the exam; reach for /context in practice. Card 9

3.2 — Custom slash commands and skills

"Available to every developer when they clone or pull" is always the project-scoped .claude/ directory. And .claude/config.json with a commands array does not exist — it's a recurring Doesn't exist distractor.

SKILL.md frontmatter

---
name: analyze-codebase
description: Maps module structure and dependencies.
context: fork          # run in an isolated sub-agent context
allowed-tools: Read, Write, Grep   # restrict tools during the skill
argument-hint: <module-path>       # prompt for a missing parameter
disable-model-invocation: true     # only you can trigger it (e.g. /deploy)
---

Skills vs CLAUDE.md: skills are on-demand, for task-specific workflows. CLAUDE.md is always loaded, for universal standards. If the stem needs something applied automatically, skills are the wrong instrument — they need invocation.

Personal customisation of a team skill: create a variant in ~/.claude/skills/ under a different name, so teammates are unaffected.

3.3 — Path-specific rules for conditional loading

# .claude/rules/testing.md
---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
Use React Testing Library. One assertion per test. Mock at the network boundary.

• Rules load only when editing matching files — less irrelevant context, fewer tokens.
• Glob patterns beat directory-level CLAUDE.md when a convention spans directories. Test files sitting next to their components (Button.test.tsx beside Button.tsx) are the canonical case: a directory-bound CLAUDE.md can't cover files scattered across the tree.
• Also correct for area conventions: paths: ["terraform/**/*"], paths: ["src/api/**/*"].

3.4 — Plan mode vs direct execution

Combine them: plan mode for investigation, then direct execution to implement the planned approach.

Explore subagent: isolates verbose discovery output and returns a summary — the answer when a multi-phase task risks exhausting the context window during discovery.

3.5 — Iterative refinement

3.6 — Claude Code in CI/CD

claude -p "Review the diff for security issues" \
  --output-format json \
  --json-schema ./review-schema.json

Doesn't exist --batch, CLAUDE_HEADLESS=true. And < /dev/null is a Unix workaround, not the documented mechanism.

The four CI context practices

• CLAUDE.md carries project context into CI — testing standards, fixture conventions, review criteria. It's how you raise test-generation quality and cut low-value output.
• Include prior review findings when re-running after new commits, and instruct Claude to report only new or still-unaddressed issues. Prevents duplicate comments.
• Provide existing test files so generated tests don't duplicate coverage.
• Session context isolation: the session that generated the code is worse at reviewing it. Use an independent instance.

Deck additions From Domain 3 slides

How the memory levels actually combine

They merge into one working context rather than one replacing another, with enterprise policy sitting above all three. On a conflict the more specific or later level wins: your personal file says two-space indents, the project says four, the project wins. Path-specific rules are appended last, so they win over both.

Keep it lean. Roughly 200 lines is the guidance — a bloated CLAUDE.md measurably reduces adherence. Keep the pitfalls and conventions that differ from defaults, and the why behind a rule. Cut anything Claude can work out for itself: folder layout, dependency lists.

Typing # at the start of a message quick-adds a rule; Claude asks which memory file to save it to. And note @import keeps the file organised but everything still loads at launch, so it does not shrink your context.

Slash command mechanics

The filename becomes the command and the body is the prompt. $ARGUMENTS drops whatever you typed after the command name into the prompt, so fix-issue.md invoked as /fix-issue 123 receives 123.

Commands have been merged into skills. A .claude/skills/<name>/SKILL.md also creates /name, adds a folder for supporting files, and can be auto-discovered so Claude invokes it when relevant rather than only when you type it. On a name clash between a command and a skill, the skill wins. Use disable-model-invocation: true for side-effect commands such as /commit or /deploy so Claude never fires them on its own.

Rules sit at the same priority as CLAUDE.md

.claude/rules/*.md and .claude/CLAUDE.md load at the same priority — rules are simply a tidier way to split the same content. With a paths: glob a rule is conditional and loads only for matching files; without one it loads every session. Mix both: unconditional files for project-wide conventions, path-scoped files for area-specific ones.

Plan mode is read-only, and there are three ways in

It is not a polite request. Plan mode blocks file-modifying tools at the tool level — Claude reads, searches and drafts a numbered plan, and Write and Edit cannot fire until you approve.

The plan loop: Explore → Plan → Approve → Execute → Verify. You can edit the plan before approving, and fixing a plan is cheap because nothing has been built yet.

Why planning pays: small decisions compound. Twenty unguided choices at 80% accuracy each leaves you around 1% likely to be right throughout. A plan catches the wrong turns before they cost anything.

The Explore subagent is a read-only scout limited to Read, Grep and Glob, working in a separate context window; only the findings return to your main session.

The full CI surface

claude -p runs to completion, prints the result, and exits with a status code your pipeline can branch on. Output formats are text (default), json and stream-json for real-time consumption. The json form returns the result plus metadata such as cost and session id, which you parse with jq; --json-schema forces an exact shape into structured_output.

And check the output content, not just the exit code. A run can exit zero having produced nothing useful.

Currency check Verified Aug 2026

Domain 3 has drifted the most of any domain, because Claude Code ships weekly. Every row below has an exam answer that is still keyed and a current answer that is different. Card 9 has the full detail; Card 11 ranks the alternatives.

Domain 4 — Prompt Engineering & Structured Output 20% · ~12 items · 6 task statements

4.1 — Explicit criteria to cut false positives

Specific categorical criteria beat vague instruction, every time.

Trust dynamics: one high-false-positive category poisons confidence in the accurate ones. The keyed tactic is to temporarily disable the noisy category to restore trust while you improve its prompt — not to bury it behind a confidence filter.

4.2 — Few-shot prompting

Few-shot is the answer when detailed instructions alone produce inconsistent results. Use 2–4 targeted examples, aimed at the ambiguous cases, and show the reasoning for choosing one action over a plausible alternative.

• Format consistency — demonstrate the exact shape: location, issue, severity, suggested fix.
• Ambiguous-case judgment — tool selection for vague requests; branch-level coverage gaps.
• False-positive reduction — contrast acceptable patterns against genuine issues, so the model generalises instead of matching only your listed cases.
• Extraction hallucination and empty required fields — show varied document structures: inline citations vs bibliographies, narrative prose vs structured tables, methodology sections vs embedded details.

4.3 — Structured output via tool_use and JSON schemas

tool_use with a JSON schema is the most reliable route to schema-compliant output: it eliminates JSON syntax errors. It does not eliminate semantic errors — line items that don't sum, values in the wrong field.

{ name: "extract_invoice",
  input_schema: {
    type: "object",
    properties: {
      invoice_number: { type: "string" },
      po_number:      { type: ["string", "null"] },   // nullable: may be absent
      category:       { type: "string", enum: ["goods","services","other","unclear"] },
      category_detail:{ type: ["string", "null"] },       // pairs with "other"
      stated_total:   { type: "number" },
      calculated_total:{ type: "number" }                // semantic cross-check
    },
    required: ["invoice_number", "stated_total"]
  } }

• Optional / nullable fields are the fix when the model fabricates values to satisfy a required field.
• "other" + detail string for extensible categories; "unclear" for genuine ambiguity.
• Put format normalisation rules in the prompt alongside the strict schema when source formatting is inconsistent — the schema constrains shape, the prompt handles messy input.

4.4 — Validation, retry, feedback loops

Retry with error feedback: the follow-up request includes the original document, the failed extraction, and the specific validation error.

Self-correcting validation design: extract calculated_total alongside stated_total to flag discrepancies; add a conflict_detected boolean for inconsistent source data.

Feedback-loop instrumentation: add a detected_pattern field to every finding so that when developers dismiss findings you can analyse which code constructs trigger false positives.

4.5 — Batch processing

Fit: non-blocking, latency-tolerant — overnight reports, weekly audits, nightly test generation. Misfit: anything a human is waiting on, especially a blocking pre-merge check. "Batches are often faster than 24h" is not an acceptable basis for a blocking workflow.

• SLA arithmetic: with a 24-hour worst case, submitting every 4 hours guarantees a 30-hour SLA (4h max wait + 24h processing, with headroom).
• Failures: resubmit only the failed custom_ids, with modifications — chunk documents that exceeded context.
• Before a large batch: refine the prompt on a sample to maximise first-pass success and avoid paying for resubmission cycles.

4.6 — Multi-instance and multi-pass review

• Self-review is weak because the model retains its generation reasoning and is less likely to question its own decisions. An independent instance without that context catches more — better than a "review your work carefully" instruction or extended thinking.
• Multi-pass for scale: per-file passes for local issues + separate integration passes for cross-file data flow. Fixes attention dilution and contradictory findings.
• Verification passes where the model reports confidence alongside each finding, to route review attention.

Deck additions From Domain 4 slides

Severity, defined

Without severity a typo and a security hole look equally urgent, and the important issue gets buried. The mirror term for a false positive is a false negative — missing a real issue. Both hurt; false positives are the trust-killer. The deck's worked contrast: "review this code" yields 15 flags, mostly style noise, and the team ignores all of them; criteria plus severity plus a tuned category yields 3 flags — one critical, two major — and the team acts. The good reviewer finds fewer things.

Few-shot, precisely

Shot just means example. Zero-shot is instructions only, one-shot is one example, few-shot is several. Practical parameters from the deck: typically 2–5 examples, stopping when accuracy plateaus; keep every example's format identical, since inconsistent formatting confuses the pattern; and place the examples before the real input. Always include one case where the correct answer is "not specified" or null, or Claude infers it must always produce a value and fabricates.

There is no dedicated JSON mode — in the exam's world

The keyed pattern is a tool whose input_schema describes your fields; Claude "calls" the tool and its answer is the tool input, so you read a clean tool_use block instead of prose. Two operational details: a malformed schema is rejected up front with a 400 before Claude even runs, so validate the schema first; and left on auto, Claude may skip the tool and hand you prose — use any or a forced named tool when you need the guarantee.

Exam vs reality — native structured outputs now exist on the platform. The guide keys forced tool use; answer that way.

The validation and retry loop, in full

Extract → validate → feedback → re-validate → escalate at the cap. Common semantic checks: do the line items sum to the total, is the date real and in range, and does every extracted value actually appear in the source document (the fabrication check).

Cap the retries at roughly 2–3, then flag for a human or mark the record low-confidence. No cap is an infinite loop spending money on an input Claude may be unable to fix. The deck's worked case: line items of 2,000 and 2,800 with a stated total of 5,000 — the JSON was valid both times, and only the validation step caught it. One retry carrying "the sum is 4,800" fixed it.

Batch, in operational detail

The decision rule in one line: is it acceptable for the consumer to get this within 24 hours? Yes means batch; no means the synchronous API.

Aggregating multiple passes

Merge, don't concatenate. De-duplicate overlapping findings, keep the highest severity where two passes disagree, and group by confidence for routing. Two passes reporting the same issue must appear once, at its true severity, or you have recreated the trust problem from 4.1. Confidence itself is reported as high, medium or low on each finding.

Currency check Verified Aug 2026

Domain 5 — Context Management & Reliability 15% · ~9 items · 6 task statements

5.1 — Conversation context across long interactions

• Progressive summarisation risk: numbers, percentages, dates and customer-stated expectations get condensed into vagueness. Fix: extract transactional facts into a persistent "case facts" block included in every prompt, outside the summarised history.
• Lost in the middle: beginnings and ends are processed reliably; the middle gets dropped. Fix: put a key-findings summary first and organise details under explicit section headers.
• Tool result bloat: 40+ fields per order lookup when 5 matter. Fix: trim before it accumulates.
• Pass the complete conversation history in subsequent requests — the API is stateless.
• When a downstream agent has a tight budget, make the upstream agent return structured key facts, citations and relevance scores instead of verbose prose and reasoning chains.
• Require subagents to include metadata (dates, source locations, methodological context) in structured output so synthesis is accurate.

5.2 — Escalation and ambiguity resolution

• Unreliable proxies the exam rejects: Self-assessed model confidence scores — the agent is already wrongly confident on hard cases — and Wrong problem sentiment analysis, since sentiment doesn't correlate with case complexity.
• Multiple customer matches: ask for an additional identifier. Never select by heuristic.
• The keyed fix for miscalibration is explicit escalation criteria with few-shot examples in the system prompt.

5.3 — Error propagation across multi-agent systems

{ status: "error",
  failure_type: "timeout",
  attempted: "web_search: 'AI adoption in film post-production 2024'",
  partial_results: [ /* 3 of 12 sources retrieved */ ],
  alternatives: ["narrower query", "try industry-report source"] }

That structure is what lets the coordinator choose: retry modified, try an alternative, or proceed with partial results and annotate the gap.

• Suppresses signal Generic "search unavailable" after internal retries — hides context the coordinator needs.
• Suppresses signal Returning an empty result set marked successful — failure disguised as success, no recovery possible.
• Over-reaction Propagating to a top-level handler that terminates the whole workflow on one failure.
• Correct division of labour: subagents recover locally from transient failures, propagate only the unresolvable — with what was attempted and partial results.
• Access failure ≠ valid empty result. One needs a retry decision; the other is a successful query with no matches.
• Synthesis output carries coverage annotations: well-supported vs gaps due to unavailable sources.

5.4 — Context in large codebase exploration

• The degradation signature: inconsistent answers, and the model referencing "typical patterns" instead of the specific classes it discovered earlier.
• Scratchpad files persist key findings across context boundaries; the agent refers back to them.
• Subagent delegation isolates verbose exploration while the main agent keeps high-level coordination — "find all test files", "trace refund flow dependencies".
• Summarise before the next phase and inject the summary into the new initial context.
• Crash recovery: each agent exports structured state to a known location; the coordinator loads a manifest on resume and injects it into agent prompts.
• /compact reduces context usage mid-session when the window has filled with discovery output.

5.5 — Human review workflows and confidence calibration

• Aggregate accuracy hides segment failure. 97% overall can conceal one document type performing terribly. Before reducing human review, analyse accuracy by document type and by field.
• Field-level confidence scores from the model, with thresholds calibrated on a labelled validation set — not raw self-reported confidence used bare.
• Route to humans: low confidence, or ambiguous/contradictory source documents. Prioritise limited reviewer capacity.
• Stratified random sampling of high-confidence extractions gives ongoing error-rate measurement and catches novel error patterns.

5.6 — Provenance and uncertainty in multi-source synthesis

• Attribution dies in summarisation unless claim→source mappings are structured and explicitly preserved and merged by the synthesis agent. Each finding: claim, evidence excerpt, source URL or document name, publication date.
• Conflicting statistics from credible sources: keep both values with attribution and annotate the conflict. Never silently pick one. The document-analysis agent completes its analysis with both values annotated and lets the coordinator decide reconciliation.
• Temporal data: require publication or collection dates, so a 2021 figure isn't misread as contradicting a 2024 one.
• Report structure: explicit sections separating well-established from contested findings, preserving each source's original characterisation and methodological context.
• Render by content type: financial data as tables, news as prose, technical findings as structured lists. Flattening everything into one uniform format is the anti-pattern.

A note on sources Coverage

There is no consolidated Domain 5 slide deck in this project — the other four domains each have one, Domain 5 does not. Everything above is drawn from the exam guide plus the six individual Domain 5 lecture decks (5.1 conversation context, 5.2 escalation, 5.3 error propagation, 5.4 codebase context, 5.5 human review, 5.6 provenance), all of which are captured rule by rule in the Avoid → Use playbook.

Practical consequence: Domain 5 is the one domain where you have slightly less material than the others, and it is also the smallest at 15%. Do not over-invest here. The six task statements are highly formulaic — each has one canonical fix, listed above — so the recall drills are a more efficient use of your time than re-reading.

Currency check Verified Aug 2026

Domain 5 is the most durable of the five, because it teaches judgment rather than configuration. Almost nothing here has drifted — which is a reason to trust the time you spend on it.