Agents and Workflows

14.7% of the Claude Certified Developer – Foundations blueprint — roughly 8 of the 53 questions on a real sitting.

Agents and Workflows is 14.7% of the CCDV-F blueprint — roughly 8 of the 53 scored questions, and the third-largest domain. It decomposes into Agent Construction with Claude (5.3%), Agent Patterns and Frameworks (4.9%) and Agent Architecture (4.5%), which is an unusually even split: no single sub-skill dominates, so no part of the domain is safe to skip.

The framing that runs through all three is restraint. Anthropic's own published guidance draws a sharp line between *workflows*, described as systems where models and tools are orchestrated through predefined code paths, and *agents*, where the model dynamically directs its own process and tool use. Its headline conclusion is that the most successful implementations use simple, composable patterns rather than complex frameworks. Exam questions inherit that bias almost perfectly: a scenario describes a task, four options escalate in autonomy and machinery, and the correct answer is usually the least autonomous one that actually solves the problem.

The construction half is concrete rather than philosophical. Know what the agent loop is — the model returns a tool-use stop reason, your code executes tools, results go back, repeat — and who supplies which part of the machinery in each available approach. And because agents run long, know the context story: what degrades as a window fills, and which of retrieval, compaction, note-taking and delegation fixes which problem. Treat this domain as 'when not to build an agent, and how to build one safely when you must'.

What the exam actually tests

  • —The workflow-versus-agent distinction: predefined code paths versus model-directed control flow
  • —The named workflow patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer
  • —The four-question test before building an agent: complexity, value, viability, and cost of error
  • —The agent loop mechanics, and who supplies the harness versus the deployment in each build approach
  • —Managing context over long horizons: context rot, just-in-time retrieval, compaction, note-taking, sub-agents
  • —Bounding autonomy: iteration caps, human approval for irreversible actions, and gateable dedicated tools

Workflows and agents are different systems

A workflow orchestrates model calls and tools through code paths you wrote: the sequence is fixed, the branching is yours, and you can reason about every route through it. An agent hands control flow to the model, which decides which tools to call and when it is done. Agents buy adaptability and pay for it in cost, latency and unpredictability, so the choice is an engineering judgement rather than a fashion. Four questions decide it. Is the task genuinely hard to specify in advance, or could you write the steps down? Does the outcome justify higher cost and latency? Is the model actually capable at this task type? And can errors be caught and recovered from — by tests, review, or rollback? A 'no' on any of them means drop to a simpler tier.

The workflow patterns worth naming

Five composable patterns cover most non-agentic work, and they are worth knowing by name because scenarios describe them without naming them. **Prompt chaining** decomposes a task into sequential steps, each acting on the previous output, with programmatic gates between them. **Routing** classifies an input and dispatches it to a specialised follow-on path. **Parallelization** runs independent calls concurrently, either splitting a task into sections or running the same task several times and aggregating by vote. **Orchestrator-workers** has a lead model decompose a task dynamically and delegate the pieces. **Evaluator-optimizer** pairs a generator with a critic that grades output against criteria and feeds revisions back. All five build on the same primitive — a model augmented with tools, retrieval and memory.

Constructing an agent on Claude

Underneath every option is the same loop: send messages and tool definitions, receive `stop_reason: "tool_use"`, execute the requested tools, append the results as `tool_result` blocks, and send again until the model stops calling tools. What differs is who supplies the machinery. Writing the loop yourself gives total control and total responsibility. The SDK's tool runner drives the loop over tools you define while leaving per-turn hooks for approval gates, error interception and result modification — the usual right answer for a custom-tool agent. Anthropic's managed agent platform supplies both the loop and a hosted execution environment, with agent configurations persisted and versioned separately from the sessions that reference them. And the Claude Agent SDK is a distinct product that packages the Claude Code harness with built-in file and shell tools.

Context over a long horizon

An agent's context window is a budget, not a container. As it fills, recall and accuracy degrade — the effect Anthropic's engineering writing calls *context rot*, framed as the model spending a finite attention budget. Four techniques address it, and they are not interchangeable. Just-in-time retrieval keeps lightweight identifiers — file paths, queries, links — in context and loads the content only when needed. Compaction summarises a conversation approaching the limit and continues from the summary. Structured note-taking has the agent persist findings to durable storage outside the window. Sub-agent architectures give each delegated piece its own clean window and return only a report. Exam scenarios usually describe one symptom precisely enough that only one of the four fits.

Bounding autonomy

An agent that can loop can loop forever, and an agent with a shell can do anything the shell can. Three controls recur in correct answers. Hard bounds: an iteration or turn cap and a spend ceiling, so a pathological run terminates rather than escalating. Human approval at the points that matter — irreversible actions such as external writes, payments, deletions and outbound messages — rather than blanket approval, which trains reviewers to click through. And tool surface design: promoting an action from a generic shell command to a dedicated tool gives your harness typed arguments it can gate, audit, render or parallelise, where a bash string is opaque. Reversibility, not sensitivity, is the usual criterion for what needs a gate.

Where candidates go wrong

Trap 1 — 'It calls tools, so it should be an agent'

The most common wrong answer in this domain escalates autonomy that the task does not need. A task with a knowable sequence of steps is a workflow, even when every step calls a model and tools; making it agentic adds cost, latency and non-determinism while removing your ability to reason about the control flow. When a scenario describes a well-specified multi-step process, the correct option is almost always prompt chaining or routing — not an autonomous agent with a large toolset and a hope that it works out.

Trap 2 — 'Adopt an agent framework so you do not have to build this'

Options that solve an agent problem by reaching for a heavyweight orchestration framework read as pragmatic and are usually the distractor. The published guidance is explicit that simple, composable patterns beat complex frameworks, and the practical reason is debuggability: frameworks hide the loop, the prompt and the exact request being sent, which is precisely the layer you need visibility into when an agent misbehaves. Prefer the smallest amount of machinery that supplies what you are missing.

Trap 3 — 'Sub-agents can see what the orchestrator knows'

Delegation is attractive and routinely misunderstood. A sub-agent runs with its own context window; it does not inherit the parent's conversation, its reasoning, or the shorthand the parent invented along the way. Every delegated task must therefore be self-contained — paths, constraints, and the shape of the report expected back. The corollary is that delegation is not free: each hand-off costs a round trip and a re-briefing, so splitting a job a single agent could finish in a handful of tool calls makes it slower and more expensive, not less.

Trap 4 — 'The run is getting long, so move to a bigger context window'

A larger window postpones the failure and worsens the symptom, because degradation tracks how much is in the window rather than how much room is left. The exam-correct responses are the ones that reduce what the model must hold: retrieve just in time instead of pre-loading, compact the history into a summary, persist findings to notes outside the window, or delegate a reading-heavy branch to a sub-agent that returns only its conclusion. 'Send everything and let the model sort it out' is wrong for the same reason at every scale.

How to study this domain

Because the three sub-skills are close in weight — 5.3%, 4.9% and 4.5% — resist specialising. Cover all three at moderate depth.

Start with the patterns; they are the cheapest points. Write the five names on a card — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — and beside each, one sentence on when it applies and one on its failure mode. Then practise the reverse direction, which is how the exam asks: read a described system and name the pattern. Sectioning versus voting inside parallelization is a favourite discrimination.

Next, build one agent by hand without a framework — a loop, two or three tools, an iteration cap, and an approval gate on the action that is hard to undo. Doing it once makes the construction questions concrete and shows exactly which parts a tool runner or managed platform would have supplied.

Finally, rehearse the restraint reflex: for every scenario, ask 'what is the simplest tier that solves this' before reading the options, and check the complexity, value, viability and cost-of-error test. That habit alone converts a large share of this domain.

Common questions

How many CCDV-F questions come from Agents and Workflows?

It is 14.7% of the blueprint — roughly 8 of the 53 scored questions, making it the third-largest domain. Its sub-skills are Agent Construction with Claude (5.3%), Agent Patterns and Frameworks (4.9%) and Agent Architecture (4.5%).

What actually separates a workflow from an agent?

Who owns control flow. In a workflow, models and tools are orchestrated through predefined code paths you wrote. In an agent, the model dynamically directs its own process and tool use. Both may call tools and both may take many steps; the difference is whether the sequence is yours or the model's.

Which workflow patterns should I be able to name?

Prompt chaining, routing, parallelization — with its sectioning and voting variants — orchestrator-workers, and evaluator-optimizer, all built on a model augmented with tools, retrieval and memory. Expect to be given a described system and asked to identify the pattern, rather than asked for a definition.

Should I use an agent framework?

Usually not as a first move. The published guidance favours simple, composable patterns over complex frameworks, and the practical argument is visibility: frameworks abstract away the loop and the exact request, which is the layer you need when debugging. If you want the loop handled without giving up that visibility, an SDK tool runner is the middle option.

How do I keep a long-running agent from degrading?

Reduce what is in the window rather than enlarging it. Retrieve content just in time behind lightweight identifiers, compact the history when it approaches the limit, have the agent persist findings to notes outside the window, and delegate reading-heavy branches to sub-agents that report back a conclusion. Larger windows delay the problem; they do not solve it.

Where should human approval sit in an agent?

At the actions that are hard to reverse — external writes, payments, deletions, outbound messages — not on everything. Blanket approval turns reviewers into clickers and provides no real control. Promoting those actions to dedicated tools rather than leaving them inside generic shell commands is what makes gating them possible in the first place.

Practise this domain

The CCDV-F bank is weighted to the blueprint above, so 14.7% of what you practise is this domain — and every option carries a written explanation, not just the correct one.

See CCDV-F

Other CCDV-F domains

Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.