The distinction is who chooses the next step
A workflow automation has its path decided in advance. When this happens, do that, then that. The model, if one is involved at all, fills in a value somewhere along a route that was fixed before the run started.
An agent is given a goal and chooses its own steps, including which tools to call and in what order. The path is decided during the run, and it can differ every time.
Everything else — cost, latency, reliability, how you test it — follows from that one difference.
Fixed paths are cheap and boring, which is the point
A workflow costs what its steps cost. It takes as long as its slowest step. It fails in a small number of ways you can enumerate, and when it fails you can point at the step. You can write a test that asserts the whole thing end to end, because the path is knowable.
For the overwhelming majority of business processes this is exactly what you want. Lead routing, data sync, notification, report generation, document handling — none of these need anything chosen at runtime. They need to be right every time.
Agents earn their cost when the path genuinely cannot be known
There are real problems where enumerating the branches is impractical. Investigating an open-ended question across several systems. Handling a request that could be any of forty things. Working through a task where step three depends on what step two turned up.
For these, an agent is not overengineering — a workflow covering the same ground would be an unmaintainable tree of conditionals. But be honest about which problem you have, because the agent shape costs more on every axis.
- Cost: several model calls per run rather than zero or one, and the count varies
- Latency: seconds to minutes rather than milliseconds
- Testing: the same input can produce different paths, so assertions have to be about outcomes, not sequences
- Debugging: you are reconstructing a decision, not reading a route
Bound what an agent can reach
The blast radius of a workflow is whatever its steps touch, and you can read them. The blast radius of an agent is every tool you gave it, in any order, any number of times.
That means the tool list is the real security boundary. Give it the narrowest possible set. Prefer tools that read over tools that write. For anything destructive or externally visible — sending mail, issuing refunds, deleting records — require a human approval step rather than trusting the model to have judged correctly.
A useful test: if the agent did the most damaging combination of its available actions, what would that cost? If the answer is unacceptable, the tool list is wrong, not the prompt.
Most useful systems are mostly workflow
In practice the strongest designs are a fixed pipeline with a model at one or two specific points. Classify this. Extract these fields. Draft this reply. The surrounding structure — validation, routing, storage, retries, notification — stays deterministic.
This gets most of the benefit of using a model while keeping the properties that make a system operable. When something breaks you are usually looking at one step with a known input and a known expected output, which is a debuggable situation.
Decide by the failure you can live with
Ask what happens when it gets it wrong, because it will. If the answer is "a person notices and fixes it in a minute", either shape is fine. If the answer is "a customer receives something incorrect" or "a record is changed and nobody knows", you want the fixed path, and you want a person in front of the irreversible step.
Start with the workflow. Add the agent when you have a concrete case where enumerating the branches has actually become the problem.
Cost is variable in a way a workflow's is not
A workflow's cost is a known number per run. An agent's is not: it depends on how many steps it chose to take, and that varies with the input. The same task can cost twice as much on a Tuesday because the phrasing was ambiguous.
That matters for budgeting, and it matters more for the failure mode. An agent stuck in a loop — calling a tool, getting an unhelpful result, trying again — can spend a great deal before anything notices. A hard cap on steps and on total spend per run is not an optimisation; it is the thing standing between a bad input and a large bill.
- Cap the number of steps per run, and log when the cap is hit
- Cap total spend per run, and per day
- Alert on runs that hit either cap, since that is where the pathologies live
Testing an agent is a different discipline
A workflow is tested by asserting that a given input produces a given output. That works because the path is fixed.
An agent's path varies, so the same assertion style produces flaky tests that fail for reasons unrelated to correctness. What you can assert is the outcome: the record ended up in the right state, the answer contains the right facts, no forbidden tool was called. Build a set of real inputs with known-good outcomes and measure the pass rate rather than expecting determinism.
A pass rate also gives you something a binary test cannot — the ability to tell whether a prompt change helped, which is otherwise guesswork.
The hybrid shape in practice
Most useful systems are a fixed pipeline with a model at one or two specific points, and the interesting design work is deciding where those points are.
A good rule: the model handles the step where the input is unstructured and the output is small and checkable. Everything around it — deciding what to do with that output, where it goes, what happens on failure — stays deterministic code you can read.
That shape keeps the debuggable properties of a workflow while getting the part of the model that is genuinely hard to replace.