← CCDV-F study guide

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.

Question 1 of 3

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?

Report issue
Next domain

Domain 2: Applications & integration →