Most AI agents should have been workflows
An agent decides its own next step in a loop; a workflow runs a fixed path and calls the model only where the input is fuzzy. Why the workflow is usually cheaper, more testable, and easier to audit — and when an agent is actually justified.
The word "agent" has quietly become the default way to describe anything that uses a language model to do work. It shouldn't be. An agent and a workflow are different architectures with different failure modes, and most of what gets shipped as an agent would be more reliable, cheaper, and easier to defend as a workflow. The distinction is not academic. It decides how the system fails, how much it costs to run, and whether anyone can test it before it touches production.
Two architectures, one model
An agent decides its own next step in a loop. It reads a goal, chooses an action, observes the result, and chooses again, until it decides it is done. A workflow runs a fixed path you defined in code and calls the model only at the points where the input is genuinely fuzzy. Both use the same LLM. The difference is who owns the control flow. In an agent, the model does. In a workflow, you do — and you hand the model the one job it is actually good at: turning messy input into a structured decision at a single step.
The loop is where the cost lives
Every iteration of an agent's loop is another model call, another chance to wander off the path, and another output you cannot unit-test because it is non-deterministic by design. Give the loop tools and the blast radius grows: a wrong turn no longer just produces a bad sentence, it writes to a database or calls an API. Debugging becomes archaeology — you are reconstructing a chain of model decisions that will never reproduce the same way twice.
A workflow inverts this. The path is code you can read, version, and cover with tests. The one model call in the middle is isolated, logged, and easy to reason about. When it goes wrong, you know exactly which step produced the wrong output, because there is only one that could.
When an agent is actually justified
None of this means agents are never the right tool. Reach for one when the path is genuinely dynamic — when you cannot enumerate the steps ahead of time because the next action depends on what the previous one discovered, and the space of actions is open. Open-ended research, interactive troubleshooting, tasks where the plan itself has to be invented at runtime: those earn the loop.
The test is simple. If you can draw the flow as a fixed set of steps on a whiteboard, you don't need an agent; you need those steps in code with a model on one of them. Most enterprise tasks pass that test. Classify this document, extract those fields, draft that reply, route this ticket — a known sequence with one or two soft spots, not an open problem.
The plain description of most "AI agent" projects is "we wrote six functions and called a model in one of them." That is not a lesser system. It is cheaper to run, because you are not paying for a loop to rediscover the same path on every request. It is easier to audit, because a deterministic, logged path is something a reviewer — or, under the AI Act's logging requirements for high-risk systems, a regulator — can actually reconstruct. And it fails in ways you can debug, because the failure is located at one step instead of smeared across a conversation. Choosing a workflow is not settling for less ambition. It is refusing to pay the operational tax of autonomy you don't need.
Which of your "agents" is really a workflow with good marketing?