When you actually need an AI agent instead of a workflow

"Can we just make it an agent?" is the most common request I hear in enterprise GenAI work, and it almost always lands before anyone has written down what the task actually needs to do. The word carries a certain gravity now — agentic, autonomous, self-directed — so it gets reached for early, usually for a job that a plain script with one model call would handle better and more predictably.

Here is the decision stated plainly, before the nuance: build a workflow whenever you can write the steps down in advance, and reach for an agent only when you genuinely cannot. Most of what gets called an "agent problem" in a planning meeting is a workflow problem wearing a more exciting word.

What actually separates them

The difference is not capability, and it is not how clever the model is. It is who owns the control flow.

In a workflow, you own it. You write the sequence — fetch this, call the model here, branch on that result, stop there — and the model fills in the steps you hand it. The path is fixed in your code even when it has branches and loops. Anthropic's Building effective agents draws exactly this line: workflows orchestrate models through predefined code paths, while agents let the model direct its own process, choosing its tools and deciding when it is done.

In an agent, the model owns the control flow. It decides what to do next, which tool to call, in what order, and when to stop — at runtime, based on what it finds along the way. You are no longer writing the path; you are writing the environment and letting something non-deterministic navigate it.

That single shift — who decides the next step — is the whole distinction. Everything else follows from it.

The test I use

Before building anything, I ask one question: can you draw the steps on a whiteboard before you run it?

If you can — even with branches, even with a loop — it is a workflow, so build it as one. A support-ticket classifier, a document-extraction pipeline, a retrieval-augmented answer, a nightly reconciliation report: each has a shape you can enumerate, and enumerating it buys you something precious, which is a system that fails the same way twice.

You reach for an agent only when the path genuinely depends on information you cannot see until runtime, and the space of possible paths is too large to write down. "Investigate why this deployment is failing and fix it" is that kind of task — you cannot pre-plan the tool calls, because the third step depends on what the second one returns. That is where handing the control flow to the model actually earns its keep.

What the autonomy actually costs

And it is a cost, not a free upgrade. This is the part that gets skipped in the planning meeting.

Every degree of autonomy you hand the model, you pay back somewhere less visible:

• Determinism. A workflow runs the same path each time; an agent can take a different route on identical input, so "it worked in the demo" quietly stops being evidence.
• Evaluation. You are no longer testing an output, you are testing a decision process with a branching, open-ended trace — much harder to cover with cases.
• Cost and latency. Each decision is another model call. An agent that takes seven steps is seven round-trips where the workflow had one.
• Debuggability. When a workflow breaks you read the line that threw; when an agent breaks you reconstruct why it chose the path it did.

My rule, earned the boring way: the autonomy you add is not capability you gain for free, it is deferred cost you pay back in evals and observability. Add it only where enumerating the path is genuinely impossible, and you spend your reliability budget where it actually buys something.

rendering diagram…

Where the line falls in practice

Hold real tasks against the test and most of them sort themselves quickly. Classification, extraction, summarisation, a RAG answer, a fixed multi-step approval — workflows, every one, even though a model sits inside them. Open-ended research across sources you cannot list ahead of time, multi-step debugging, "take this goal and do whatever the situation needs" — those are the genuine agents.

The interesting cases sit in the middle, and the middle is where most enterprise "agents" actually live: a mostly-fixed pipeline with one point where a human would have used judgment. The honest build there is a workflow with a single LLM decision at that seam — not a loop handed the keys to the whole process. You get the judgment exactly where you need it and keep the determinism everywhere else.

FAQ

Isn't an agent just a workflow with a loop?

A loop is necessary but not sufficient. What makes it an agent is that the model, not your code, decides whether to go around again and what to do on the next pass. A workflow can loop a fixed number of times over a known operation; an agent loops because it judged the job unfinished.

Can I start with a workflow and upgrade to an agent later?

Yes, and you usually should. Build the workflow, watch where it actually fails for lack of runtime judgment, and hand the model control flow only at that seam. Starting agentic on day one means paying the full evaluation and observability cost before you know whether you needed any of it.

Do multi-agent setups change the rule?

No, they raise the stakes. Every agent in the system multiplies the non-determinism and the trace you have to evaluate. The same test applies to each one: if that agent's steps can be enumerated, it should have been a workflow node, not another autonomous process.

Before you build the "agent", try to draw its steps on a whiteboard — if you can, you already have your answer, and it isn't an agent.