Study guide

The biggest domain, and the one beginners most often get backwards. An agent, in this exam's sense, is a loop: Claude reads context, decides on an action (call a tool, ask a question, or stop), the result is fed back in, and it repeats until the task is done. A deterministic workflow is the opposite instinct — you, the architect, hard-code the steps and only let Claude fill in the reasoning inside each step.

The exam wants you to know when to choose which, not just define them. Reach for a fixed workflow when the steps are known in advance and repeat the same way every time — it's cheaper, faster, and its failure modes are easy to test for. Reach for an agent loop when the path genuinely can't be known ahead of time (the right next step depends on what a tool call just returned) — but know that this buys nondeterminism, extra latency, and real dollar cost per retry, so don't reach for it just because it's more impressive.

• Multi-agent patterns: a lead agent that plans and delegates to narrower sub-agents does better on broad, parallelizable research-style tasks; a single agent with a big tool set does better when steps are tightly coupled and order-dependent, since sub-agents can't easily share intermediate reasoning.
• State preservation: anything that must survive a crash, a restart, or a context-window compaction (see domain 5) needs to live outside the conversation — on disk, in a database, in a ticket — not just "in Claude's head" for that turn.
• Human review integration: the exam rewards designs that put a person in the loop before irreversible or high-cost actions (sending money, deleting data, publishing publicly), not designs that maximize autonomy for its own sake.

This domain is about the concrete knobs Claude Code actually has, and picking the right one for a given audience. A beginner mental model: instructions and permissions can live at several scopes, from "just me, just this repo" up to "everyone on this team, every repo." The exam's recurring theme is choosing the narrowest scope that reliably reaches the people who need it — not the broadest one available.

• CLAUDE.md files: project-level instructions checked into the repo (shared with the whole team) versus user-level settings that are personal and don't belong in version control — know which facts belong in which place.
• Commands and skills: reusable, named procedures you invoke on demand, versus hooks, which fire automatically on an event (a tool call, a session start) whether or not anyone asked for them — hooks are the right answer whenever a rule must never be skippable by a bad or lazy prompt.
• Permissions: the exam tests whether you'd grant broad standing access versus scoping a permission to exactly the tool and path a task needs, then re-evaluating it, not leaving it wide forever.
• Headless operation & CI/CD: running Claude Code non-interactively (no human watching each turn) raises the bar on what must be automatic — logging, exit codes, and failure alerts have to work without anyone there to notice a stuck session.

The core beginner mistake this domain probes for: treating a prompt as the only line of defense for getting a reliable, parseable answer out of a model. A system prompt with good examples raises the odds of correct-shaped output; it does not guarantee it. The exam wants the combination: clear instructions and examples plus a schema, plus deterministic code that validates the actual response before anything downstream trusts it.

• System prompts and examples: a few well-chosen examples (few-shot) that show the exact output shape you want usually beats a longer paragraph of abstract rules.
• XML-style organization: wrapping distinct pieces of context (instructions, retrieved documents, prior turns) in clearly-tagged sections helps Claude tell them apart — especially important once you're stuffing in content from outside sources, which should never be confused with instructions from the operator.
• Output constraints and validation: ask for a specific schema, then actually check the response against it in code (not just by eye) before using it; on a real mismatch, prefer a bounded retry with the specific validation error fed back over silently guessing or crashing.
• Decision boundaries: know where "just prompt it better" stops working and the right fix becomes a tool, a schema, or a code-level check instead — the exam rewards recognizing that boundary, not pushing prompt tweaks indefinitely.

A "tool" is just a function Claude can choose to call — but the exam treats tool design, not just tool use, as its own skill. MCP (Model Context Protocol) is the standard way to package and expose those capabilities to any compatible client, and it distinguishes three different things that beginners often lump together: tools (actions with side effects, like sending an email), resources (read-only data the model can pull in, like a file or a database row), and prompts (reusable, parameterized instruction templates a user or client can invoke).

• Naming and descriptions: a tool's name and description are the only information Claude has to decide when to call it — vague names like do_thing or overlapping tools that do almost-the-same-thing cause wrong calls, even with a perfect underlying implementation.
• Input schemas: tight, specific schemas (enums over free strings where possible) cut down on malformed calls before they ever run.
• Output contracts: a tool should return something a model can actually reason from — structured, consistently-shaped results, not a raw dump that changes format depending on internal state.
• Failure behavior: a tool that fails should say so clearly (a distinct error field or message) rather than returning something that looks like a valid success — the exam treats "fails loudly and legibly" as strictly better than "fails silently."
• Permissions per tool: scope what each tool is allowed to touch as narrowly as the task allows, same theme as domain 2.

The smallest domain by weight but the one that quietly underlies all the others: a context window is finite, and everything you put in it — conversation history, tool results, retrieved documents — competes for the same limited space and the model's limited attention. The exam's core distinction here is durable state versus transient conversation: anything that must be true next week shouldn't live only in this session's chat history, it should be written to disk, a database, or a ticket — the same idea as state preservation in domain 1, seen from the context-budget side instead of the crash-recovery side.

• Compaction: when a conversation gets long, older turns get summarized or dropped rather than kept verbatim forever — know that this is lossy by design, so anything load-bearing needs to be re-derivable from what's left, not buried in a turn that might get compacted away.
• Retrieval: pull in only the specific slice of a large corpus that's relevant to the current step, rather than stuffing an entire document set in up front "just in case."
• Prompt caching: reusing a stable prefix (system prompt, tool definitions, a large fixed document) across calls cuts cost and latency — but only if that prefix genuinely doesn't change turn to turn, so structure prompts with the stable part first and the variable part last.
• Escalation and confidence handling: a well-designed agent recognizes when it's uncertain or stuck and hands off to a human rather than guessing forward — the exam rewards designs with an explicit escalation path, not ones that assume the model will always know when it's wrong.