Agent, or a workflow with an LLM step? Pick the boring one

A workflow is a system where the steps are written down in advance and a model fills in the parts that need judgement. An agent is a system where the model decides the steps at runtime. The words get used interchangeably in sales conversations and they describe architectures with different costs, different failure modes and different debugging stories.

This is about which one to build. The short answer is the boring one, more often than anyone selling you an agent will say.

The line, and who drew it

The cleanest formulation comes from Anthropic’s engineering write-up on building effective agents:

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.

Applied to something concrete: a chain that classifies an incoming email, looks the answer up in a table, drafts a reply and routes anything it cannot handle to a person is a workflow. Every step is written. The model decides which category the mail falls into, not what happens next.

The same task becomes an agent when you hand the model a set of tools (search the knowledge base, read the CRM, draft, escalate) and let it decide which to use, in what order, and when it is finished.

Both can produce the same output for the same input on a good day. They diverge on the bad ones.

The trade, in four rows

	Workflow	Agent
Path	Fixed in code	Chosen at runtime
Cost per run	Predictable	Varies with how much the model decides to do
When it fails	At a known step, with a stack trace	Somewhere in a loop, with a plausible-looking result
Handles the unexpected	No: routes it to a person	Sometimes, which is the appeal and the risk

Row three is the one that decides most real projects.

A workflow that breaks tells you where. An agent that goes wrong produces something that reads exactly like something that went right, and the only way to know is to check the outcome. That is why an agent needs an evaluation harness and a workflow mostly does not.

Row two matters at volume. An agent’s cost per run is a function of how many steps it decides to take, which means the bill is a distribution rather than a number. That is fine until the day something in the environment changes and the average number of steps quietly triples.

When a workflow is the right answer

When you can write the steps down. This is the whole test, and it is worth doing literally: try to write the path as a numbered list. If you can, you have a specification, and a specification implemented as code is cheaper, faster and more debuggable than the same specification rediscovered by a model on every request.

When the same input must produce the same output. Anything touching quoting, pricing, contractual language or compliance wants determinism. “Usually correct” is a different product from “correct”.

When you need to explain what happened. A workflow’s audit trail is its code plus its logs. An agent’s is a transcript of reasoning, which is longer, less stable and harder to defend to an auditor.

When volume is high and margins are thin. Predictable cost per run beats capable-but-variable at scale.

Most of what a go-to-market team automates falls here. Meeting preparation, inbound screening and email triage are all workflows with model steps inside them, and they are better products for it.

When an agent earns its keep

When the number of steps genuinely varies. Research tasks are the honest example: finding out whether a company matches a profile might take one lookup or nine, and which nine depends on what the earlier ones returned. Writing that as a fixed path means writing every branch.

When the tools are many and the right combination is not knowable up front. Past roughly a dozen tools, enumerating combinations in code costs more than letting the model choose.

When a person cannot be in the loop each time and the task tolerates being wrong sometimes. That second clause is doing a lot of work. Plenty of tasks tolerate it. Few of the ones people reach for first do.

Why the incentive points the wrong way

There is a commercial reason “agent” appears on more slides than the architecture warrants: it is the word that justifies the price. A workflow with a model step sounds like something a competent developer builds in a fortnight, which is often exactly what it is. An agent sounds like a capability.

Anthropic’s own guidance, from the people with the strongest possible interest in selling model capacity, points the other way: find the simplest solution that works, and add complexity only when it demonstrably improves outcomes. That advice is worth more than it looks, because it is against the author’s short-term interest.

It also lines up with the measured record. Reaching for the most autonomous architecture available is an approach problem wearing an engineering costume.

The failure rate for enterprise AI pilots is 95 %, and the differentiator was not model quality or regulation. It was how the system was fitted to the work.

MIT Media Lab, The GenAI Divide: State of AI in Business 2025

The middle ground nobody names

Most good production systems are workflows with one agentic step inside them, and the shape is worth naming because nobody sells it.

The chain is fixed: trigger, fetch, decide, act, log. One step in the middle, usually the research or the classification, is allowed to loop and choose its own tools, with a hard limit on iterations and a defined output shape. Everything around it stays deterministic.

That structure keeps the audit trail, keeps the cost bounded, and still handles the one part of the task where the number of steps genuinely varies. It also degrades sensibly: when the agentic step fails, the workflow around it routes to a person instead of improvising.

If you take one thing from this article, take that shape. It is what most “agents” in production actually are once you look at them, and building it deliberately is much cheaper than arriving at it after an incident.

How to decide, in one sitting

Write the task as a numbered list of steps. Then:

• The list is complete → build a workflow. Do not add a model where an if statement will do.
• One step in the list says “it depends” → workflow with one agentic step, iteration-capped.
• You cannot write the list at all → either an agent, or the task is not understood well enough to automate yet. Be honest about which. In our experience it is the second more often than the first.

The last case is the expensive one, because an agent is the only architecture that lets you skip understanding the problem and still ship something that demos well. That is precisely why it demos well.

Frequently asked questions