CCDV-F · Agents and Workflows
Workflow or agent, if the steps are fixed the path goes in code
A team built an agent to file claims: validate the data, look up the policy, calculate the amount and generate the letter. It’s always the same four steps, in the same order. Even so, every now and then the agent skips validation or calculates before looking up the policy. They added “ALWAYS IN THIS ORDER” to the prompt and it kept happening. The problem isn’t the prompt: they gave the model a decision it never needed to make.
The difference in one line
- In a workflow, your code decides the path: which step comes next, in what order and with which checks between them. Claude handles the parts that need language.
- In an agent, the model decides the path: it picks the next tool based on what has turned up so far, until the goal is met.
The agent gains flexibility and pays for it in cost, latency, predictability and ease of auditing. That’s why the rule is to start with the simplest thing that works: a single well-built call, then a workflow, and an agent only when the problem calls for one.
How to choose
| Question | If the answer is yes |
|---|---|
| Are the steps and their order known in advance? | Workflow |
| Do you need to guarantee an order or a check (validate before calculating)? | Workflow, with the check in code |
| Do the number and order of steps depend on what earlier steps reveal? | Agent |
| Does the model need to choose the next tool based on intermediate results? | Agent |
| Do you need to audit exactly what was done and why? | Workflow, or an agent with hooks that log everything |
A mixed case is very common: a fixed workflow where one of the steps is a bounded agent. For example, filing the claim is fixed, but “research the policyholder’s history” can be a small agent with two read-only tools and an iteration cap.
The workflow patterns
It pays to recognize them by name, because exam options describe them:
- Prompt chaining: the task is split into successive calls and each one uses the previous output, with checks in code in between. Useful when the task splits cleanly into fixed subtasks (extract, then summarize, then translate).
- Routing: a first call classifies the input and the code sends it down a specialized path. Useful for distinct categories that are better handled separately, even with different models (simple queries to Haiku, hard ones to a more capable model).
- Parallelization: several calls at once, either independent parts of the task or the same task several times to compare results.
- Evaluator-optimizer: one call generates, another evaluates against clear criteria and returns corrections, in a capped loop. Useful when there are explicit criteria and iteration measurably improves the result.
- Orchestrator-workers: a model decides on the fly how to split the task and delegates the parts. It’s already halfway to an agent; we cover it in the supervisor and subagents lesson.
The typical traps
- Building an autonomous agent for a fixed-step process “because it’s more modern”.
- Fixing an agent that skips steps with capital letters in the prompt, instead of moving the order into code.
- Thinking a workflow doesn’t use Claude: it uses it at every step, it just doesn’t let it choose the path.
- Ruling out an agent when the path truly can’t be predicted, as in open-ended research or a code fix that touches unknown files.
- Adding a framework or more agents without a concrete problem that justifies it.
On the exam
Look in the scenario for whether the steps are always the same. If they are and something “sometimes gets skipped or reordered”, the answer is to move to a workflow in code with checks between steps, not to reinforce the prompt or switch models. If the question asks for signals that justify an agent, pick the ones about unpredictable steps and choosing the next tool based on intermediate results. If the scenario describes a task that splits into fixed parts, look for the workflow pattern that fits by name.
Quick question
A practice exam question on this domain. It counts towards your progress.
A logistics team built its own tool loop on the Messages API for a warehouse assistant. It has four read-only tools, such as get_stock_level and get_inbound_shipments, and it often answers questions that need several lookups at once.
The harness takes only the first tool_use block from each response, runs it and sends back its tool_result. On questions that trigger several calls, the next request fails with a 400 error saying that tool_use ids were found without tool_result blocks. When it does work, users complain that multi-warehouse questions are slow, because each lookup takes about two seconds.
A teammate proposes retrying the 400 errors with backoff.
Which TWO changes should the team make? Select two.
Select all that apply.