Most agents should be workflows. Here is the test
If you can draw the steps in advance, write them as code and call the model inside them. Reach for an agent only when the next step genuinely depends on something you cannot know until runtime. Most systems described as agents fail that test, and they cost more and debug worse for it.
Three questions get muddled together here and they have different answers. Whether you need an agent at all is a capability question, and AI agent vs chatbot answers it: can this thing only answer, or does it need to act. Whether your agents should talk to each other is a topology question, and A2A and agent interoperability answers that one.
This piece is about the third: control flow. Given that the system needs to act, does your code decide what happens next, or does the model? That is the decision that determines what the thing costs, how it fails, and whether anyone can debug it at two in the morning.
The distinction, stated precisely
Anthropic's formulation from December 2024 is the cleanest available: "workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
Both use models. Both call tools. Both can be described in a pitch as an AI agent, and routinely are. The difference is who holds the control flow, and it is invisible in a demo because a demo runs the happy path where both look identical.
Anthropic go further in the same piece, and the recommendation is unusually blunt for a model vendor: "when building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all."
The test
One question decides it. Can you draw the steps in advance?
Sit with a whiteboard and the person who does the job today. If the process is: read the ticket, classify it, look up the account, check entitlement, draft a reply, then escalate if the value is over a threshold, that is a flowchart. The branches are known. The model is genuinely useful at several of those boxes and useless at deciding the shape, because the shape is your business process and it does not change per ticket.
Write that as code. Call the model inside the boxes where judgement is needed. What you have is a workflow, and it will be cheaper, faster, testable step by step, and explicable to an auditor.
The agent case is narrower than it sounds: the next step genuinely depends on something you cannot know until runtime. Open-ended research where each finding determines what to look at next. Debugging where the second question depends on the first answer. Triage across a domain too varied to enumerate. If you can enumerate it, you do not have that case.
What you pay for the flexibility
Handing control flow to the model is not free, and the costs land in three places.
| Workflow | Agent | |
|---|---|---|
| Cost per run | Predictable, roughly fixed | Varies with how much the model decides to do |
| Failure mode | A step fails, and you know which | It completed something, and you work out what |
| Debugging | Replay the step | Reconstruct the reasoning from traces |
| Changing behaviour | Edit the code path | Edit the prompt and re-measure everything |
On cost, Anthropic report from their own usage that "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats". They do not state the conditions those ratios were measured under, so treat them as an order of magnitude rather than a number to budget against. The direction is the useful part, and it matches what we see: latitude costs tokens, and it costs them unpredictably, which is worse than costing more.
The debugging column is the one teams underestimate. When a workflow misbehaves you look at which step returned what. When an agent misbehaves you are reading a transcript trying to infer why it chose a path, and the answer is frequently that it would choose differently next time. That is the property you asked for.
The shape that usually wins
Most good systems we build are workflows with one agentic step, rather than one or the other.
The deterministic parts stay deterministic: fetching, validating, routing, writing, notifying. Somewhere in the middle there is one box where the work genuinely cannot be enumerated, and that box gets a model with tools and a budget. It runs, it returns a result, and the workflow resumes control.
This is worth designing deliberately, because it gives you the flexibility where it is needed and containment everywhere else. The agentic step has a step limit and a spend cap, and the actions it can take are decided before it starts rather than by what it reads, which is the same constraint we argue for in prompt injection.
Why the market says agent anyway
Some of this is genuine ambiguity and some is labelling. Agent is what gets funded, so workflows get described as agents in decks, and buyers reasonably conclude that agents are what everyone is building. It is worth being specific in your own requirements, because a vendor quoting for an agent when you need a workflow will build the more expensive thing and both of you will call it a success.
The question to put to any proposal: which decisions does the model make at runtime, and what happens if it makes a different one tomorrow. A good answer names a small number of specific decisions. A vague one usually means nobody has drawn the flowchart, and the flowchart is the thing you are actually buying.
If you want the flowchart drawn before anyone quotes for a build, that is what our free AI audit produces, and how we build orchestration covers the workflow-with-one-agentic-step pattern in practice.
Related reading
Get this applied to your business.
The free AI audit measures your live setup and shows where AI would actually pay off.