- In short
- A workflow orchestrates Claude through predefined code paths, while an agent lets the model direct its own steps and tool calls at runtime. Prefer a workflow when the steps are known and repeatable, and an agent when the path depends on inputs discovered during execution. Because agents trade predictability and cost for flexibility, the simplest structure that meets the requirement wins.
Workflow vs agent: the decision this knowledge point tests
The first thing the Claude Certified Developer - Foundations (CCDV-F) exam asks you to do in Domain 1 is to look at a task and decide whether it should run as a workflow or as an agent. The two are not competing technologies. They are two ways of structuring the same building blocks, Claude plus some tools, and the choice between them is driven entirely by how predictable the task path is and how much decision-making has to happen at runtime.
A workflow orchestrates Claude through predefined code paths. You, the developer, decide the sequence: call the model here, parse the result, call this tool, branch on that value, call the model again. The control flow lives in your code, and Claude fills in the language-shaped gaps. An agent inverts that. You hand the model a goal and a set of tools, and the model itself decides which tool to call next, when to call it, and when the task is finished. The control flow lives in the model's runtime decisions rather than in your code.
- Workflow vs agent
- A workflow orchestrates Claude through code paths you define in advance; an agent lets the model direct its own steps and tool calls at runtime. Workflows are predictable and cheap; agents are flexible but trade away predictability and cost.
Known and repeatable steps point to a workflow
The cleanest signal that a task wants a workflow is that you can write the steps down in advance and they stay valid. Extract fields from an invoice, validate them against a schema, look up the vendor, and file the record: every run follows the same path, so encoding that path in code gives you a system that is cheaper to run, faster because it takes no unnecessary model turns, and far easier to test because the steps are fixed. When the procedure is known and repeatable, a workflow is almost always the better engineering choice.
Workflows also compose predictably. Because the path is yours, you can unit-test each stage, add retries where they belong, and reason about cost per run before you ship. This is the same instinct that shows up later in the SDK material: even when you use the Claude Agent SDK to build something more autonomous, the discipline of preferring the simplest structure that meets the requirement carries straight over.
Paths discovered at runtime point to an agent
The signal that a task wants an agent is that you cannot write the steps down in advance because they depend on things the system only learns while it runs. Consider a support task where the right next action depends on what the customer's account state turns out to be, which depends on what an earlier lookup returns, which depends on how the customer phrased the problem. There is no single fixed path; the path branches on discoveries. When the route through the task is data-dependent in ways you cannot enumerate ahead of time, letting the model choose its own steps is what an agent is for.
That flexibility is not free. An agent takes more model turns, each turn costs tokens and latency, and the behaviour is harder to test because the path is chosen at runtime rather than fixed by you. This is the core tradeoff the exam wants you to hold in your head: agents buy adaptability and pay for it in predictability and cost.
Choosing the simplest structure that works
The governing principle for this knowledge point is that the simplest structure that meets the requirement is preferred. That is not a stylistic preference; it is a cost-and-reliability argument. A workflow you can test end to end is more trustworthy than an agent whose path you cannot fully predict, so you should only pay for agentic flexibility when the task genuinely needs it. If the same requirement can be met by a fixed sequence of model calls, the fixed sequence wins.
What the CCDV-F exam trips candidates on
The exam tests two specific misreadings here, and both come straight from the traps in this knowledge point.
The first is reaching for an agent when a deterministic workflow would be cheaper, faster, and easier to test. A scenario will describe a task whose steps are actually fixed and repeatable, then offer an agent as a tempting answer because agents sound more capable. The credited answer recognises that autonomy adds cost and unpredictability the task does not need, so the workflow is the correct design.
The second is assuming that agent always means multi-agent. A single-agent tool-use loop, one model calling tools in a loop until it decides the task is done, is already an agent. The exam will use this to separate candidates who understand that the defining property of an agent is the model directing its own steps, not the number of agents involved. Do not let a single-agent design fool you into calling it a workflow, and do not assume choosing an agent commits you to a fleet of them.
Worked example
A team must build a system that turns uploaded receipts into ledger entries. Every receipt is processed the same way: OCR the image, extract amount and vendor, validate against the chart of accounts, and write a record. They are debating whether to build an agent.
Walk the task through the decision. Can the steps be known in advance? Yes: OCR, extract, validate, write, the same four every time. Do any steps depend on discoveries that would reroute the path unpredictably? No: a validation failure is a known branch you can code as an if-statement, not an open-ended decision that needs the model to improvise.
So this is a workflow. Encoding the four steps in code gives the team a system they can unit-test stage by stage, whose cost per receipt is predictable, and whose latency is bounded by a fixed number of model calls. Handing the same task to an agent would let the model decide the order of operations it does not need to decide, spend extra turns reasoning about a path that never varies, and produce behaviour that is harder to test for no benefit.
The tell that would flip the answer is a genuine runtime branch the team cannot enumerate, for example if the receipt could be any of dozens of document types requiring different, unpredictable follow-up lookups. Absent that, the simplest structure that meets the requirement is a workflow, and the workflow is correct.
Common misreadings to avoid
Misconception
Agents are the modern, better choice, so a new build should default to an agent.
What's actually true
Misconception
Choosing an agent means building multiple agents that coordinate.
What's actually true
How this shows up on the exam
Domain 1 questions on this knowledge point are classification questions: you are given a task and asked to pick the structure. The reliable method is to ask whether the steps can be fixed in advance. If yes, and the task offers no runtime branching you cannot enumerate, choose the workflow and justify it by cost, speed, and testability. If the path genuinely depends on what the system discovers while running, choose the agent and accept the tradeoff in predictability and cost.
Once you can make this call cleanly, the rest of Domain 1 builds on it. The construction knowledge points, starting with the Claude Agent SDK, assume you have already decided an agent is warranted, and the deployment question of self-hosted versus Anthropic-hosted only arises once you are building one. Getting the workflow-versus-agent decision right first is what keeps the rest of your design honest.
A developer needs to build a nightly job that reformats a fixed CSV export, validates it against a known schema, and emails a summary. The steps are identical on every run. Which structure best fits, and why?
People also ask
What is the difference between a workflow and an agent?
When should I use a workflow instead of an agent?
Is a single tool-use loop still an agent?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.