Domain 1 – Agents and Workflows (14.7%)
3 lessons · 3 practice questions at the end · jump to questions ↓
Domain recapQuick overview of all lessons
- Agent Architecture (4.5%)
- Agent Construction with Claude (5.3%) – Agent SDK patterns
- Agent Patterns and Frameworks (4.9%)
1.1 — Agent Architecture
CCDV-F Domain 1 · Task 1.1
What You Need to Know
Every agentic system starts from one decision: who owns the control flow.
The Three Tiers
| Tier | Who decides the next step |
|---|---|
| Augmented LLM | Single model call with retrieval, tools and memory added |
| Workflow | LLM calls and tools orchestrated through predefined code paths |
| Agent | The model directs its own process and tool usage |
The dividing line: whoever decides the next step names the tier. A hand-coded three-step chain is a workflow; a model choosing its own tool sequence is an agent.
Choosing Between Workflow and Agent
Find the simplest solution possible. Steps known in advance and repeating for every input → workflow. Number of steps unknown and each decision depends on the last → agent. Cost and latency belong inside this decision.
Supervisor Hierarchies and Subagents
A lead agent decomposes the goal, spawns specialised subagents and synthesises their results. Subagents do not share memory. A subagent’s context window starts fresh; only the delegation prompt travels. Every file path, error message, decision and convention the subagent needs must be in that brief. (Exception: Claude Code fork mode inherits the whole conversation.)
Isolation is the payoff: intermediate tool calls and large file reads stay inside the subagent; only its final message returns. Parallelism pays only when subtasks are independent.
When a multi-agent system misbehaves, trace the failure to the orchestrator first. Vague delegation produces duplicated work and gaps. The fix is almost always a better brief.
Key Concept: The single most-tested fact: subagents do not share memory. Distractors that rely on implicit shared state are always wrong.
Exam Traps
- Choosing an agent as the default tier for a task with fixed steps
- Assuming subagents can see the orchestrator’s conversation
- Classifying a hand-coded pipeline as an agent because it chains several model calls
- Believing more subagents means better results
Practice Scenario
Observability platform team runs an orchestrator agent that decomposes a codebase-wide dependency upgrade into per-service subtasks. The dependency-pinning policy was agreed in the orchestrator’s own conversation, yet the subagents keep choosing versions that violate it. Cause and fix?
Build Exercise: Draw the Boundary Before You Build (25 min)
1.2 — Agent Construction with Claude
CCDV-F Domain 1 · Task 1.2
What You Need to Know
An agent is a model calling tools in a loop. The harness is the code that runs the loop. A turn is one round trip. A hook is harness code that runs at a fixed point.
The Bare Loop
Send prompt with tool definitions → if response requests tools, execute them, append results, call again → end when no tool calls or a cap trips. Production needs a harness: turn caps, spend budgets, retries, tool-result validation, state persistence and observability. These belong in code, never in the prompt.
The Agent SDK as the Packaged Harness
Key options:
max_turns/maxTurns— caps the loop (tool-use turns only)max_budget_usd/maxBudgetUsd— stops when estimated spend reaches the dollar value
Both default to no limit. Result subtypes: success, error_max_turns, error_max_budget_usd, error_during_execution (also error_max_structured_output_retries). Every subtype carries total_cost_usd, num_turns, session_id. The result text is present only on success.
Budget is cumulative across subagents. Subagent spawn depth and concurrency are controlled by environment variables (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS).
A limit result is not a model failure. Documented recovery: resume the session with a raised limit, tighten the task brief, or split oversized work.
Where the Agent Runs
- Self-hosted: your process runs the loop (custom or Agent SDK)
- Anthropic-hosted: Claude Managed Agents (separate product; REST API; Anthropic runs the harness and sandbox)
Hooks Enforce, Prompts Request
A PreToolUse hook fires before a tool executes and can deny it deterministically. A system-prompt rule is an instruction the model may not follow. A hook executes outside the model’s discretion.
Key Concept: “Prompts request, hooks enforce” is the exam’s favourite construction.
Exam Traps
- Accepting max_iterations, budget_limit or turn_cap as real SDK options
- Reading error_max_turns as the model failing, then fixing it with a better prompt
- Treating a system-prompt prohibition as a guardrail equivalent to a hook
- Assuming subagent spend escapes the parent’s budget cap
- Describing Claude Managed Agents as the Agent SDK hosted for you
Practice Scenario
Developer-platform team ships a repository maintenance agent with Bash access. Policy: it must never invoke the production database CLI, even if malicious text in a cloned repository instructs it to. Which control actually enforces the policy?
Build Exercise: Trip Every Limit on Purpose (30 min)
1.3 — Agent Patterns and Frameworks
CCDV-F Domain 1 · Task 1.3
What You Need to Know
The Five Workflow Patterns
| Pattern | Mechanism |
|---|---|
| Prompt chaining | Fixed sequence; each call works on the previous output; optional programmatic gates |
| Routing | Classify input and send to specialised follow-up (different prompt, tool set or model per category) |
| Parallelization | Sectioning (independent subtasks side by side) or voting (same task several times for diverse answers) |
| Orchestrator-workers | Central model breaks the task down at runtime and delegates; subtasks not known in advance |
| Evaluator-optimizer | Generator + evaluator that scores against explicit criteria; critique loops back until pass |
Telling the Patterns Apart
- Chaining vs routing: fixed sequence vs classification decision
- Sectioning vs orchestrator-workers: subtasks known in advance vs decided at runtime
- Voting vs evaluator-optimizer: independent repeated attempts aggregated by code vs feedback loop with critique
- Gate vs evaluator-optimizer: fixed pass/fail in a one-way sequence vs looped critique
Memory Is a Design Decision
An agent remembers nothing between sessions unless the design adds a mechanism. Anthropic’s memory tool (memory_20250818) gives create/read/update/delete over files in /memories. Your application executes each operation client-side. Safeguards live in your handler (reject path traversal, track file sizes, cap view returns).
Context as a Constraint
Context rot: recall degrades as token counts grow. Documented moves: compaction, structured note-taking, sub-agent architectures. Compaction summarises and starts a new window with the summary (Agent SDK does this automatically).
Framework Identities
- LangGraph — low-level orchestration; model control flow as a graph; durable executions; human-in-the-loop
- Pydantic AI — typed Python agent SDK; validated output types
- Strands Agents — model-driven loop; minimal orchestration code; from Amazon production systems
Key Concept: The requirement profile justifies a pattern, never sophistication. Plain code beats a framework for a fixed pipeline.
Exam Traps
- Choosing sectioning when the model must discover subtasks at runtime (or vice versa)
- Assuming an agent keeps yesterday’s decisions between sessions by default
- Recommending LangGraph for typed output validation, or Pydantic AI for graph-shaped control flow
- Choosing voting when the requirement is a critique fed back into the next draft
Practice Scenario
Subtitling team automates broadcast subtitle files. Every file must meet a published style code. They want one model call to draft and a second to grade against the style code, feeding the critique back until the draft passes or three rounds elapse. Which workflow pattern?
Build Exercise: Profile Three Tasks, Pick Three Patterns (30 min)
Test yourself: Domain 1: Agents & workflows
3 practice questions on this domain, each with an explanation.
An observability platform team runs an orchestrator agent that breaks a codebase-wide dependency upgrade into per-service subtasks. The dependency-pinning policy was agreed in the orchestrator's own conversation, yet the subagents keep choosing versions that violate it. What is the cause, and the fix?
Domain 2: Applications & integration →