Agents vs workflows
A workflow follows a path you decided in advance; an agent decides its own path at runtime. The difference is who chooses the next step, and it changes cost, testing and every failure mode that follows.
Short answer
In a workflow, you decide the sequence of steps in code and the model does the work inside each one. In an agent, the model decides which step comes next, using tools, until a stop condition fires. Choose the workflow whenever the steps are knowable before the run, because it is cheaper, faster and far easier to test. Reach for an agent only when the number of steps, or their order, genuinely cannot be known until the work starts.
These two get conflated because they are built from the same parts. Both call a model. Both usually give it tools. Both can look identical from outside, since the user sends a request and gets an answer. The difference is structural and it sits in one place: who chooses what happens next.
A workflow encodes that choice in your code. You wrote the sequence, you can read it, and it runs the same shape every time. An agent hands the choice to the model, which decides at each turn what to do with what it has just learned. That single change turns a system with bounded cost and testable stages into one with an open-ended trajectory, which is a genuinely different engineering problem.
The reason this matters for the exam and in production is the same: the instinct is to reach for the agent because it sounds more capable, and most tasks do not need one. Anthropic's own engineering guidance is blunt about it, recommending the simplest thing that works and adding complexity only when it demonstrably improves outcomes. Questions in this area are usually built to reward that judgement, with the more elaborate architecture visibly available and visibly unnecessary.
Workflow vs Agent, side by side
| Workflow | Agent | |
|---|---|---|
| Who chooses the next step | You do, in code, before the run starts | The model does, at each turn, from what it has just seen |
| Cost and latency | Bounded and predictable. One or a few model calls per stage. | Open-ended until a stop condition fires. One task can run many turns. |
| Typical failure | A stage produces poor output, and you can see which stage | The loop takes a wrong turn early and builds confidently on it |
| How you test it | Each stage in isolation, much like ordinary code | End to end, on outcomes and trajectories rather than steps |
| What it needs from you | A good prompt per stage, and the glue between them | Good tools, a clear stop condition, and a budget it cannot exceed |
| Where it wins | The task decomposes the same way on every run | The shape of the task depends on what earlier steps find |
The dividing line is control, not capability
A workflow is not the less capable option. Routing a support message to one of four specialised prompts is a workflow, and the routing decision is still made by a model. Splitting a document into sections, summarising each in parallel and merging the results is a workflow, and every summary is model work. What makes it a workflow is that you wrote the sequence: the router always routes, the merge always merges, and no run invents a step you did not anticipate.
An agent removes that guarantee on purpose. Given a goal and a tool set, it decides for itself whether to search first or read first, whether to try again or give up, and when it is finished. That freedom is the whole point when the task needs it, and it is pure cost when it does not.
The workflow patterns worth knowing by name
Five recur often enough that questions assume you can name them:
- Prompt chaining: split a task into ordered steps, each working on the last one's output, with a programmatic check between steps where it helps
- Routing: classify the input, then send it to the prompt or model best suited to it
- Parallelisation: run independent subtasks at once, either sectioning a job into pieces or voting by running the same job several times
- Orchestrator and workers: a model breaks the task into subtasks at runtime, workers do them, and the orchestrator merges
- Evaluator and optimiser: one call produces, another critiques against criteria, and the pair iterates
Orchestrator and workers is the one candidates most often mislabel as an agent, because the subtasks are decided at runtime. It is still a workflow: the orchestrate, delegate, merge shape is fixed in your code.
What an agent is, mechanically
Strip away the vocabulary and an agent is a loop. You call the model with a goal and a set of tools. It returns a request to use one or more of them. Your code executes them and returns the results. You call the model again with the results appended. That repeats until the model stops asking for tools, or until you stop it.
Everything else is scaffolding around that loop, and it is where the engineering actually lives: which tools exist, how well their descriptions tell the model when to reach for each, what the environment returns as feedback, what the stop condition is, and what budget of turns or tokens or money the loop is allowed to spend. An agent with excellent tools and a weak stop condition is a bill, not a system.
Cost, latency and the budget question
A workflow's cost is a sum you can write down before you ship. Three stages, one call each, and you know what a request costs and roughly how long it takes. That is what lets you put it behind a synchronous request with a human waiting.
An agent's cost is a distribution. Most runs finish quickly and some do not, and the tail is where the money goes. That makes an explicit budget part of the design rather than an operational afterthought: a maximum number of turns, a token ceiling, and a defined behaviour when either is hit. Deciding what the system does when it runs out of budget, rather than simply stopping, is one of the marks of a design that has been thought through.
Escalate only when the simpler thing fails
There is a ladder, and the useful discipline is to climb it one rung at a time. A single well-written call, with retrieval and tools where they help, solves more than people expect. When a task has genuinely distinct stages, a workflow makes each one visible, testable and separately improvable. Only when the sequence cannot be written down before the run does an agent earn its complexity.
The practical test is a question you can answer honestly at design time: can I write out the steps? If yes, write them out, and you have a workflow. If the answer is genuinely no, because the second step depends on what the first one discovers in a way you cannot enumerate, that is the case an agent exists for.
How to choose
Reach for workflow when
- The steps are the same on every run, even when the content differs
- You need predictable cost and latency, because a user is waiting
- Each stage has a checkable output you can regression-test
- You could describe the sequence to a new colleague before seeing the input
- Failures need to be attributable to a specific stage
Reach for agent when
- The number of steps depends on what earlier steps find
- The work is open-ended search, triage or repair rather than transformation
- The environment gives real feedback the model can act on, such as test results or API errors
- You can state a clear, checkable stop condition
- You can afford a variable number of model calls per task, and can cap it
Where candidates go wrong
Trap 1: the agent is the more advanced answer, so it is the better answer
This is the single most common wrong choice in this area, and questions are frequently built around it. The scenario describes a task with three obvious stages, and one option proposes an autonomous agent with a tool set. It sounds like the sophisticated answer. It is the expensive one. The agent will rediscover the same three steps on every run, at a variable cost, with no stage boundary to test against and no way to tell which part went wrong when the output is poor. Where the steps are knowable, encoding them is not a lack of ambition; it is the reason the system can be measured and improved.
Trap 2: it calls tools, so it is an agent
Tool use and agency are separate properties. A single model call that fetches a record and formats a reply uses a tool and is not an agent, because your code decided that the record would be fetched. Add retrieval, add memory, add several tools, and it is still a model call with capabilities attached. What makes something an agent is the loop plus a model-chosen path: the model deciding, turn after turn, which capability to use next based on what came back. Options that define an agent by its tool list rather than by who controls the sequence are testing exactly this confusion.
Trap 3: the agent failed because the model was not capable enough
When an agent loops, wanders or stops early, the instinct is to reach for a heavier model. That occasionally helps and usually does not, because most agent failures are design failures that a stronger model executes more confidently. The usual culprits are a stop condition that was never defined, a budget that was never set, tools whose descriptions do not say when to use them, and an environment that returns nothing the model can act on. A tool that fails silently instead of returning a structured error leaves the loop guessing, and no model tier fixes that. Diagnose the scaffolding before the model.
Trap 4: a workflow means the whole thing is hardcoded
Candidates sometimes read workflow as a system with no model judgement in it, which makes the agent look like the only option whenever a decision has to be made. That is not the distinction. Routing delegates a classification decision to a model. An evaluator and optimiser pair delegates a quality judgement. An orchestrator decides at runtime how to break the task up. All three are workflows, because the shape of the run is fixed even though the content of each decision is not. Judgement inside a fixed structure is still a workflow.
How the exam tests it
Agents and Workflows is 14.7% of the CCDV-F blueprint, roughly 8 of the 53 scored questions, and it is split into Agent Architecture (4.5%), Agent Construction with Claude (5.3%) and Agent Patterns and Frameworks (4.9%). The distinction on this page runs through all three sub-skills, and the pattern names above are the vocabulary the questions assume.
Common questions
What is the difference between an agent and a workflow?
A workflow runs a sequence you wrote in code, with the model doing the work inside each step. An agent runs a loop in which the model chooses the next step itself, from the tools available and what it has learned so far. The dividing line is who controls the sequence, not how many tools are involved or how capable the system is.
Is prompt chaining an agent?
No. Prompt chaining is the simplest workflow pattern: fixed steps in a fixed order, each working on the previous step's output. Nothing in the run is chosen by the model, so the cost is predictable and each link can be tested on its own.
Is an orchestrator with worker calls an agent?
It is usually classed as a workflow, and this is the case people get wrong most often. The orchestrator decides at runtime how to split the task, which feels agentic, but the overall shape is fixed in your code: orchestrate, delegate, merge. An agent has no such fixed shape.
How do I stop an agent looping forever?
Give it three things: a stop condition it can actually reach, a hard budget in turns or tokens, and defined behaviour when the budget runs out. Tools that return structured errors rather than silence matter as much, because a loop with no usable feedback keeps retrying variations of the same failed move.
Do I need a framework to build an agent?
No. The loop is a model call, a tool execution and an appended result, repeated. Frameworks are useful once you want tracing, retries and standard patterns, but building the loop directly first is worth it, because most agent problems turn out to be in the tools and the stop condition rather than in the orchestration layer.
Which does the exam favour when both would work?
The simpler one, and the questions are usually written so that both are on the table. If the steps can be written down before the run, the workflow is the expected answer, because it costs less, fails more visibly and can be tested stage by stage.
Practise this
Agents and Workflows is 14.7% of the CCDV-F blueprint, and the bank is weighted to match. Every option carries a written explanation, not just the correct one, so a distinction like this one is explained where you get it wrong.
See CCDV-FOther CCDV-F distinctions
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.