Agents vs workflows: when you actually need an agent

Right now, “build an agent” is the default answer to almost every AI problem. It is usually the wrong one. The autonomous, do-it-all agent is the most exciting thing to demo and the most expensive, least predictable thing to run, and most of the tasks people point it at would be better served by something simpler and more reliable: a workflow.

The useful question is almost never “should we use AI?” It is “how much autonomy does this task actually need?” Get that right and you build systems that are cheaper, faster and trustworthy. Get it wrong and you build an agent to do a job a flowchart could have done, and then spend months trying to make it behave. This post is the real distinction between agents and workflows, and how to tell which one a task needs.

Three levels of autonomy

Think of it as a ladder, and climb it only as far as the task forces you to.

1. A single LLM call. Retrieval, a good prompt, maybe an example or two. A surprising share of “AI features” are just this, and should be. If one call does the job, stop there.
2. A workflow. An LLM and its tools orchestrated through predefined code paths. You decide the steps in advance; the model handles the parts that need language or judgement. The route is fixed; the content is flexible.
3. An agent. The LLM directs its own process, deciding what to do next and which tools to use, looping until it judges the task complete. You hand it a goal and it finds its own path.

The line that matters is between the last two. A workflow follows a route you drew. An agent draws its own. Everything about cost, predictability and how much you can trust the system flows from that one difference.

Workflows: the patterns that cover most needs

Workflows sound less impressive than agents, and quietly do most of the useful work. The reason is that most real tasks have a shape you can describe. A handful of patterns cover the vast majority:

• Prompt chaining: break a task into a fixed sequence of steps, each an LLM call, each feeding the next. Good when a task decomposes cleanly (draft, then check, then refine).
• Routing: classify the input first, then send it down the right specialised path. Good when different kinds of request need different handling.
• Parallelisation: run subtasks at the same time and combine them, or run the same task several times and take a vote. Good for speed, or for reliability through agreement.
• Orchestrator-workers: one LLM breaks a task into subtasks and delegates them to others, then synthesises the results. Good when the subtasks are not known until you see the input, but the pattern is fixed.
• Evaluator-optimiser: one LLM produces an answer, another critiques it against criteria, and it loops until good enough. Good when you have a clear quality bar.

Notice what these share: the control flow is decided by you, in code. That makes them predictable, testable, cheaper, and far easier to trust in production. When someone asks what a system will do, you can answer, because you wrote the paths.

Agents: real, but narrower than the hype

An agent is what you need when you genuinely cannot draw the flowchart in advance. It runs a loop: look at the goal and the current state, decide the next action, use a tool, observe the result, and repeat, until it decides it is done or hits a stopping condition. That autonomy is the whole point, and the whole risk.

Agents earn their place when three things are true at once:

• The task is open-ended, and the number and order of steps genuinely vary with the input, so a fixed path would be brittle or impossible.
• The value of dynamic decision-making is high enough to justify the cost and unpredictability of handing the model control.
• You can trust the model’s decisions enough, within tight guardrails, to let it act without a human approving every step.

Coding assistants that explore a repository, research tasks that follow leads wherever they go, support cases that require different investigations each time: these are real agent use cases, because you cannot know the steps until you are in them. We cover the broader shape in AI agents, explained.

The trade-off, stated plainly

Autonomy is not free. Compared with a workflow, an agent:

• Costs more. It makes more model calls and uses more tokens, often many times more for the same outcome.
• Runs slower. Each loop is another round trip.
• Is harder to predict and debug. The same input can take a different path twice, which is the point, and also the problem.
• Compounds errors. A small mistake early in a long chain of self-directed steps can snowball, where a fixed workflow would have caught it at a defined checkpoint.
• Is harder to guardrail. More freedom means more surface area for it to do something you did not intend.

A workflow gives up flexibility and gets back predictability, lower cost, and testability. For most tasks, that is a very good trade.

So when do you actually need an agent?

The honest decision rule is: default to the simplest thing that works, and only add autonomy when the task forces you to.

• If one call does it, do that.
• If you can draw the steps, build a workflow. The fact that the steps involve judgement or language does not make it an agent; it makes it a workflow with LLM steps.
• Only when you cannot script the path, because it genuinely changes every time, do you need an agent. And even then, the best agents are the least agentic ones that still solve the problem: as much structure as you can impose, as much autonomy as you truly need.

This maps onto a distinction we have made before from the business side: most processes follow rules and are better served by automation or a workflow than by an autonomous agent. “Agent” as the reflexive answer is how you end up with something more expensive and less predictable than the problem ever required. The engineering version of the same point: reach for the loop last, not first.

If you do build an agent, build it governed

When a task genuinely needs an agent, the difference between a demo and something you can put near real work is the structure around the loop:

• Scope the tools tightly. Give it only the actions it needs, with permissions to match. Its power is its tools, so its tools are your control surface.
• Ground it. Reliable retrieval and checks against hallucination, so its decisions rest on real information.
• Set stopping conditions and budgets. A maximum number of steps or spend, so a confused agent fails safe instead of looping forever.
• Put humans at the decisions that matter. Autonomous where it is safe, a human checkpoint where it is not.
• Make it observable, and evaluate it. Log what it did and why, and test it with an evaluation harness, because you cannot trust what you cannot inspect.

That is the difference between an agent that is a liability and one that is governed and safe to ship.

The short version

Agents and workflows are not rivals; they are different amounts of autonomy for different jobs. A workflow orchestrates LLMs and tools through paths you define, and it is cheaper, faster, more predictable and easier to trust. An agent lets the model direct its own process, which you want only when the task is genuinely open-ended and cannot be scripted. Start with the simplest thing that works, climb to a workflow when you can map the steps, and reach for an agent only when you truly cannot, then wrap it in tight guardrails. Most tasks need less autonomy than the hype suggests, and are better for it.

We build AI agents and automation at the right level of autonomy for the job, structured workflows where that is what the task needs, governed agents where it genuinely needs one, not an autonomous system for a problem a flowchart would have solved. If you are trying to work out which your process actually needs, talk to us.