Domain 1 of the Claude Certified Developer – Foundations (CCDV-F) exam, Agents and Workflows, carries roughly 14.7% of the total weight, split across three sub-objectives: Agent Architecture (4.5%), Agent Construction with Claude (5.3%), and Agent Patterns and Frameworks (4.9%).
This guide is an independent, unofficial study resource. It is not affiliated with, authorized by, or endorsed by Anthropic, and it reproduces no real exam items. Everything Anthropic-specific below is grounded in Anthropic's own engineering writing and current platform documentation; where a claim would require guessing at internals Anthropic hasn't published, this guide says so rather than inventing detail.
The single most exam-relevant idea in this domain is not a pattern name or an SDK method — it's a judgment call: when should a system be a workflow, and when does it actually need to be an agent? Anthropic's own canonical reference for this domain is the engineering post "Building Effective Agents" (published December 2024, and — as of this writing in August 2026 — still the current authoritative framework with no newer official replacement). Its central argument is that most production systems should use the least autonomous design that satisfies the requirement, and that agents are a deliberate trade-off, not a default. Everything else in this domain — the five workflow patterns, subagents, the SDK, third-party frameworks — sits downstream of that one decision.
Workflow or agent: the distinction the exam actually tests
Anthropic draws a precise line between the two terms, and the exam expects you to know it word-for-word, not just in spirit. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths." Agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
This matters because the two shapes fail differently. A workflow that goes wrong fails in a way you can reproduce and fix, because the failure lives in one of your predefined steps. An agent that goes wrong can fail in ways that are hard to reproduce, because the failure might be an emergent property of a multi-turn loop the model itself steered.
- Can you enumerate the steps in advance, even if some steps call an LLM? Use a workflow.
- Does the number of steps or their order depend on what the model discovers along the way? That's a signal for an agent.
- Is the task bounded and well-specified, with a clear success condition you can check programmatically? Prefer a single call or a workflow.
- Is the cost of a wrong or runaway answer high, and is your ability to sandbox-test low? That's a reason to stay with a workflow even if an agent would technically work.
- Would a human expert doing this task need to improvise based on intermediate results? That's the strongest signal an agent is actually warranted.
The five workflow patterns
"Building Effective Agents" names five workflow patterns. These are all still workflows in the strict sense above — your code owns the control flow — but they compose LLM calls in progressively more sophisticated ways. Knowing the five names and being able to match a scenario description to the right one is directly testable.
| Pattern | How it works | Use when |
|---|---|---|
| Prompt chaining | Sequential LLM steps with programmatic checks ("gates") between them | A task decomposes cleanly into fixed subtasks, and you want to validate intermediate output before continuing |
| Routing | Classify the input first, then dispatch it to a specialized downstream path | Inputs fall into distinct categories that are each better handled by a different prompt, model, or tool |
| Parallelization — sectioning | Split a task into independent subtasks, run them concurrently, combine results | Subtasks don't depend on each other and can be parallelized for speed |
| Parallelization — voting | Run the same task multiple times and aggregate the results | You want higher confidence or diverse perspectives on one judgment |
| Orchestrator-workers | A central LLM dynamically breaks a task into subtasks and delegates them to worker LLMs | The subtasks aren't predictable in advance — the orchestrator decides them at runtime, even though the overall loop is still code-controlled |
| Evaluator-optimizer | One LLM generates a candidate answer, a second LLM critiques it, and the loop repeats until the critique passes | There's a clear evaluation criterion and iterative refinement measurably improves output quality |
Orchestrator-workers is the pattern most often confused with a true agent, and it's a favorite place for exam distractors. The distinguishing detail: in orchestrator-workers, the set of possible subtasks and the decision to delegate is still something your code frames and bounds — the orchestrator LLM chooses which subtasks to run, but it doesn't have open-ended control over the whole system's process the way an agent does. It's a workflow with a dynamic step, not an agent.
Agent architecture: manager/supervisor hierarchies and subagents
Once a system crosses the line into being an agent — the LLM owns its own loop — architecture questions shift from "what's the control-flow graph" to "how do I keep one open-ended loop from becoming an unmanageable, context-polluted mess." The dominant answer is hierarchy: a manager (or supervisor) agent that delegates bounded pieces of work to subagents, each of which runs its own loop and reports back a result.
This looks structurally similar to orchestrator-workers, and the two ideas rhyme on purpose — but here the manager itself is an agent with open-ended control over when and how to delegate, not code executing a predefined delegation step. The manager/subagent split earns its keep for two reasons: it isolates context (a subagent's exploration doesn't fill up the manager's context window with dead ends), and it isolates failure (a subagent that goes down a bad path can be discarded without corrupting the manager's state).
In Claude Code specifically, subagents are a first-class construct: they're defined in .claude/agents/*.md files (project-level) or ~/.claude/agents/*.md (personal), with YAML frontmatter specifying name, description, a tools allow/deny list, model, permissionMode, and optionally isolation: worktree for filesystem-level isolation.
| Delegation shape | Context the child sees | Typical use |
|---|---|---|
| Subagent | Fresh, isolated context by default — no parent conversation history | A bounded, well-scoped piece of work where you want a clean slate and don't want the exploration polluting the parent's context |
| Fork | Inherits the full parent conversation history | Continuing the same train of thought with a separate execution track, where shared context is the point |
Building agents with Claude: SDK, raw API, or Managed Agents
"Agent Construction with Claude" is the highest-weighted sub-objective in this domain (5.3%), and it's really a question about three different levels of abstraction for the same underlying idea — an LLM in a tool-use loop — and who owns which part of the stack.
| Approach | Who builds the loop/harness | Who hosts it | Languages |
|---|---|---|---|
| Raw API tool-use | You do — your own harness around client.messages.create plus a tools array, your own loop, your own state | You | Any language with an HTTP client / official SDK |
| Claude Agent SDK | Anthropic — it packages the actual Claude Code harness (same agent loop, built-in tools, context management) as a callable library | You | Python and TypeScript officially; other languages shell out to the claude CLI with -p --output-format json |
| Managed Agents | Anthropic | Anthropic — including the execution sandbox | Per Anthropic's managed-agents interface |
The distinction people most often get backwards on the exam is Agent SDK vs. Managed Agents: both are "agents built by Anthropic's tooling," but the Agent SDK is self-hosted — you still deploy and run the process yourself — while Managed Agents is Anthropic-hosted end-to-end, including the sandbox the agent executes in.
- Built-in tools: Read, Write, Edit, Bash, and web tools, the same ones Claude Code ships with
- The same agent loop and automatic context management Claude Code uses
- Hooks for injecting deterministic checks around the loop
- Subagents, exactly as configured in
.claude/agents/*.md - MCP support for connecting external tools and data sources
- A permissions system, plus session resume and fork
- Auto-loaded skills, commands, and memory from a project's
.claude/directory
Hooks, permission modes, and context-window management
Hooks are how you put deterministic guardrails around an otherwise non-deterministic loop: user-defined checks that run at points in the agent's lifecycle, independent of what the model itself decides to do. They're one of the concrete answers to "agents require guardrails" from Anthropic's own when-to-use-an-agent guidance — instead of trusting the model to self-police, you enforce a rule in code that runs regardless of what the model outputs.
Permission modes govern how much the loop can do without a human in it, and this is an area that has changed materially and recently — know the current state, not just the concept. Claude Code exposes six modes: default (manual approval, read-only until approved), acceptEdits, plan, auto, dontAsk, and bypassPermissions.
| Mode | What it means |
|---|---|
| default | Manual approval required for actions; effectively read-only until you approve each step |
| acceptEdits | File edits are auto-accepted; other action types still gated |
| plan | The agent plans before acting rather than executing immediately |
| auto | A second classifier model reviews most actions instead of requiring human approval for each one |
| dontAsk | Skips prompts for a broader set of actions than acceptEdits |
| bypassPermissions | No permission gating at all |
Context-window management is the other half of keeping a long-running agent loop tractable. The two mechanisms this domain expects you to connect are the ones already covered above: subagent isolation (delegating bounded work to a fresh context so exploration doesn't pollute the parent's window) and persistent memory living outside the context window entirely (skills, commands, and memory auto-loaded from .claude/ rather than re-derived every turn). Both exist to solve the same underlying problem — a context window is a finite, shared resource, and an agent that fills it with noise degrades in quality long before it hits a hard token limit.
Third-party frameworks: recognize the names, don't overclaim
The official blueprint's sub-objective text for Agent Patterns and Frameworks names three third-party frameworks: Strands, LangGraph, and PydanticAI. Be honest with yourself about what the exam is likely testing here: recognition, not implementation depth. This guide focuses on Anthropic's own tooling because that's what can be verified against Anthropic's own documentation; treat the descriptions below as orientation, not a substitute for reading each framework's own docs if you expect deep questions on them.
- LangGraph — a graph-based orchestration framework (from the LangChain ecosystem) for building stateful, multi-step LLM applications, including multi-agent systems.
- PydanticAI — a Python agent framework built around Pydantic, oriented toward structured, type-validated model outputs and tool calls.
- Strands — an open-source agent SDK for building model-driven agent loops, positioned similarly to "bring your own model" agent frameworks.
Key takeaways
- 01Workflows use predefined code paths; agents let the LLM dynamically direct its own process and tool use. Who owns control flow is the entire distinction.
- 02Default to the least autonomous design that works. Anthropic's own guidance: single calls with retrieval/in-context examples are often enough, and agents trade latency, cost, and compounding-error risk for open-ended capability.
- 03The five workflow patterns — prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers, evaluator-optimizer — are all still code-controlled, even the dynamic-delegation ones.
- 04Subagents get a fresh, isolated context by default; a fork inherits the full parent conversation. Isolation is what lets manager/subagent hierarchies scale without polluting context.
- 05Raw API tool-use, the Claude Agent SDK, and Managed Agents are three different points on the same spectrum: who builds the harness and who hosts it. The Agent SDK gives you the full Claude Code harness as a library, but you still host it yourself — only Managed Agents hosts the sandbox for you.
- 06Hooks give you deterministic guardrails around a non-deterministic loop. Permission modes govern how much the loop can do unsupervised — and as of mid-2026,
auto(classifier-reviewed) is the default on paid plans, not the older manualdefaultmode. - 07Strands, LangGraph, and PydanticAI are third-party, model-agnostic agent frameworks worth recognizing by name and category — the exam blueprint doesn't expect deep internals knowledge of any of them.
Common mistakes
Treating orchestrator-workers as the same thing as a true agent because both involve dynamic delegation.
Orchestrator-workers is still a workflow: your code frames and bounds what the orchestrator can delegate. A true agent has open-ended control over its own process, not just a dynamic delegation step inside a predefined structure.
Assuming the Claude Agent SDK means Anthropic hosts and runs the agent for you.
The Agent SDK packages the Claude Code harness as a library you still deploy and operate yourself. Anthropic hosting the sandbox too is what Managed Agents specifically provides.
Reaching for an agent by default because it 'seems more capable' than a workflow.
Start from Anthropic's own guidance: optimize single calls with retrieval and in-context examples first, and only move to a workflow or agent when the task's structure genuinely requires it — remembering agents add latency, cost, and compounding-error risk that require sandboxed testing and guardrails.
Answering permission-mode questions as if default (manual approval) is still the out-of-the-box behavior on a paid plan.
As of mid-August 2026, auto mode is the built-in default on paid plans, using a classifier model to review most actions instead of requiring approval for each one.
Frequently asked
Is 'Building Effective Agents' still the right thing to study for this domain, or has Anthropic replaced it?
As of this writing (August 2026), it's still Anthropic's current authoritative framework for the workflow-vs-agent distinction and the five named workflow patterns — no newer official replacement has been published. It's the right primary source to study.
What's the practical difference between a subagent and a fork in Claude Code?
A subagent starts with a fresh, isolated context by default and does not see the parent conversation's history. A fork inherits the full parent conversation history and continues from it. Use a subagent when you want a clean, bounded piece of work isolated from the parent's context; use a fork when shared context is the point.
Do I need to know LangGraph or PydanticAI in depth for the exam?
The official blueprint's sub-objective text names Strands, LangGraph, and PydanticAI, so recognizing what each is and what category it occupies (third-party, model-agnostic agent orchestration frameworks) is fair game. Deep implementation knowledge of any of them is unlikely to be the focus, since the domain is otherwise built entirely around Anthropic's own tooling and public engineering guidance.
How is the Claude Agent SDK different from just calling the API with a `tools` array myself?
Raw API tool-use gives you the model plus tool definitions; you build the entire loop, state management, and context handling yourself. The Claude Agent SDK gives you the same harness Claude Code itself runs on — built-in tools (Read/Write/Edit/Bash/web), the agent loop, automatic context management, hooks, subagents, MCP support, permissions, and session resume/fork — as a callable library. You still host and deploy it, but you're not rebuilding the harness from scratch.
Independent, unofficial study material. Not affiliated with, endorsed by, or authorized by Anthropic. Every example is original and written to teach the public exam objectives — no real exam questions are reproduced. Technical details reflect Claude, the Anthropic API, Claude Code, and MCP as of August 24, 2026; always confirm specifics against current official documentation.
Test yourself
Turn what you just read into answers you can check.