Augmented LLM
A single model call enhanced with retrieval, tools and memory. The basic building block of the taxonomy, and the right answer more often than its position at the bottom suggests: most problems need nothing more.
Exam context: Wrong options inflate a multi-call coded pipeline into an "augmented LLM" or shrink it into one. The number of calls is the clue: an augmented LLM is one enhanced call.
See also: 1.1 Agent Architecture
Workflow
A system where LLM calls and tools are orchestrated through predefined code paths. The developer wrote the control flow. The model executes inside it, which is what makes runs predictable, testable and cheaper. As of September 2026, Claude Code's dynamic workflows apply the same idea to multi-agent work. A script that Claude writes decides what runs next and holds the intermediate results. So Claude's context holds only the final answer.
Exam context: If a question names fixed, repeating, auditable steps, the workflow is the right answer, however capable the model in each step. A hand-coded chain is a workflow no matter how many model calls it contains.
See also: 1.1 Agent Architecture
Agent
A system in which the model directs its own process and tool usage, deciding each next step from environment feedback until the goal is met. The benefit is flexibility. The costs are latency, token spend, more chances of error and a guardrail burden.
Exam context: An agent is justified when the path genuinely cannot be scripted: unknown step count, decisions dependent on intermediate findings. The extra spend must give you something a workflow could not deliver.
See also: 1.1 Agent Architecture
Context Isolation
The property that a subagent's context window starts fresh, with no parent conversation. It is both a limit and a benefit: nothing reaches the worker except the delegation prompt, and nothing large returns to the lead agent except the worker's final message. As of October 2026 the one exception is a Claude Code fork, which inherits the whole conversation. Fork mode lets Claude start a fork on its own. From Claude Code v2.1.302, fork mode is on by default, including in the Agent SDK and -p runs. A deny rule for Agent(fork) in the permission settings stops forks.
Exam context: The most-tested fact in the domain. Some designs assume that workers see the orchestrator's conversation, or each other's findings when nothing sends those findings to them. These designs cannot work. The fix is always a fuller brief, never a respawn or a bigger model. Named subagents and agent teammates can message each other, but only through that explicit channel.
See also: 1.1 Agent Architecture
Delegation Prompt
The brief a subagent is spawned with: the only way the parent gives information to the worker. A production brief carries an explicit objective, an output format, tool guidance, task boundaries, and every convention or decision the worker must honour.
Exam context: Look for the cause of multi-agent failures in the orchestrator first. Overlapping scopes produce duplicated sections. An unassigned topic produces a gap. Both are faults in how the orchestrator divided the task, and you fix them in the briefs.
See also: 1.1 Agent Architecture
Agent Loop
The cycle every harness wraps: send the prompt with tool definitions; if the response requests tools, execute them, append the results, call again; stop when the model responds without tool calls or a cap is reached. The raw Messages API has no loop behaviour of its own.
Exam context: The loop's normal exit is a response containing no tool-use requests. There is no API-enforced iteration cap and no termination token. Limits exist only where the harness configures them.
See also: 1.2 Agent Construction with Claude
Turn
One pass through the agent loop: the model produces output, and it may include tool calls. The harness executes them and the results return to the model. The final text-only response is a turn too. The unit max_turns counts.
Exam context: Wrong options redefine a turn as a token count, a session count or a subagent count. It is one pass of the loop, nothing else.
See also: 1.2 Agent Construction with Claude
max_turns
The Claude Agent SDK option (maxTurns in TypeScript) capping the turns in a run: each turn with tool calls, plus one for the final text-only response. It defaults to no limit, and hitting it ends the run with the error_max_turns result subtype.
Exam context: The exam tests the exact name. Invented names that look plausible and are almost right (max_iterations, turn_cap) are the wrong options, and a cap that is reached is a configuration event, not a model failure.
See also: 1.2 Agent Construction with Claude
max_budget_usd
The Claude Agent SDK option (maxBudgetUsd in TypeScript) stopping a query when estimated spend reaches the set dollar value. Cumulative across the run, subagent spend included. The docs call it a good default for production agents.
Exam context: Context isolation does not mean cost isolation: subagent requests count toward total_cost_usd, spawns fail at the cap, and the run ends with error_max_budget_usd.
See also: 1.2 Agent Construction with Claude
ResultMessage
The final message of an Agent SDK run. Its subtype names the outcome: success, error_max_turns, error_max_budget_usd or error_during_execution (the docs list a fifth, error_max_structured_output_retries, as of August 2026). Every subtype carries total_cost_usd, num_turns and session_id. The result text is present only on success.
Exam context: Code that reads result without checking the subtype gets nothing useful on error runs. The documented recovery from a limit subtype is resuming the session with a raised cap, tightening the brief, or splitting the work.
See also: 1.2 Agent Construction with Claude
Harness
The code around the loop that production requires: turn caps, spend budgets, retries, tool-result validation, state persistence, observability. Execution guarantees belong here. Model behaviour belongs in the prompt.
Exam context: The exam tests whether a concern belongs in the harness or in the prompt. Prompted retries and prompted frugality are instructions the model may not follow; only the harness enforces.
See also: 1.2 Agent Construction with Claude
PreToolUse Hook
Code the harness runs before a requested tool call executes. It receives the tool name and input, and a deny permission decision blocks the call, with the reason returned to the model as the tool result.
Exam context: Prompts ask for a behaviour. Hooks enforce it. The hook executes deterministically in the application process regardless of what the model was persuaded to attempt, which is what makes it a guardrail rather than guidance.
See also: 1.2 Agent Construction with Claude
Claude Managed Agents
Anthropic's hosted agent product, distinct from the Agent SDK. Anthropic runs the agent harness and the sandbox behind a REST API. It provides stateful server-side sessions with minimal operational burden. In beta as of August 2026 (header managed-agents-2026-04-01), and the sandbox can be Anthropic-managed or self-hosted for data residency. As of September 2026, a self-hosted sandbox still sends tool inputs and outputs to Anthropic's control plane, and a session can be pinned to one agent version. Scheduled deployments run an agent on a cron schedule, and a coordinator agent delegates one level only, to a roster of at most 20 unique agents.
Exam context: Not "the SDK hosted for you". Questions test who operates the harness in each deployment model: self-hosting keeps control and burden; Managed Agents trades control for minimal operations.
See also: 1.2 Agent Construction with Claude
Prompt Chaining
The workflow pattern that decomposes a task into a fixed sequence where each call processes the previous output, optionally with programmatic gates between steps.
Exam context: A gate is a one-way pass/fail checkpoint that stops bad output propagating; it never feeds critique back. If a question has a fixed sequence and checkpoints, the right answer is chaining, not evaluator-optimizer.
See also: 1.3 Agent Patterns and Frameworks
Routing
The workflow pattern that classifies an input and dispatches it to a specialised follow-up: a different prompt, tool set or model per category.
Exam context: The cue is distinct input categories deserving distinct treatment. The tempting wrong answer is one handler for every input, or chaining, which fits one decomposable task rather than a stream of different ones.
See also: 1.3 Agent Patterns and Frameworks
Parallelization
The workflow pattern that runs LLM work simultaneously, in two forms: sectioning, where independent subtasks run at the same time, and voting, where the same task runs several times for diverse or confident answers.
Exam context: Sectioning requires subtasks known and independent in advance. Voting aggregates independent attempts in code, with no information flowing between them. It never refines an answer from one attempt to the next.
See also: 1.3 Agent Patterns and Frameworks
Orchestrator-Workers
The workflow pattern where a central model breaks the task down at runtime and delegates to workers. The pattern behind subagent architectures; its identifying feature is that the subtasks are not known in advance.
Exam context: The most common wrong option when the right answer is sectioning, and the reverse. What separates the two patterns is who decides the subtasks and when: subtasks that you can list in advance mean sectioning; discovered at runtime by the model means orchestrator-workers.
See also: 1.3 Agent Patterns and Frameworks
Evaluator-Optimizer
The workflow pattern pairing a generator with an evaluator that scores output against explicit criteria and feeds the critique back until the result passes, usually under a hard round cap.
Exam context: The right answer when the question has explicit criteria plus iterative, critique-driven refinement. Voting is the adjacent wrong option (no feedback between attempts) and the gate is the other (pass/fail without regeneration).
See also: 1.3 Agent Patterns and Frameworks
Memory Tool
Anthropic's cross-session persistence mechanism, generally available on the Messages API as tool type memory_20250818. Claude gets create, read, update and delete operations over files in a /memories directory that the application executes client-side. The application's handler carries the safeguards: it must reject paths outside /memories, and the docs suggest capping how much a view returns, with view_range for the rest.
Exam context: An agent remembers nothing between sessions unless the design adds a mechanism. Wrong options rely on automatic recall, longer conversations or bigger windows; the right answer persists state explicitly.
See also: 1.3 Agent Patterns and Frameworks
Context Rot
The degradation of recall as a context window's token count grows, named in Anthropic's context-engineering guidance. The reason long-running agents need a design answer rather than a bigger window.
Exam context: The documented answers are compaction (the Agent SDK performs it automatically), structured note-taking, and sub-agent architectures. On the Messages API, as of September 2026, compaction comes in on-demand and token-threshold forms, and the docs recommend on-demand wherever it is available. Domain 1 tests the design choice; the window-management technique detail belongs to Domain 6.
See also: 1.3 Agent Patterns and Frameworks
LangGraph
A low-level orchestration framework and runtime for long-running, stateful agents, from LangChain Inc but usable without LangChain. Control flow is modelled explicitly as a graph: deterministic and model-driven steps mixed, durable resumable execution, inspectable state.
Exam context: The right answer for needs that put graphs, statefulness and inspection first. Recommending it for typed output validation is the classic mistake of mixing up two frameworks.
See also: 1.3 Agent Patterns and Frameworks
Pydantic AI
The typed Python agent SDK from the Pydantic team: give the agent an output type and every run comes back validated against it.
Exam context: The right answer for schema-validated, typed outputs in Python. Graph-shaped control flow is what LangGraph is for, not Pydantic AI, and Pydantic AI is not built for TypeScript.
See also: 1.3 Agent Patterns and Frameworks
Strands Agents
An open-source agent SDK for Python and TypeScript. It was built from production systems inside Amazon. It takes a model-driven approach: the model drives the loop and orchestration code stays minimal.
Exam context: The right answer for a model-driven loop with minimal orchestration, often with an AWS-ecosystem clue in the question. The mistake to watch for: schema-validated outputs are what Pydantic AI is for, not Strands.
See also: 1.3 Agent Patterns and Frameworks