Workflows first. Agents when the branch cannot be written down.
The choice between a fixed pipeline and a model that decides its own next step is usually made for cultural reasons and defended for technical ones. There is a test that settles it, and it takes about ten minutes per use case.
There is a particular meeting where somebody says the word “agentic” and the room divides. One half hears ambition. The other half hears an unbounded loop with a corporate credit card attached. Both are responding to the same sentence and neither is describing the system, because the system has not been specified yet.
The vocabulary is doing real damage here, so it is worth being precise. A workflow is a system where the steps are written in code and a model is called at particular points inside them. An agent is a system where the model chooses what to do next and when to stop. Anthropic’s engineering note on building effective agents draws the line in those terms, and the practical advice that follows from it — start with the composable pattern, graduate only when the task demands it — has held up better than most of what was written about agents in the same period.
The claim: the decision is not about how capable the model is. It is about whether you can enumerate the branches. If you can, writing them down is cheaper, faster, more testable and easier to govern than asking a model to rediscover them on every request. If you genuinely cannot, no amount of process discipline will make a fixed pipeline cover the space.
The test
Can you write down the set of steps this task can take, before you see the input?
- It is a workflow. Put the branches in code. Cheaper per run, deterministic to test, and the failure modes are the ones you already know how to handle.
- It is a workflow with a router. The model picks the branch, not the plan. You keep the ceiling on cost and the audit trail, and you get the flexibility where it is actually needed.
- It is an agent. Now specify the ceiling, the tools and the stopping condition. An agent without a stated maximum number of steps is a system that has declined to describe its own worst case.
Most enterprise tasks land in the first two rows and get built as the third, because the third is the one that demonstrates well. The demonstration is not lying: an agent handling a task a workflow could have handled looks more impressive, precisely because you can see it working things out. The cost of that appears later, in three places at once.
What the third row actually costs
| As a workflow | As an agent |
|---|---|
| Cost per run is bounded by the number of steps in the code | Cost per run is bounded by whatever ceiling you remembered to set |
| A test suite covers the branches, because the branches exist as code | Testing is sampling. Coverage is a statistical claim, not a list |
| A failure points at a step. Someone can go and read it | A failure points at a trajectory. Reproducing it needs the whole trace |
| The audit answer is the code path plus the inputs | The audit answer is the trace, and only if you kept it |
| A new capability means writing a branch | A new capability means a tool, and every tool widens the attack surface |
None of the right-hand column is an argument against agents. It is an argument against reaching for one before the left-hand column has been shown to be insufficient, which is a different and much weaker claim than the one usually being made in the room.
The last row deserves separating out, because it is where the security and the architecture arguments meet. Every tool an agent can call is an action the system can be induced to take by whatever text it happens to read. A workflow with a model at step three can only ever do what step four does next. An agent with a tool can do anything that tool does, in any order, on any input — which is why the meaningful safety property of an agentic system is not how autonomous it is but which of its actions cannot be undone.
If it is genuinely an agent
Four things have to be written down before the build, and they are cheap now and expensive later.
The stopping condition is the one that is most often missing and most often the cause of the bill. A task that terminates when the model says it is finished has delegated the exit criterion to the component with the least incentive to apply it. Something outside the loop — a schema, a validator, a system of record — should be able to say whether the work is done.
What this does not tell you
This is not a claim that agents do not work. They do, and there is a class of task — open-ended research, triage across systems that were never designed to be queried together, work where the next step really does depend on what the last one found — where a fixed pipeline is a worse answer at any price.
It is also not a claim that the choice is permanent. The best sequencing we see is a workflow first, instrumented, with the branch distribution measured. If a long tail of requests keeps falling outside the written branches, that is evidence for an agent, produced by the system itself rather than by an architecture argument in a meeting.
The person who decides differently after reading this is whoever is about to approve the build. The question to ask is not “should this be agentic”. It is “which branches can you not write down”, and if the answer is a pause, the system in front of you is a workflow that has not been specified yet.