CCDV-F · module 3 of 8 · 14.7% of the exam

Agents and workflows

Weight: 14.7 percent of the exam. Tests whether you can tell a workflow from an agent, pick the right pattern for a stated problem, and build agents with the Agent SDK's loop, tools, subagents, hooks, sessions, and permissions.

What the exam expects

This domain rewards restraint. The single most common wrong answer is an agent where a workflow would do, and the second most common is a subagent where two inline tool calls would do. Anthropic's own guidance is explicit that you should start with the simplest thing that works and add agency only when a simpler approach demonstrably falls short, because agents trade latency and cost for task performance.

Expect three kinds of question. Pattern-matching questions ask which workflow pattern fits, where the answer turns on one distinguishing property in the scenario. Justification questions ask whether agency is warranted at all. Mechanism questions test the Agent SDK primitives: what a subagent inherits, when a hook runs versus a permission callback, what resume does that fork does not.

Workflows versus agents

The definition is precise and the exam uses it literally.

• A workflow is a system where LLMs and tools are orchestrated through predefined code paths. Your code decides what happens next.
• An agent is a system where the LLM dynamically directs its own processes and tool usage. The model decides what happens next.

Notice what is not part of the definition. Using tools does not make something an agent; workflows call tools constantly. Making several model calls does not make something an agent; a three-link chain is still a chain. The only question is who chooses the next step.

The five workflow patterns

Each pattern has one distinguishing precondition. Learn the preconditions, not the diagrams, because that is what the scenario will state.

Two pairs are routinely confused and both confusions are tested.

Sectioning versus orchestrator-workers. Both fan out. The difference is whether you knew the subtasks before you saw the input. Three fixed checks on every post is sectioning. "However many files turn out to need editing" is orchestrator-workers.

Sectioning versus voting. Both run things in parallel. Sectioning divides different work; voting repeats the same work to raise confidence. Using voting to choose a category is a classic wrong answer, since a cheap classifier does that directly at a third of the cost.

Evaluator-optimizer has a precondition people skip: the criteria must be concrete enough to grade against. An evaluator asked whether output is "high quality and useful" produces generic feedback, the loop runs to its cap every time, and nothing improves. When a scenario describes exactly that symptom, the fix is specific checkable criteria, not more iterations.

Deciding whether to build an agent

Before choosing the agent tier, check four criteria:

• Complexity. Is the task multi-step and genuinely hard to specify in advance?
• Value. Does the outcome justify higher cost and latency?
• Viability. Is Claude capable at this task type?
• Cost of error. Can mistakes be caught and recovered from, through tests, review, or rollback?

If any answer is no, stay simpler. The inverse signals are equally testable: steps that are the same for every input, and errors that are hard to detect and expensive to reverse, both argue for keeping control in code.

The classic over-engineering scenario: a team builds an autonomous agent for a task with exactly one known sequence, say extract three fields from a PDF and write a database row. In production it sometimes writes twice, sometimes skips the write, and costs several times the estimate. The right answer is never a stronger system prompt, a bigger model, or an evaluator loop on top. It is a deterministic pipeline, one structured-output call then a write performed by application code, which makes both failure modes impossible by construction.

Choosing your surface

Four ways to build, and the exam expects you to distinguish them:

The Agent SDK (claude-agent-sdk in Python, @anthropic-ai/claude-agent-sdk in TypeScript) is Claude Code packaged as a library. You call query(prompt, options) and it supplies the agent loop, context management, and built-in tools for reading, writing, and editing files, running commands, searching, and fetching the web. It ships for Python and TypeScript only; to drive the same harness from another language, run the CLI as a subprocess in headless mode with a prompt flag and JSON output.

Agent SDK primitives

Subagents are the context-management workhorse. Define them through the agents option, giving each a description (how Claude decides when to invoke it), a prompt (its system prompt), and optionally tools, model, and permissionMode. Their benefits are context isolation, parallelism, specialised instructions, and tool restriction.

The contract you must know: a subagent's context starts fresh. It does not receive the parent's conversation history or tool results. The only thing that crosses the boundary is the prompt string you pass it, and only its final message returns to the parent. A prompt like "review the file we discussed for the bug described above" therefore resolves to nothing, and this is the most commonly tested subagent mistake. Subagent transcripts are also stored separately and survive the parent's compaction.

Subagents are not free. Each re-establishes context and reports back, so delegating one file read and one edit costs more than doing it inline. Use them for wide exploration whose intermediate results are disposable, and for independent tracks that run concurrently.

Hooks run your code at points in the agent lifecycle. The events include PreToolUse, PostToolUse, UserPromptSubmit, SubagentStop, PreCompact, SessionStart, SessionEnd, and Notification, registered under options.hooks with a matcher that filters which calls fire them. A PreToolUse hook can inspect the tool input and return hookSpecificOutput with permissionDecision set to allow, deny, or ask, plus a permissionDecisionReason the model sees, and it can rewrite arguments with updatedInput.

Permissions are evaluated in a fixed order, and the order decides several exam questions: hooks first, then deny rules, then ask rules, then the permission mode, then allow rules, then your canUseTool callback. Modes include default, plan (explore without auto-approving edits), acceptEdits, dontAsk, and bypassPermissions.

Two consequences of that ordering are heavily tested. allowedTools grants approval, it does not restrict availability. An unlisted tool still exists and falls through to the permission mode, so pairing allowedTools with bypassPermissions does not constrain anything. Use disallowedTools or a hook. And auto-approved calls never reach canUseTool, so any check that must run on every call, such as audit logging, belongs in a PreToolUse hook, which runs before every other step and whose denial holds even under bypassPermissions.

Sessions persist the conversation to disk. continue picks up the most recent session in the directory. resume takes a specific session ID, which is what a multi-user application needs, and the ID is available on the result message. fork creates a new session seeded with a copy of the history while leaving the original untouched and separately resumable, which is the tool for exploring an alternative without losing the first thread. Forking branches the conversation, not the filesystem, so file edits either branch makes are real and shared.

Managing context across turns

Three mechanisms, three distinct jobs. Confusing them is a reliable exam question.

• Compaction summarizes earlier conversation so a session can continue past what would otherwise exceed the window. The surviving content is a paraphrase.
• Context editing clears stale tool results or thinking blocks. It prunes rather than summarizes, so what remains keeps its exact fidelity.
• Memory persists information across sessions, which neither of the other two does.

None of them enlarges the model's context window. They change what you send within a fixed window. And max_tokens is unrelated to all three, since it caps output.

Two protocol details round out the domain. When one assistant turn contains several tool_use blocks, all their results must return in a single user message; splitting them silently trains the model out of parallel tool calls. And stop_reason: "pause_turn" means the server-side tool loop hit its iteration limit: re-send the conversation with the paused assistant turn appended so it resumes, and cap continuations.

How to think through the question

Step 1: find the sentence that says whether the steps are knowable. Scenarios telegraph this. "Always the same, always in that order" is a workflow. "Cannot be known until the codebase is inspected" is orchestrator-workers or an agent. "Two files or forty depending on the request" is the same signal in numeric form.

Step 2: check for a cost-of-error clause. "Expensive to unwind," "writes to production," "no human watching" pushes toward code-controlled paths and structural enforcement. "Covered by tests and easy to roll back" makes agency safer.

Step 3: decide what the question is really asking. Pattern selection, justification, or mechanism. For mechanism questions, resist reasoning from what would be convenient and recall the actual contract, especially for subagent inheritance and permission ordering.

Step 4: eliminate options that add agency the scenario does not need. If every input goes through every step, there is nothing to decide, so any option letting the model choose the order is over-engineering.

Step 5: eliminate options that enforce a hard requirement through prose. When a scenario says "must never" or "compliance requires," an answer that adds a system prompt instruction is wrong by construction. The right answer is structural: a hook, a deny rule, a permission mode, or moving the action into code.

Worked example

A security team requires that an agent can never write to files matching a secrets pattern. The rule currently lives in the system prompt. An audit finds two writes to matching paths.

Step 1: this is a mechanism question, not a pattern question, so the steps are irrelevant.

Step 2: the cost-of-error clause is absolute ("can never"), which tells you the answer must be an enforced boundary rather than a behavioural nudge.

Step 3: the question asks what to implement, so we need the control, not a diagnosis.

Step 4: nothing here is about excess agency, so this filter does not apply.

Step 5: this is decisive. An option offering stronger, more emphatic system prompt language is the failing approach with more capital letters, and aggressive imperative phrasing tends to overtrigger elsewhere while still guaranteeing nothing. A PostToolUse hook that deletes the file afterwards is disqualified for a different reason: the secret was already written to disk, so the control acts too late. A restricted subagent limits which tools exist but does not inspect the path argument of a write it is allowed to make.

That leaves a PreToolUse hook matching the file-writing tools, inspecting the path, and returning permissionDecision: "deny" with a reason. It runs before the call executes and before the permission mode, so it holds regardless of how the rest of the configuration is set.

Exam traps

• "It calls tools, so it is an agent." Tempting because tool use feels autonomous. Workflows call tools; the question is who picks the next step.
• Reaching for an agent because the current chain is slow. Backwards, since agents trade latency and cost for capability. They are generally slower per request.
• Using voting where a classifier would do. Voting sounds rigorous and triples cost for a decision a cheap routing step makes directly.
• Delegating trivial work to a subagent to "keep the transcript clean." A subagent re-establishes context and reports back, so a one-read, one-edit task costs more delegated than inline.
• Assuming a subagent can see the parent's history. The most natural assumption in the domain, and false. Only the prompt string crosses.
• Trusting allowedTools to lock an agent down. It reads like an allow list in the restrictive sense. It only pre-approves; unlisted tools still fall through to the permission mode.
• Putting audit or security checks in canUseTool. Reasonable-looking, but auto-approved tools never reach it. Use a PreToolUse hook.
• Raising the iteration cap when an evaluator-optimizer loop never converges. Treats a signal problem as a budget problem; the criteria were too vague to grade against.
• Returning tool results in separate user messages. Feels tidier per tool, and quietly suppresses parallel tool use.
• Treating pause_turn as terminal. Produces truncated answers with no error, since the turn was resumable all along.

Quick reference