TimoBy Amotion AI

Agent Architecture: CCDV-F study guide

CCDV-F · Agents and Workflows, topic weight 4.5% of the exam

Agent Architecture sits in Domain 1, Agents and Workflows (14.7% of the CCDV-F exam), with a topic weight of 4.5%. It tests one build decision: should your code fix the steps (a workflow) or should Claude choose them (an agent), and if Claude chooses, how to split the work between a supervisor and its subagents.

What the official guide covers

The Claude Certified Developer Foundations exam guide (version 1.0, effective July 2026) describes this topic as the principles, patterns and trade-offs of agent and workflow architecture:

What the guide listsWhat it means in practice
Principles, patterns and trade-offs of agent and workflow architectureKnow the standard workflow patterns and what each costs in tokens, latency and control
Decision criteria for a workflow versus an agentUse fixed code paths when the steps are known; use an agent loop when the next step depends on what the last one found
The structure of manager or supervisor hierarchiesOne coordinator splits the task, briefs workers and merges their results
The role of subagents in improving task executionSeparate context windows, parallel work, focused prompts and narrower tool sets, at the price of more tokens

Workflow or agent: what changes in the code

Anthropic's engineering guidance draws the line by who controls the path. In a workflow, your code calls Claude at fixed points and decides what happens next. In an agent, Claude runs in a loop, calls tools and decides the next step itself (loop mechanics are in CCAR-F 1.1). The common workflow patterns are:

PatternHow it worksUse it when
Prompt chainingEach call's output feeds the next, with checks in code between stepsThe task splits cleanly into fixed steps
RoutingA first call classifies the input and picks a specialised prompt or modelInputs fall into distinct categories that need different handling
Parallel callsIndependent sections run at once, or one task runs several times and results are comparedSubtasks do not depend on each other, or you want several views
Orchestrator and workersA central call breaks the task down at run time and hands parts to workersYou cannot predict the subtasks in advance
Evaluator and optimiserOne call drafts, another critiques against criteria, and the draft is revisedClear criteria exist and revision measurably improves the result

An agent earns its extra cost when the number of steps cannot be known in advance, such as debugging or open research, and when a wrong step is cheap to catch and undo, as with code under tests. It needs a sandbox and guardrails, because Claude chooses actions you did not script; where one wrong action is costly, put a coded check or a person in front of it.

Start on the lowest rung that handles the variation

Treat the options as a ladder: one model call, then a workflow, then an agent. Move up a rung only when the rung below cannot cope with how much the inputs vary. Each rung up buys flexibility and costs control, so the questions below decide where you stop:

QuestionIf yes, lean towardsBecause
Can you write every step as code today?WorkflowThe path is known, so a loop adds cost without adding capability
Is a wrong step expensive, so each step needs its own check?WorkflowCode can validate between steps and stop the run
Must operations staff follow runs with normal logs and alerts?WorkflowAn agent's path lives in a transcript, which needs transcript-level tooling to inspect
Does the product only offer users a fixed set of tasks?WorkflowThe interface already limits the inputs, so each task can be scripted and tested step by step
Do inputs arrive in shapes you cannot list in advance?AgentA workflow would need dozens of branches and still break on the next new shape
Is varied behaviour acceptable, with the tool set bounding what Claude can do?AgentYou specify the goal and tools, and Claude finds the path

Two mistakes sit at either end. An agent where a workflow would do adds token cost and behaviour you can only see by reading transcripts. A workflow where an agent is needed fails the first time a request falls outside the scripted path. Choose from the task, not from whichever pattern is quickest to prototype.

How a supervisor hierarchy is built

A supervisor (also called a coordinator or lead agent) holds the user's goal. It splits the work, writes a brief for each worker, runs independent workers in parallel and merges what comes back. Workers never talk to each other, so the supervisor is the one place to log, retry and check quality.

The worker brief is the part candidates get wrong. In the Claude Agent SDK, a subagent starts with its own system prompt, the project CLAUDE.md, its tool definitions and the prompt string the supervisor passes to the Agent tool. It does not see the supervisor's conversation, so any file path, error message or earlier decision must be written into that prompt. Only the worker's final message returns, so the supervisor's context grows by a summary, not by every file the worker read.

How deep the hierarchy goes depends on the platform:

PlatformHow the supervisor declares workersDepth
Claude Agent SDKThe agents option maps names to AgentDefinition objects (description, prompt, tools, model and more); Claude calls them through the Agent toolSubagents can spawn their own; CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH caps the layers, and 1 stops workers from spawning
Claude Managed AgentsA coordinator agent lists its workers in a multiagent roster of type coordinatorOne level only; a worker with its own roster is rejected

In Managed Agents, each agent has its own session thread and history, while all agents share one sandbox filesystem.

A supervisor with two read-only workers (Python)

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition, ResultMessage

WORKERS = {
    "log-analyst": AgentDefinition(
        description="Reads service logs and reports error patterns. Use for any question about log contents.",
        prompt="You analyse log files. Report each distinct error with first and last timestamp and a count.",
        tools=["Read", "Grep", "Glob"],   # read-only
        model="haiku",                    # cheaper model for a narrow task
    ),
    "code-tracer": AgentDefinition(
        description="Finds the code that raises a given error message. Use after the error is known.",
        prompt="Trace the error message you are given to the code that raises it. Return file paths and line numbers.",
        tools=["Read", "Grep", "Glob"],
    ),
}

async def main():
    options = ClaudeAgentOptions(
        system_prompt=(
            "You coordinate an incident review and write the summary yourself. Workers cannot see "
            "this conversation, so give each one every path, time window and error message it needs."
        ),
        allowed_tools=["Read", "Grep", "Glob", "Agent"],
        agents=WORKERS,
        max_turns=30,
        env={"CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH": "1"},   # workers may not spawn workers
    )
    try:
        async for message in query(
            prompt="Why did checkout fail between 02:00 and 03:00? Logs are in ./logs.",
            options=options,
        ):
            if isinstance(message, ResultMessage) and message.subtype == "success":
                print(message.result)
    except Exception as error:
        print(f"Run ended early: {error}")

asyncio.run(main())

Each worker's description is the routing rule the supervisor reads when deciding whom to call.

When subagents help and when they hurt

Subagents help when work splits into parts that do not need each other's context: separate sources, separate files, a security check and a style check at once. They hurt when every part needs shared context or another part's output. Anthropic's write-up of its multi-agent research system reports that multi-agent runs use far more tokens than a chat, and that tasks where agents must share context or have many dependencies, including most coding tasks, are a poor fit today.

Think of adding workers as hiring: a team finishes a broad survey sooner, but you pay every member, and the hire only makes sense when the parts can be done without waiting on each other. Two further costs are easy to miss:

  • Failure handling multiplies. Every worker makes its own API calls, so every worker needs the same retry, backoff and timeout rules as a single agent. One worker stuck on a rate limit with no backoff leaves the supervisor waiting for a result that never arrives, and the merge step stalls.
  • Model choice can claw back cost. A common split is a more capable model for the supervisor, which plans and merges, and a cheaper model for narrow workers, as the log-analyst example above does.
SituationChooseWhy
Same three steps every time (extract, validate, file)Prompt chain workflowOrder is fixed; code guarantees each step runs
Inputs fall into a few known typesRouting workflowOne cheap classification call, then a focused prompt
Open-ended investigation, steps unknownSingle agent loopClaude picks the next step from what it found
One fact looked up in a stable sourceOne call, or one agent with the cheapest model that passesWorkers would multiply tokens with nothing to run in parallel
Broad research across independent sourcesSupervisor with parallel subagentsSeparate contexts, parallel time, focused briefs
Steps depend tightly on each other's outputOne agent, no subagentsSplitting adds hand-off loss and token cost

Rules that decide exam answers

  • Fixed steps mean a workflow. Steps that always run in the same order belong in code, not in an agent that might skip one.
  • Subagents start blind. The fix for a worker that "ignores" earlier findings is a fuller brief, not a bigger model.
  • Route everything through the supervisor. Workers do not message each other; the coordinator merges results and handles errors.
  • Parallelise only independent work. Dependent parts belong in one agent or in sequence.
  • More agents cost more tokens and add failure points. Choose multi-agent designs when the task value justifies the cost, and give each worker its own retry and timeout handling.
  • Restrict tools per worker. Give each subagent the smallest tool set its job needs.

Where it appears in the exam

Agent Architecture carries 4.5% of the exam within Domain 1, Agents and Workflows (14.7%), so expect two or three items out of 53. Scenarios describe a business process and ask for a workflow or an agent, or describe a supervisor system with a symptom and ask for the fix.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A finance team built an autonomous agent with every tool enabled to process supplier invoices. The process is always the same: extract the fields, check them against the purchase order, then post to the ledger. In testing, the agent sometimes posts before checking, and token use varies widely between invoices. What should the developer change?

Answer: C. The steps are known and always run in the same order, so a workflow fixes the order in code and removes the variable agent overhead. A still leaves the order to Claude's choice. B runs dependent steps in parallel, which breaks the order. D gives more room but does not make the check happen first.

Question 2

A research supervisor built with the Claude Agent SDK sends three subagents to cover different markets. Each subagent repeats sources the supervisor already rejected earlier in the conversation and ignores the user's date range. What is the most likely fix?

Answer: A. A non-fork subagent receives only its own prompt, its system prompt and project context, so the supervisor must pass the constraints explicitly. B describes inheritance that standard subagents do not have. C gives up the parallel work the design needs. D lets workers spawn more workers, not read the supervisor's history.

Build exercise

  1. Write a three-step prompt chain (summarise, classify, draft a reply) with a validation check in code between steps.
  2. Rebuild it as one Agent SDK agent. Log turns and tokens for ten inputs and compare.
  3. Run the supervisor above on sample logs, then remove the "give each worker every path" sentence and compare the workers' answers.
  4. Give one worker the Agent tool with the depth cap at 1 and confirm it cannot spawn a worker.

Practise this topic

Sources