Agents and Workflows

What this domain tests

14.7% — about 8 of the 53 scored items. Third-heaviest on CCDV-F, behind Applications and Integration and Model Selection.

The three published skills carry nearly equal weight, which is unusual and tells you not to over-invest in any one:

A warning about study overlap. The Architect certification also has an agentic domain, and there is real shared material — the loop, hooks, subagent context isolation. But two things in this blueprint are distinctly CCDV-F and appear nowhere in the Architect guide:

• Managed agent deployment models — self-hosted versus Anthropic-hosted (under Agent Construction).
• Agentic abstraction frameworks — Strands, LangGraph, PydanticAI (under Agent Patterns).

Both are named in the published objectives, which makes them fair game, and both are exactly where a candidate cross-studying from Architect material has a hole.

The question character is mixed: recall for the construction surfaces (which package, which field, which lifecycle value) and judgment for architecture (workflow or agent, delegate or not, hook or prompt).

Theory outline

1. Agent Architecture (4.5%)

The blueprint scopes this to principles, patterns, and trade-offs of agent and workflow architecture, decision criteria for using a workflow versus an agent, the structure of manager/supervisor hierarchies, and the role of subagents in improving task execution.

Workflow versus agent — the decision criteria

The distinction the exam tests is about who controls the path:

There is a tier below both, and it is the most-forgotten correct answer: a single API call. Classification, summarization, extraction, and question-answering are one request. No loop, no tools, no orchestration.

Default to the simplest tier that meets the need. The published escalation order is: single call, then workflow with tool use where your code owns the orchestration, then an agent when the task genuinely requires open-ended model-driven exploration.

Four criteria decide whether an agent is warranted, and all four must hold:

A "no" on any one of them means stay at a simpler tier. The exam's favorite illustration contrasts "turn this design document into a pull request" — genuinely open-ended, worth an agent — against "extract the title from this PDF," which is one call. A stem describing a fixed, known sequence of steps is describing a workflow, and the agent option is the trap.

Manager and supervisor hierarchies

The named structure is hub and spoke: one coordinator, N specialized subagents, and all inter-subagent communication routed through the coordinator. Subagents do not talk to each other directly. Routing through the hub buys observability, consistent error handling, and controlled information flow.

The coordinator owns task decomposition, dynamic selection of which subagents a given request actually needs, delegation with complete instructions, result aggregation and validation, and iterative refinement when coverage falls short.

"Dynamic selection" is the tested nuance: a coordinator that always runs the full pipeline regardless of the request wastes cost and latency. A simple factual query should not trigger every stage.

The role of subagents

Subagents improve task execution through two distinct mechanisms, and the exam separates them:

Parallelism. Independent subtasks run concurrently instead of serially.

Context isolation. This is the one candidates under-appreciate. Each subagent burns its own context window on raw material and returns condensed findings, so the coordinator's window holds summaries rather than source dumps. That is why delegation helps even on work that could have run sequentially.

The cost of that isolation is the constraint you must design around: subagents inherit nothing. No conversation history, no shared memory between invocations. Every fact a subagent needs must be present in its own prompt. A delegation that says "synthesize the earlier findings" points at context the subagent cannot see, and produces generic output — that failure signature resolves to missing explicit context every time.

Delegation is not free. Each subagent re-establishes context, explores, and reports back, and the coordinator then reads the report. Judgment guidance across recent models runs in both directions: some generations under-reach for subagents and need explicit encouragement, others over-reach and need an explicit cap. The stable rule is that delegation should be reserved for genuinely independent, sizeable tracks — not for work the coordinator could finish in a handful of tool calls, and not for verifying the coordinator's own output, which belongs in the main loop.

2. Agent Construction with Claude (5.3%)

The heaviest skill here. The blueprint names four things: the Claude Agent SDK, custom agent loops and harnesses, managed agent deployment models (self-hosted versus Anthropic-hosted), and hooks for deterministic actions.

Four ways to build an agent

Two independent questions separate them: who supplies the harness (the loop plus context management) and who supplies the deployment (the infrastructure it runs on). This table is the densest recall material in the domain.

Read the deployment column: three of the four leave hosting to you. Only Managed Agents supplies both halves. That is the load-bearing distinction, and a stem asking for "no loop code, no state files, no scheduler" is pointing at Managed Agents specifically.

Tool Runner is not the Claude Agent SDK

These sound alike and are different products. Confusing them is the single most likely construction question.

Both are harness-only and both run on your infrastructure. The difference is the scope of the harness. A stem asking for a batteries-included coding or filesystem agent is the Agent SDK; a stem asking to avoid hand-writing the loop over a handful of custom business tools is the Tool Runner.

The Tool Runner is also under-credited. It is not a black box: each iteration exposes the assistant message before the tools execute, which is where approval gates, error interception, result modification, and per-turn retries live. "I need human-in-the-loop approval" is therefore not a reason to drop to a manual loop — you gate inside the tool function or intervene on the yielded message. Reach for the manual loop when you need something the runner genuinely does not expose: a custom transport, a control flow that interleaves unrelated work, or avoiding a beta dependency.

The custom loop

Whichever harness you use, the underlying lifecycle is the same:

1. Send the request (system prompt, history, tool definitions).
2. Inspect stop_reason.
3. If it reads tool_use: execute the requested tools, append tool_result blocks referencing each call's tool_use id, resend.
4. If it reads end_turn: done.
5. Repeat.

Four mechanics that get tested:

• Append the full response content, not just the extracted text. Dropping the tool_use blocks breaks the pairing on the next turn.
• Every tool_result carries the matching tool_use id.
• All results from one turn go back in a single user message. Splitting them across messages silently trains the model out of parallel tool calls.
• A failed tool still returns a tool_result, with is_error set. Dropping it leaves an unmatched call and gives the model a hole to reason over.

Termination anti-patterns, named explicitly:

• Parsing natural language for a completion signal.
• Using an arbitrary iteration cap as the primary stop condition.
• Treating "the assistant produced text" as completion.

The only reliable signal is stop_reason. An iteration cap is fine as a runaway backstop; it is wrong as the thing that normally ends the loop, because it truncates legitimate multi-step work and masks the real signal.

One more stop_reason belongs in a loop that uses server-side tools: pause_turn, emitted when a server-side sampling loop hits its iteration limit. Resend the conversation to resume — and do not append a "Continue." user message. The API detects the trailing server-tool block and picks up on its own.

Managed agent deployment models

The distinctly CCDV-F material. Managed Agents is a hosted surface with a mandatory two-step flow:

Agent, once. Session, every run.

• The Agent is a persisted, versioned configuration object. model, system, tools, MCP servers, and skills live here.
• The Session references a pre-created agent by ID, plus an environment, and produces an event stream.

The most-tested anti-patterns:

• Putting model, system, or tools on the session. They are agent fields. The session takes a pointer.
• Calling agent-create on every run. That accumulates orphaned agents, pays creation latency per request, and defeats the versioning model. Create once, store the ID, reuse it. To change behavior, update the agent — each update creates a new immutable version, and sessions can pin to one for reproducibility.

Now the deployment fork. An environment's configuration type is either cloud or self_hosted:

The subtlety worth memorizing: self-hosted does not move the agent loop. The loop still runs on Anthropic's side; what moves is tool execution, so filesystem contents and network egress stay inside your infrastructure. An answer option claiming self-hosted runs the model or the loop on your hardware is wrong.

Self-hosted is the right answer when tools must run on your own infrastructure, secrets cannot leave it, or the job needs binaries and data a hosted container will not have. It comes with reduced feature support relative to cloud, so it is a deliberate trade, not a default.

Session lifecycle — four states: rescheduling, running, idle, terminated. Terminated is irreversible and does not by itself mean failure; a session terminates on completion too.

The tested client-side rule: do not break your loop on idle alone. Sessions go idle transiently — between parallel tool executions, or while waiting on you. Check the idle event's stop_reason:

Two more client patterns: open the event stream before sending the kickoff, because the stream only delivers events emitted after it opens; and on reconnect, fetch history and dedupe by event ID, because the stream has no replay.

Hooks for deterministic actions

The blueprint's own phrase is "hooks for deterministic actions," which states the principle outright.

Prompt instructions are probabilistic. Hooks are deterministic. An instruction saying to always verify identity before a refund has high compliance and a non-zero failure rate. A hook that blocks the call has neither.

Direction matters and is a favorite trap: a hook that fires before a tool call can inspect the outgoing call and block or redirect it — enforcement. A hook that fires after a tool returns can only transform the result before the model sees it — normalization. A "before" hook prevents; an "after" hook is too late to prevent anything and exactly right for cleaning up heterogeneous tool output.

Whenever a stem mentions money, legal exposure, safety, or "must never," the deterministic option is the answer, and "strengthen the system prompt" is the seductive wrong one.

Managed Agents expose a related control with the same logic: a per-tool permission policy. The default allows a tool to execute automatically; the alternative pauses the session and waits for an explicit confirmation event from your client before the call proceeds.

3. Agent Patterns and Frameworks (4.9%)

The blueprint scopes this to common design patterns — tool-use loops, sub-agents, memory, context-window management — and agentic abstraction frameworks (Strands, LangGraph, PydanticAI).

Designing the tool surface

The model emits tool calls; your harness handles them. The shape of those calls determines what the harness can do, which is what makes tool-surface design an architectural decision rather than an API detail.

A shell tool gives the model enormous reach but gives your harness an opaque command string — the same shape for every action. Promoting an action to a dedicated tool gives the harness a typed, action-specific hook it can intercept, gate, render, or audit.

Promote an action to its own tool when you need to:

The rule of thumb: start with breadth, promote on need.

Tool descriptions should be prescriptive about when to call the tool, not merely descriptive of what it does. That materially changes how often the model reaches for it, and it is the first lever when a tool is under-used.

Scaling the tool and instruction set

Two mechanisms with the same underlying idea — keep the fixed context small and load detail on demand:

• Tool search, when many tools exist but few are relevant per request. Tools are declared up front but deferred, and their schemas load only when surfaced. Because the schemas are appended rather than swapped, the prompt cache survives — which is exactly why this beats rebuilding the tool list per request. Constraint: at least one tool must be non-deferred, and the search tool itself cannot be deferred.
• Skills, for task-specific instructions. A skill's short description sits in context by default; the full file is read only when the task calls for it. Same progressive-disclosure principle applied to instructions instead of tools.

Composing calls

Standard tool use is one round trip per call: the model calls, the result lands in its context, it reasons, it calls again. Three sequential lookups means three round trips, and most of the intermediate data is never needed again.

Programmatic tool calling lets the model compose those calls into a script instead. The script runs in the code-execution container; when it invokes a tool, the call executes and the result returns to the running code, not to the model's context. Ordinary control flow filters it, and only the script's final output goes back to the model. Reach for it when there are many sequential calls, or when intermediate results are large and should be filtered before they consume context.

Context-window management

Three mechanisms, and conflating them is the likeliest question in this skill:

Editing prunes; compaction condenses; memory survives process restarts. Many long-running agents use all three. Compaction carries an implementation trap: append the full response content back into your messages, because the compaction blocks are what the API uses to replace the compacted history next request. Extracting only the text silently loses the compaction state.

Memory is a client-side tool — the model reads and writes files in a memory directory and you implement the storage. The design guidance that recurs: one lesson per file with a summary line, record both corrections and confirmed approaches, do not save what the repository already records, update rather than duplicate, and delete what turns out to be wrong. And the standing security caution: never persist credentials or secrets into memory, because memory is replayed verbatim into every later session that mounts it.

Caching in agents

Long agent runs make caching structural rather than optional, and three constraints have agent-specific workarounds:

Multiagent composition

Where a coordinator delegates within one hosted session, the roster is declared as a top-level field on the agent, not as an entry in the tools array. Two constraints:

• One level of delegation only. Rostering an agent that itself carries a roster fails validation — it is rejected, not silently flattened.
• Each delegated agent runs in its own thread with its own conversation history, model, prompt, and tools. Threads share the container's filesystem but not conversation context — the same isolation rule as subagents generally.

Agentic abstraction frameworks

Named in the blueprint: Strands, LangGraph, PydanticAI. Third-party libraries that sit above the raw request-and-loop layer and provide orchestration primitives — graph or state-machine style control flow, typed inputs and outputs, and provider abstraction — so that multi-step workflows are declared rather than hand-written.

The exam is a foundations exam, so treat these at the level the objective states them: know that they exist, know that they are abstraction layers over the same underlying API, and know the trade-off, which is the part a question can actually turn on.

The judgment: a framework earns its place when you need its orchestration model or genuine multi-provider portability. It costs you when you need a capability the abstraction has not surfaced yet — effort levels, a new thinking configuration, a beta tool type — because you cannot reach past it without dropping down anyway. Note also that the Claude Agent SDK is not one of these: it is Anthropic's own harness for a coding and filesystem agent, not a provider-neutral orchestration library.

Worked problems

Problem 1. A team must extract the invoice number, date, and total from 200 PDFs each morning. The fields are always present and the format is stable. An engineer proposes an agent with file-reading and validation tools that decides how to approach each document. What should a reviewer say?

A. Approve — document processing is a canonical agent use case B. This does not meet the criteria for an agent; the task is fully specifiable, so a single structured-output call per document (batched) is the right tier C. Approve, but require a hook to validate each extraction D. Use an agent with a low effort setting to control cost

Approach: Run the four criteria. Complexity fails immediately — the task is fully specifiable in advance, which is the published counterexample ("extract the title from this PDF") for when not to build an agent. The correct tier is a single call per document with a structured output schema, and since nothing is waiting on the result overnight, batching adds the discount.

Why the others fail: A appeals to the domain rather than the criteria; document processing spans every tier. C bolts governance onto an architecture that should not exist — a hook cannot fix an over-engineered tier choice. D reduces the cost of the wrong architecture instead of choosing the right one.

Answer: B

Problem 2. A developer wants an agent that reads and edits files in a repository, runs shell commands, and searches the web, hosted on the team's own infrastructure. They install the Anthropic API SDK and look for a tool-runner method, expecting built-in file and shell tools. They find none. What went wrong?

A. Built-in tools require the beta messages endpoint B. The Tool Runner loops over tools you define and ships no built-in tools; the batteries-included file, shell, and search harness is the separate Claude Agent SDK package C. Built-in tools are only available through Managed Agents D. The Tool Runner requires a schema library before built-in tools appear

Approach: This is the domain's central naming confusion. Tool Runner is a helper in the regular API SDK that automates the loop over your tools — no built-in tools, no filesystem access. The Claude Agent SDK is a different package shipping the Claude Code harness with built-in tools, and it is still self-hosted, which matches the stated requirement.

Why the others fail: A invents an endpoint gate. C is wrong on the deployment requirement — Managed Agents does ship a hosted toolset, but Anthropic hosts the container, and the stem specifies the team's own infrastructure. D confuses schema generation with tool availability; a schema library is optional for the Tool Runner and irrelevant to built-in tools.

Answer: B

Problem 3. A regulated firm wants a hosted agent — no loop code, no scheduler — but its security team requires that all file contents and network egress stay inside the company VPC. Which configuration fits, and what still runs on Anthropic's side?

A. Cloud environment with restricted networking; nothing runs on Anthropic's side B. A self-hosted environment: tool execution moves into the firm's container, while the agent loop still runs on Anthropic's orchestration layer, reached by an outbound-polling worker C. The Claude Agent SDK, since Managed Agents cannot be self-hosted D. A self-hosted environment, which moves both the loop and the model inference into the firm's infrastructure

Approach: The stem asks for the managed harness and data locality, which is exactly what the self-hosted environment type provides. The precise split is the tested part: tool execution moves; the agent loop does not. Connectivity is outbound-only — the firm's worker polls Anthropic's work queue, and Anthropic never dials in.

Why the others fail: A is doubly wrong: restricted networking still leaves the container on Anthropic's infrastructure, and the loop runs there regardless. C is false — self-hosted environments exist precisely for this, and the Agent SDK would also mean writing and operating the harness the firm said it did not want. D overstates the move; model inference never runs on customer hardware, and neither does the loop.

Answer: B

Problem 4. A client drives a hosted agent session and breaks its event loop the first time it sees an idle status. Users report the agent "stops halfway" on tasks that use a custom tool. What is wrong?

A. Custom tools are unsupported in hosted sessions B. Idle is transient — the client must inspect the idle event's stop_reason and continue when it reads requires_action, which means the session is waiting on a tool result from the client C. The client should break on terminated instead and never on idle D. The session needs a longer timeout

Approach: The symptom points straight at the documented idle-gate rule. A custom tool call parks the session in idle with stop_reason requires_action while it waits for the client to return a result. Breaking there abandons the session mid-task. The correct gate breaks on terminated, or on idle with a terminal stop_reason — anything except requires_action.

Why the others fail: A contradicts the design: custom tools are the mechanism by which your application executes calls, and the idle pause is how the handshake works. C is half right and would hang — a session that completes normally goes idle with a terminal reason and may never reach terminated. D misreads a protocol handshake as a latency problem.

Answer: B

Problem 5. An agent must never issue a refund above a threshold without human approval. The rule is in the system prompt in bold capitals, and quarterly audit found four violations. The team proposes adding few-shot examples of correct escalation. Evaluate.

A. Approve — few-shot examples are the strongest way to lock behavior B. Reject; the rule needs a hook that fires before the refund tool executes and blocks or redirects calls above the threshold C. Approve, and additionally lower the model's effort so it follows instructions more literally D. Add a hook that fires after the refund tool returns and logs violations for review

Approach: "Must never," a money threshold, and an audited failure rate together are the exam's signature for a deterministic requirement. Prompt-based guidance — bold text, capitals, few-shot examples — reduces the failure rate but never to zero. Only programmatic enforcement guarantees it, and it must act before execution.

Why the others fail: A and C are still prompt-based: they move the probability, not the guarantee, and effort is a reasoning-depth control, not a compliance mechanism. D has the right mechanism pointed the wrong way — a hook that runs after the tool fires cannot prevent a refund that already happened. Logging a violation is not preventing one, and that Pre/Post direction is the buried trap.

Answer: B

Exam traps

• Confusing Tool Runner with the Claude Agent SDK. Tool Runner is a helper inside the regular API SDK that loops over your tools, with no built-in tools and no filesystem access. The Claude Agent SDK is a separate package shipping the full Claude Code harness with built-in tools. Both are self-hosted.
• Thinking Managed Agents is the only hosted option — or that the others are hosted. Only Managed Agents supplies harness and deployment. The manual loop, Tool Runner, and Agent SDK are all harness-only; you host them.
• Believing self-hosted moves the agent loop. It moves tool execution into your container. The loop stays on Anthropic's orchestration layer, reached by an outbound-polling worker. Model inference never runs on your hardware.
• Putting model, system, or tools on the session. Those are agent fields. The session takes a pointer to a pre-created agent plus an environment.
• Creating the agent on every run. Create once, store the ID, reuse it; update the agent to change behavior, which creates a new immutable version. Per-run creation orphans agents and defeats versioning.
• Breaking on idle alone. Check the idle event's stop_reason. requires_action means the session is waiting on you — handle it and continue. Only a terminal reason, or a terminated status, ends the loop.
• Sending after opening the stream, or reconnecting without history. Open the stream first; the stream only delivers events emitted after it opens. It has no replay, so on reconnect fetch history and dedupe by event ID.
• Iteration caps as the primary stop condition. The loop's control signal is stop_reason — tool_use continues, end_turn terminates. Caps are runaway backstops. Parsing text for completion and treating "assistant produced text" as done are both named anti-patterns.
• Dropping a failed tool result, or splitting results across messages. Return every tool_result — with is_error set on failures — and return all of a turn's results in one user message.
• Sending "Continue." after pause_turn. Resend the conversation; the API resumes from the trailing server-tool block on its own.
• Assuming subagents inherit context. They inherit nothing. Every fact goes explicitly into the delegated prompt. Generic subagent output almost always means missing context, not an incapable model.
• Delegating verification. Verification belongs in the main loop, not in a subagent — and delegation generally should be reserved for genuinely independent, sizeable tracks rather than work the coordinator could finish in a few tool calls.
• Prompt instructions for guaranteed compliance. Money, compliance, safety, and "must never" mean hooks. And direction matters: a hook before the call can block it; a hook after the call can only reshape the result.
• Conflating context editing, compaction, and memory. Editing clears, compaction summarizes, memory persists across sessions. And with compaction, append the full response content — extracting only text drops the compaction state.
• Nesting coordinators. One level of delegation only; a rostered agent that itself carries a roster is a validation error. And the roster is a top-level agent field, not an entry in the tools array.