Glossary

Key terms and definitions per exam domain, crawled from the Glossary of the source guide. Each entry carries a concise definition plus the exam context.

Domain 1 — Agentic Architecture & Orchestration

Agentic Loop

A control flow where Claude repeatedly receives input, decides on an action (often a tool call), observes the result, and continues until a task is complete. The loop runs until the model returns a stop_reason of end_turn rather than tool_use.

Exam context: Questions test whether you understand the loop termination conditions and how stop_reason values determine whether the loop continues or exits.

See also: 1.1 Agentic Loops

stop_reason

A field in the Claude API response that indicates why the model stopped generating. The exam’s two key values are end_turn (the model finished its response naturally) and tool_use (the model wants to call a tool). In an agentic loop, tool_use means the loop should continue; end_turn means the task is complete. A production loop must also handle pause_turn, max_tokens, stop_sequence, refusal, and model_context_window_exceeded.

Exam context: This is a frequently tested concept. Key the exam answers on end_turn vs tool_use, and know what each value signals to the orchestration layer.

See also: 1.1 Agentic Loops

tool_use

A stop_reason value indicating that Claude wants to invoke a tool. The response will contain a tool_use content block specifying the tool name and input parameters. The orchestrator must execute the tool and return the result as a tool_result message before the next API call.

Exam context: Understand the full tool-use flow: Claude returns tool_use, the orchestrator executes, and sends back tool_result. Know what happens if the tool result is malformed or missing.

See also: 1.1 Agentic Loops

end_turn

A stop_reason value indicating that Claude has finished its response and does not need to call any more tools. In an agentic loop, this is the signal to exit the loop and return the final response to the user.

Exam context: The exam may present scenarios where you must determine whether to continue looping or terminate. end_turn is always the termination signal.

See also: 1.1 Agentic Loops

Orchestration Pattern

A design approach for coordinating one or more Claude calls to accomplish a task. The patterns the guide names are prompt chaining (fixed sequential steps), dynamic adaptive decomposition (the model decides the split at runtime), and hub-and-spoke coordination. Parallel execution of independent subtasks is the other common shape.

Exam context: You must match each orchestration pattern to the correct use case. Know when prompt chaining is preferable to a single monolithic prompt, and when parallel execution provides a genuine benefit.

See also: 1.2 Multi-Agent Orchestration

Multi-Agent System

An architecture where multiple specialised agents collaborate to complete a task. Each agent has its own system prompt, tools, and responsibilities. The tested topology is hub-and-spoke: a coordinator delegates to subagents and all inter-agent communication flows through it. Subagents never communicate directly with each other — options proposing direct peer-to-peer communication are exam distractors, because they break observability, consistent error handling, and controlled information flow.

Exam context: Know the trade-offs between single-agent and multi-agent designs. The exam tests whether you can identify when a multi-agent system is justified versus when a simpler pattern suffices.

See also: 1.2 Multi-Agent Orchestration

Coordinator

The central agent in a hub-and-spoke system. It decomposes the task, spawns and sequences subagents, and aggregates their results. It is the only component with a view of the whole job, and every message between subagents passes through it.

Exam context: Scenarios often fail because the coordinator is doing specialist work itself, or because subagents are talking to each other. Both are distractors — the coordinator delegates and aggregates, and it is the sole communication hub.

See also: 1.2 Multi-Agent Orchestration

Subagent

A separate Claude instance spawned by a coordinator to handle a scoped piece of work. It runs in its own context window with its own system prompt and its own tool list, and it returns a result to the coordinator when it finishes.

Exam context: The single most-tested property is isolation — a subagent cannot see the coordinator’s conversation. Everything it needs must be passed explicitly in the task definition.

Task Tool (Agent)

The tool a coordinator calls to delegate work to a subagent. The exam guide names it Task. Current Claude Code renamed it to Agent. Both names refer to the same delegation mechanism.

Exam context: Answer with the guide’s Task naming on keyed items. Recognise Agent if you meet it in current documentation or tooling.

AgentDefinition

The declaration of a subagent: its description, its instructions, and the tools field that scopes which tools it can reach. Note that the instruction field is named prompt, not systemPrompt — a common wrong answer.

Exam context: Know the field names and know that tools scopes access. Scope each agent to a small, role-focused set. The guide’s illustration contrasts 4–5 tools with 18, where selection reliability degrades on decision complexity alone.

allowedTools

The list of tools a given agent is permitted to call. For a coordinator this is a gate on delegation itself: unless allowedTools includes "Task" (or "Agent", its current name), the coordinator cannot spawn subagents at all, no matter how its prompt is written.

Exam context: A frequently tested failure mode — a coordinator that “will not delegate” usually has an allowedTools list missing the delegation tool, not a prompt problem.

fork_session

An option that branches a session so an agent can explore an alternative path without polluting the original context. Exposed as fork_session / forkSession in the SDK and --fork-session on the CLI. It is set beside resume: resume names the session, fork_session branches from it instead of appending.

Exam context: The answer when a scenario needs divergent exploration — trying several approaches — while keeping the main line of work clean.

See also: 1.7 Session State and Resumption

Programmatic Enforcement

Enforcing a workflow rule in code — a hook, a gate, or a check — rather than by instruction in a system prompt. Prompt guidance is probabilistic and carries a non-zero failure rate. Programmatic enforcement is deterministic.

Exam context: The decision rule the exam applies repeatedly: if a single failure means financial loss, a security breach, or a compliance violation, the answer is programmatic enforcement. Stronger prompts and few-shot examples are always distractors in those scenarios.

Prerequisite Gate

A code-level check that blocks a tool from executing until a prior condition is satisfied — for example, refusing process_refund until get_customer has returned a verified customer ID in the current session.

Exam context: The canonical fix for a “the prompt says to verify but it skips it 8% of the time” scenario. The gate takes the failure rate to zero because the model cannot route around it.

Structured Handoff

The self-contained summary an agent compiles when escalating to a human who does not have the conversation transcript. It must carry customer ID, a factual summary, root cause, any monetary amount, and a recommended action.

Exam context: The tested constraint is that the human sees nothing but this summary. Options that omit a required field, or that assume the human can read the chat history, are wrong. Note that “handoff” in this guide means escalation to a person — there is no agent-to-agent handoff primitive in the Agent SDK.

PreToolUse

An Agent SDK hook event that fires before a tool executes. Because it runs first, it can deny the call or rewrite its parameters, which makes it the mechanism for blocking dangerous operations and validating inputs.

Exam context: The answer whenever a scenario demands that something “must never” happen. Pair it with PostToolUse: Pre gates the call, Post handles the result.

See also: 1.5 Agent SDK Hooks

PostToolUse

An Agent SDK hook event that fires after a tool call succeeds. It is the place for normalising or validating tool output, redacting sensitive values, and audit logging.

Exam context: Tool-result problems — inconsistent formats across data sources, credit-card numbers arriving in results — are PostToolUse work, not prompt work.

See also: 1.5 Agent SDK Hooks

Prompt Chaining

A fixed sequential decomposition: the task is split at design time into an ordered series of steps, and each step receives the previous step’s output.

Exam context: The right choice when the structure of the work is known in advance and stable. Contrast with dynamic adaptive decomposition, which is the answer when it is not.

Dynamic Adaptive Decomposition

Letting the model decide at runtime how to break a task up, rather than fixing the steps in advance.

Exam context: Signalled by stems that describe unpredictable, open-ended or exploratory work — “the structure is not known upfront”. Where the steps are predictable, prompt chaining is the better answer.

Attention Dilution

The degradation that occurs when a single agent is asked to hold too many concerns at once: as instructions and tools accumulate, quality drops across all of them rather than on any one.

Exam context: The reason decomposition and role-scoped subagents beat one large do-everything agent. Recognise it as the underlying cause when a stem describes an agent that has become unreliable after scope was added.

Session Resumption

Continuing a previous session rather than starting fresh, so accumulated state is preserved. Resume by name or by ID. A name can be set at session start with -n / --name.

Exam context: The answer when a scenario needs continuity across invocations. Contrast with a deliberate fresh start, which is what you want when the existing context has gone stale.

See also: 1.7 Session State and Resumption

Stale Context

A session whose accumulated history has started to work against it — the model repeats itself, contradicts its earlier statements, or ignores recent tool results.

Exam context: The counter-intuitive fix is the tested one: not more context, but a fresh session seeded with a curated summary of the facts that still matter.

See also: 1.7 Session State and Resumption

Error Recovery

Strategies for handling failures within an agentic loop without crashing the entire workflow. Common approaches include retry with error feedback, fallback to a simpler strategy, graceful degradation (returning partial results), and escalation to a human operator.

Exam context: The exam tests whether you can design resilient agentic systems. Know when to retry versus when to fail gracefully, and how to prevent infinite retry loops.

Claude Agent SDK

Anthropic’s official framework (Python and TypeScript) for building agentic applications. It provides agent definitions with tool management, hooks, and subagent spawning, and handles the agentic loop internally so developers focus on configuring agent behaviour rather than writing loop logic.

Exam context: Know the AgentDefinition shape, the Task tool gate for spawning subagents, and the SDK hooks tested in 1.5.

Routing Pattern

An approach where a classification step decides which specialised handler processes a request.

Exam context: Treat this as a trap term in Domain 1. A routing classifier decides which agent receives a request. It does nothing about how that agent then behaves. The guide’s Domain 1 sample questions key it wrong twice, because the failures described happen inside an agent’s execution, where the fix is a prerequisite gate or a hook. Routing is also the wrong remedy for a bloated tool set — splitting into role-scoped agents is the keyed answer there.

Guardrail

A safety mechanism that constrains Claude’s behaviour within acceptable boundaries, whether by validating input, validating output, or restricting tool access.

Exam context: Guardrails are no longer a standalone Domain 1 task statement. The tested forms are deterministic enforcement via workflow prerequisites and handoff gates (1.4) and Agent SDK hooks such as PreToolUse interception (1.5).

Human-in-the-Loop

A design pattern where certain agent actions require explicit human approval before execution, typically for high-impact operations.

Exam context: Human-in-the-loop is no longer a standalone Domain 1 task statement. Approval gates are tested as workflow enforcement patterns (1.4), and escalation to humans is tested in Domain 5.2 (escalation and ambiguity resolution).

Domain 2 — Tool Design & MCP Integration

Tool Schema

A JSON Schema definition that describes a tool’s name, purpose, and expected input parameters. Claude uses the schema to understand what a tool does and how to call it correctly. Well-designed schemas include clear descriptions, constrained types, and sensible defaults.

Exam context: The exam tests schema design best practices — descriptive names, detailed parameter descriptions, required vs optional fields, and enum constraints. Know that better descriptions lead to better tool selection by Claude.

See also: 2.1 Tool Interface Design

MCP Server

A process that exposes tools, resources, and prompts to MCP clients via the Model Context Protocol. An MCP server registers its capabilities and handles incoming tool calls. Servers can be local (running on the same machine) or remote (accessible over a network).

Exam context: Know the distinction between MCP servers and regular tool definitions passed directly via the API. Understand what an MCP server exposes (tools, resources, prompts) and how it communicates with clients.

See also: 2.4 MCP Server Integration

MCP Client

The component that connects to one or more MCP servers, discovers their capabilities, and forwards tool calls from Claude to the appropriate server. In Claude Code, the MCP client is built in. In custom applications, you implement the client using the MCP SDK.

Exam context: Questions may ask about the client’s responsibilities: capability discovery, transport management, and routing tool calls to the correct server. Know how a client handles multiple servers with overlapping tool names.

See also: 2.4 MCP Server Integration

MCP Transport

The communication layer between an MCP client and server. The two standard transports are stdio (communication over standard input/output, used for local processes) and streamable HTTP (communication over HTTP with server-sent events, used for remote servers). The transport is configured when connecting a client to a server.

Exam context: Know which transport to use in which scenario. stdio is simpler for local tools; streamable HTTP is necessary for remote or shared servers. The exam may ask about transport selection for specific deployment scenarios.

See also: 2.4 MCP Server Integration

JSON Schema

The specification used to define the structure of tool input parameters in the Claude API. Each tool’s input_schema is a JSON Schema object that specifies property types, required fields, enums, and descriptions. Claude uses this schema to generate valid tool call inputs.

Exam context: You need to read and write JSON Schema fluently. Common exam traps include confusing required (an array at the object level) with individual property attributes, and forgetting that additionalProperties: false prevents unexpected fields.

See also: 2.1 Tool Interface Design

Tool Selection

The process by which Claude decides which tool to call based on the user’s request and the available tool schemas. Claude evaluates tool names and descriptions to find the best match. When many tools are available, clear and distinct descriptions become critical for accurate selection.

Exam context: The exam tests strategies for improving tool selection accuracy: descriptive naming, non-overlapping tool descriptions, and reducing the number of tools presented at any one time. Know the concept of tool filtering or routing to narrow down available tools.

Tool Routing

A technique for directing tool calls to the correct handler when multiple tools or MCP servers are available. Routing can happen at the application level (filtering which tools Claude sees based on context) or at the model level (Claude selecting from available tools). Application-level routing reduces ambiguity and improves selection accuracy.

Exam context: Know the difference between letting Claude choose from all tools versus pre-filtering by request type. Do not reach for a routing layer as the fix for a large tool set — the exam keys that wrong. An oversized toolkit is a distribution problem: split into role-scoped agents, or consolidate variants of one job into a parameterised tool.

Resources (MCP)

Read-only data sources exposed by an MCP server. Unlike tools (which perform actions), resources provide contextual information that can be loaded into Claude’s context. Examples include file contents, database records, or documentation. Resources are identified by URIs and can be listed and read by the client.

Exam context: Understand the distinction between MCP resources and tools. Resources are for reading data; tools are for performing actions. The exam may test when to use a resource versus a tool for data retrieval.

See also: 2.4 MCP Server Integration

Prompts (MCP)

Reusable prompt templates exposed by an MCP server. These are pre-defined message sequences that a client can retrieve and use to interact with Claude in standardised ways. Prompts can include arguments that customise the template at runtime.

Exam context: This is a less frequently tested concept, but you should know that MCP servers can expose prompts alongside tools and resources. Understand the three capability types: tools, resources, and prompts.

See also: 2.4 MCP Server Integration

Tool Error Handling

Strategies for managing failures when a tool call returns an error or unexpected result. Best practices include returning is_error: true in the tool_result with a descriptive error message, so Claude can decide how to recover. Never silently swallow errors — Claude needs to know what went wrong to adjust its approach.

Exam context: The exam tests error reporting patterns. Know that is_error: true in a tool_result tells Claude the call failed, and that the error message should be actionable so Claude can retry or take an alternative approach.

See also: 2.2 Structured Error Responses

Domain 3 — Claude Code Configuration & Workflows

CLAUDE.md

A markdown file that provides persistent instructions to Claude Code. It acts as a project-level system prompt, loaded automatically when Claude Code starts in a directory. CLAUDE.md files can exist at multiple levels (user home, project root, subdirectories) and every applicable file is concatenated into context — none overrides another, and if two rules contradict, Claude may pick one arbitrarily.

Exam context: This is heavily tested. Know the three scopes (user, project, directory), that files concatenate in a documented load order rather than overriding, and that both root CLAUDE.md and .claude/CLAUDE.md are valid, version-controlled project-level locations.

See also: 3.1 CLAUDE.md Hierarchy

Hooks

Custom scripts that run at specific points during Claude Code’s execution lifecycle. Hooks can trigger before or after tool calls, on notification events, or when a session starts. They are defined in the settings.json configuration and run as shell commands on your local machine.

Exam context: Know the available hook types (PreToolUse, PostToolUse, Notification, etc.), how to configure them, and that a PreToolUse hook can block a tool call before it executes. Hooks are deterministic code, not prompt instructions, so they cannot be bypassed by model reasoning.

See also: 1.5 Agent SDK Hooks

Permissions

The security system that controls which tools and operations Claude Code can execute. Permissions operate on an allowlist/denylist model — you can explicitly permit or deny specific tools, file paths, and commands. The default mode requires user confirmation for potentially destructive operations.

Exam context: Know the permission modes (default, acceptEdits, plan, bypassPermissions, plus auto, dontAsk, and manual as an alias for default) and the allow/deny rule patterns. Understand which operations require confirmation by default and how to configure auto-approval for trusted operations.

See also: 3.6 CI/CD Integration

Slash Commands

Custom reusable commands defined as markdown files in the .claude/commands/ directory. When a user types / in Claude Code, available slash commands appear as options. Each command file contains a prompt template that can include $ARGUMENTS placeholders for dynamic input. Commands and skills have been merged into one system: a command is a flat .md file, while a skill is a directory with a SKILL.md entrypoint, and both create /commands.

Exam context: Know where slash command files live (.claude/commands/ for project-level, ~/.claude/commands/ for user-level), the file naming convention, how $ARGUMENTS substitution works, and the file-structure difference from skills.

CI/CD Integration

Running Claude Code in non-interactive mode within continuous integration and deployment pipelines. This uses the claude -p flag for single-prompt mode or piped input. It typically needs credentials configured for the environment and runs with --allowedTools to restrict available operations.

Exam context: The exam tests how to configure Claude Code for headless environments. Know the flags (-p, --output-format json) and how to restrict tool access in automated pipelines. Note that the guide’s out-of-scope list excludes Claude API authentication and billing, so credential mechanics are not tested.

See also: 3.6 CI/CD Integration

settings.json Precedence

The hierarchy that controls Claude Code’s settings.json behaviour. Settings can be defined at the project level (.claude/settings.json), user level (~/.claude/settings.json), or enterprise level. More specific scopes override broader ones, with enterprise settings taking the highest priority.

Exam context: Understand how settings.json layers merge and which one wins. Do not carry this override model across to CLAUDE.md files: those are concatenated into context rather than overriding one another, and “more specific scope wins” is a keyed distractor there.

See also: 3.6 CI/CD Integration

Allowlist/Denylist

Permission configuration patterns for controlling tool access. An allowlist names the tools that may run (in permission settings, everything unnamed still prompts rather than being silently denied). A denylist specifies which tools are blocked (everything else is permitted). These are configured in settings.json under the permissions key.

Exam context: Know when to use an allowlist versus a denylist. Allowlists are the tighter default for unattended pipelines. Denylists are more permissive. Note the related trap: a skill’s allowed-tools frontmatter pre-approves tools rather than restricting them — disallowed-tools and permission deny rules are the actual boundary.

See also: 3.6 CI/CD Integration

settings.json

The JSON configuration file that controls Claude Code’s behaviour, including permissions, hooks, MCP servers, and model preferences. It can exist at the project level (.claude/settings.json) or user level (~/.claude/settings.json). Project-level settings are typically committed to the repository.

Exam context: Know the key configuration sections (permissions, hooks, mcpServers) and the file’s location at different scopes. Understand that project-level settings apply to all team members who clone the repo.

See also: 3.1 CLAUDE.md Hierarchy

.claude Directory

A directory at the project root that stores Claude Code’s project-level configuration. It contains settings.json (committed to the repo for shared team settings), settings.local.json (git-ignored for personal settings), and the commands/ subdirectory for slash commands.

Exam context: Know what goes in .claude/ versus what stays in the project root. Understand which files are committed (settings.json, commands/) and which are local-only (settings.local.json).

See also: 3.1 CLAUDE.md Hierarchy

Subagents

Separate Claude Code instances spawned by the main agent using the Task tool to handle specific, scoped pieces of work. Each subagent runs in its own context with its own tool access, preventing context pollution in the main conversation. The main agent coordinates subagents and aggregates their results.

Exam context: Know when to use subagents versus handling everything in the main conversation. Subagents are useful for parallel tasks, large codebases, or when you want to isolate a task’s context. Understand that subagents do not share memory with the parent.

Domain 4 — Prompt Engineering & Structured Output

System Prompt

The initial instruction message sent to Claude with the system parameter in an API call. It sets the overall behaviour, persona, constraints, and output format for the conversation. System prompts are not part of the message history — they sit above it and persist across all turns.

Exam context: Know the difference between system prompts and user messages. The exam tests system prompt best practices: clear role definition, explicit constraints, output format specification, and avoiding conflicting instructions.

See also: 4.1 System Prompts

Structured Output

A technique for getting Claude to return responses in a specific, machine-parseable format such as JSON, XML, or YAML. This is achieved through explicit format instructions in the prompt, JSON Schema definitions, or tool-use schemas.

Exam context: The exam tests two approaches to structured output: prompt-based instructions and tool-use schemas. Know the trade-offs, and know that tool-use schemas eliminate syntax errors without preventing semantic ones.

Current state (checked 14 August 2026): the API-level control for constrained output is now output_config.format (structured outputs), which the guide does not cover.

See also: 4.3 Structured Output

Prompt Chaining (Domain 4 cross-reference)

An orchestration technique where the output of one Claude call becomes the input to the next. Each step in the chain has a focused, specific task. Chaining decomposes a complex problem into manageable steps and allows for validation or transformation between steps.

Exam context: Know when to use prompt chaining versus a single prompt. The exam tests the principle that each link in the chain should do one thing well. Understand how to pass context between chain steps and where to insert validation gates.

Scope note: the exam guide places prompt chaining under Task Statement 1.6, not Domain 4.

See also: 4.4 Validation-Retry Loops

Few-Shot Examples

Input-output pairs included in the prompt to demonstrate the desired behaviour, format, or reasoning pattern. By showing Claude concrete examples of correct responses, you reduce ambiguity and improve consistency. Few-shot examples are placed in the system prompt or user message before the actual request.

Exam context: Know best practices for few-shot examples: use diverse examples that cover edge cases, place them before the request, and match the exact format you want in the output. The exam may test how many examples are typically needed (2-4 targeted examples; more than 4 wastes tokens).

See also: 4.2 Few-Shot Prompting

Prompt Optimisation

The iterative process of refining prompts to improve output quality, reduce costs, and increase reliability. Techniques include simplifying instructions, removing ambiguity, adding constraints, and testing against a set of evaluation cases.

Exam context: The exam tests systematic approaches to prompt improvement rather than ad-hoc tweaking. Know the evaluation-driven workflow: define test cases, measure baseline performance, make targeted changes, and measure again.

See also: 4.5 Batch Processing

Output Validation

Programmatic checks applied to Claude’s responses to verify they meet expected criteria before being used downstream. Validation can check format (valid JSON, correct schema), content (required fields present, values within ranges), and safety (no prohibited content). Failed validation triggers a retry or fallback.

Exam context: Know the common validation strategies: schema validation (JSON Schema, Zod, Pydantic), content checks, and review by an independent Claude instance without the generation context (same-session self-review retains reasoning bias and is a keyed exam trap). Understand how validation fits into an agentic loop.

See also: 4.4 Validation-Retry Loops

Prefilling

Starting Claude’s response by supplying the opening of the assistant message, historically used to force a response into a given format.

Current state (checked 14 August 2026): a trailing assistant-turn prefill is rejected with an HTTP 400 on every current Claude model. The word “prefill” appears nowhere in the exam guide, so it is not a tested technique either. It is listed here only so you recognise the term if you meet it in older material; the documented replacement is output_config.format.

See also: 4.3 Structured Output

XML Tags

Delimiters used within prompts to structure content into clearly labelled sections. Claude is trained to understand XML-style tags like <instructions>, <context>, and <examples>. Using tags makes prompts more readable and helps Claude identify the purpose of each section.

Exam context: “XML” appears nowhere in the exam guide, so do not expect a keyed item on tag syntax. The underlying practice is genuine Anthropic guidance and worth knowing: tagged sections reduce misinterpretation of prompt boundaries.

See also: 4.1 System Prompts

Chain of Thought

A prompting technique that instructs Claude to show its reasoning step by step before arriving at a final answer. This improves accuracy on complex tasks by forcing the model to work through the problem methodically. Chain of thought can be elicited by adding instructions like “think step by step” or by using extended thinking.

Exam context: Know when chain of thought helps (complex reasoning, multi-step problems) and when it is unnecessary (simple factual retrieval). Understand the relationship between chain of thought prompting and Claude’s extended thinking feature.

See also: 4.1 System Prompts

Temperature

A sampling parameter that historically controlled the randomness of Claude’s responses. Lower temperatures (e.g., 0.0) produce more deterministic, focused output. Higher temperatures (e.g., 0.8) produce more varied, creative output. The default is 1.0.

Exam context: “Temperature” appears nowhere in the exam guide — not in any task statement, not in the appendix — so do not expect it to be keyed. It does appear as a distractor in this domain’s bank, and is never the answer.

Current state (checked 14 August 2026): temperature, top_p and top_k are rejected with an HTTP 400 on current Claude models. Steer behaviour with prompting instead.

See also: 4.5 Batch Processing

Domain 5 — Context Management & Reliability

Context Window

The maximum number of tokens (input plus output) that Claude can process in a single API call. Everything in the conversation — system prompt, message history, tool definitions, and the response — must fit within this limit.

Current state (checked 14 August 2026): context-window size is model-specific, not a single figure. Current Claude models range from 200K tokens (Haiku 4.5) to 1M (Sonnet 5, Opus 5, Fable 5). The exam guide states no window size anywhere in Domain 5, and nothing in the bank keys on the number — treat any specific figure in a scenario as a constraint that scenario sets, not a property of the model.

Exam context: The exam tests strategies for staying within limits: progressive summarisation, message pruning, and content prioritisation. Know the trap in progressive summarisation — repeated compression can drop the specific facts a later step needs.

See also: 5.1 Context Window Management

Token Counting

The process of measuring how many tokens a prompt or response consumes. The API response includes input_tokens and output_tokens in the usage field. Accurate token accounting is essential for context window management.

Exam context: Know how to read the usage field and that token counts include all content (system prompt, messages, tool definitions). Tokenisation algorithms and per-character ratios are explicitly out of scope — the guide’s out-of-scope list excludes “token counting algorithms or tokenization specifics”.

See also: 5.1 Context Window Management

Prompt Caching

An API feature that lets frequently reused prompt content be cached, reducing latency and cost on subsequent requests. Content is marked with a cache_control breakpoint (type: "ephemeral", roughly five-minute TTL) placed at the end of the static block — system prompt, tool definitions, large documents — with dynamic content ordered after it. Cache hits are charged at a reduced rate.

Exam context: Know that caching exists, the static-then-dynamic ordering requirement, and the breakpoint placement at the end of the static prefix. The guide’s out-of-scope list excludes “prompt caching implementation details (beyond knowing it exists)”, so depth beyond this is not tested.

See also: 5.1 Context Window Management

Escalation Triggers

The conditions under which an agent should hand a case to a human rather than continue autonomously. The valid triggers are: the customer explicitly asks for a human (honour it immediately, without attempting investigation first), the policy has a gap or exception the agent cannot resolve, and the agent cannot make meaningful progress.

Exam context: Sentiment-based escalation and self-reported confidence scores are unreliable proxies for case complexity — options built on them are distractors. When a customer is frustrated but the issue is within the agent’s capability, acknowledge the frustration and offer to resolve, escalating only if they reiterate their preference.

See also: 5.2 Escalation & Ambiguity

Policy Gap vs Policy Violation

The distinction between a request the policy does not address (a gap) and a request the policy forbids (a violation). A gap — for example, competitor price matching when the policy only covers own-site adjustments — warrants escalation because the agent has no authority to decide. A violation warrants a clear refusal with the policy explanation.

Exam context: The exam tests recognising that ambiguous or silent policy means escalate, not improvise. When tool results return multiple customer matches, ask for additional identifiers rather than selecting by heuristic.

See also: 5.2 Escalation & Ambiguity

Structured Error Context

The error-reporting pattern that lets a coordinator make intelligent recovery decisions: failure type, the attempted query, any partial results, and potential alternative approaches. Generic statuses like “search unavailable” hide the context the coordinator needs.

Exam context: Both silently suppressing errors (returning empty results as success) and terminating an entire workflow on a single failure are anti-patterns. Subagents should recover locally from transient failures and propagate only what they cannot resolve, with partial results attached.

See also: 5.3 Error Propagation

Access Failure vs Valid Empty Result

The distinction between a query that could not run (timeout, auth failure — a retry decision is needed) and a query that ran successfully and found nothing (the absence of data is the answer). Error reporting must distinguish the two so the coordinator can respond appropriately.

Exam context: Treating a valid empty result as an error, or an access failure as “no results”, are both keyed wrong answers. Synthesis output should carry coverage annotations marking which findings are well-supported and which areas have gaps from unavailable sources.

See also: 5.3 Error Propagation

Context Degradation

The failure mode of extended exploration sessions: the model starts giving inconsistent answers and referencing “typical patterns” instead of the specific classes and files it discovered earlier. It signals that the context window has filled with verbose discovery output.

Exam context: The remedies are scratchpad files, subagent delegation to isolate verbose output, summarising each exploration phase before starting the next, and /compact to reduce context usage mid-session.

See also: 5.4 Codebase Exploration

Scratchpad Files

Files an agent maintains to persist key findings across context boundaries during large codebase exploration. The agent records discoveries as it goes and re-reads the scratchpad for later questions, counteracting context degradation.

Exam context: Also know the crash-recovery variant: each agent exports structured state to a known location, and the coordinator loads a manifest on resume and injects it into agent prompts.

See also: 5.4 Codebase Exploration

Stratified Sampling

Randomly sampling high-confidence extractions for human review, stratified by document type and field, to measure true error rates and catch novel error patterns. It guards against the trap of aggregate metrics: 97% overall accuracy can mask poor performance on a specific document type or field.

Exam context: Validate accuracy by segment before automating high-confidence extractions. Options that trust the aggregate number, or stop reviewing high-confidence items entirely, are distractors.

See also: 5.5 Human Review & Calibration

Confidence Calibration

Checking model-reported confidence against actual accuracy using a labelled validation set, then setting review thresholds from the calibrated scores. Field-level confidence scores route limited reviewer capacity to where it matters: low-confidence extractions and ambiguous or contradictory source documents.

Exam context: Raw self-reported confidence is not trustworthy on its own — calibration against labelled data is the keyed step before using confidence for routing.

See also: 5.5 Human Review & Calibration

Claim-Source Mapping

A structured record tying each claim to its source (URL, document name, relevant excerpt) that must be preserved and merged through every synthesis step. Attribution is lost when findings are compressed without carrying these mappings along.

Exam context: When credible sources conflict, annotate the conflict with both attributions rather than arbitrarily selecting one value; the coordinator decides how to reconcile. Reports should separate well-established findings from contested ones.

See also: 5.6 Information Provenance

Temporal Annotation

Requiring publication or data-collection dates in structured outputs so that figures from different periods are not misread as contradictions. A 2023 statistic and a 2026 statistic that differ are a temporal change, not a conflict.

Exam context: The keyed pattern is to include dates in subagent outputs and preserve them through synthesis, letting consumers interpret differences correctly.

See also: 5.6 Information Provenance

Rate Limits & Quotas (out of scope)

API throughput controls (requests or tokens per minute, returning 429 when exceeded) and billing-period usage caps. Worth knowing they exist — but the exam guide’s out-of-scope list states that “rate limiting, quotas, or API pricing calculations” will not appear on the exam.

Exam context: If an option hinges on rate-limit handling strategy in a Domain 5 question, treat it with suspicion; a 429 appears in this domain only as an example of an access failure (retry with Retry-After), never as a topic of its own.

Batches API

An API endpoint for submitting large volumes of requests for asynchronous processing at a 50% cost reduction, with completion inside a 24-hour window but no guaranteed turnaround time. Ideal for offline bulk work; wrong for real-time or user-facing flows.

Exam context: Batch processing is tested in Domain 4, not Domain 5 — know the cost figure, the window, and the no-guarantee trade-off.

See also: 4.5 Batch Processing