Most things marketed as AI agents this year are deterministic pipelines with a language model doing one or two of the steps. That is not an insult — a pipeline that runs reliably is worth more than an agent that doesn’t — but calling a pipeline an agent sets the wrong expectations for everyone who has to maintain it later. The distinction is not academic. Agents and workflows fail differently, get tested differently, and cost differently to change. Here is the test I run before I write a line of code or a line of a scope document.
The test itself
Remove one step from the system and watch what happens next. In a workflow, the system either breaks or quietly continues down the same rails minus that step — the path was fixed before the run started. In an agent, removing a step can change which step comes next, because the choice of next step depends on the state of the world at that moment, not on a diagram drawn in advance. If you cannot point to a moment where the system chose between genuinely different next actions based on new information, you are looking at a workflow.
Why the label matters
A mislabeled system gets tested against the wrong failure modes. Workflows fail at the edges — the input that does not match the expected shape, the API that returns something new. Agents fail in the middle, when a plausible-looking decision sends the whole run somewhere wrong and nothing downstream notices for a while. If a team builds a monitoring plan for an agent when they actually shipped a workflow, they spend budget watching for a failure mode that structurally cannot happen, and they miss the boring one that will. This is also a sales problem: buyers pay a premium for autonomy they are not getting, then feel cheated when the system needs the same rigid inputs a normal pipeline would have needed.
Where real agents earn their keep
Agents earn their added complexity only when the environment is genuinely unpredictable and the cost of a wrong branch is recoverable. Think customer support triage across an open-ended set of issues, or a research task where the next query depends on what the last one returned. In these cases a fixed sequence would either be enormous — trying to enumerate every path in advance — or brittle, breaking the moment reality drifts from the diagram. The tradeoff is that you now need to test decisions, not just outputs, and that is a harder, less mature discipline than testing a pipeline.
Where workflows quietly win
Workflows win almost everywhere the steps are actually known in advance, which is most business processes people want automated. Extracting fields from an invoice, drafting a first-pass email reply, summarizing a call transcript into a CRM field — these have a fixed shape even when a model does the language-heavy step in the middle. Building these as workflows means you get deterministic testing, predictable cost, and a system a junior engineer can debug by reading it top to bottom. Several of the workflows I have shipped for clients are exactly this: a model doing one hard step inside an otherwise ordinary pipeline, and everyone involved is better off for calling it that.
How to run the ten-minute test
Write the steps down as a list, then ask at each one: who or what decided this comes next, and could a different input have produced a different next step rather than a different output at the same step. If the answer is always “the diagram decided, before the run started,” you have a workflow. If at least one step routes to genuinely different next actions based on live state, you have at least a partial agent, and you should scope your testing and your pricing accordingly. Do this exercise with whoever is buying or building the thing — it takes ten minutes and prevents a much longer argument in month three.
What to do with the answer
If it is a workflow, build it, price it, and describe it as one, because that is where most reliable value actually sits right now. If it turns out you need real agentic behavior, budget separately for the evaluation work that comes with it, since that is the part vendors tend to leave out of the pitch. Either way, get the label right before the contract is signed — it is the cheapest disagreement you will ever avoid. If you want a second opinion on which one you are actually building, that is a conversation worth having through services or a quick note via contact before the architecture is locked in.