← Back to Insights

Comparison

8 min read

AI agents vs simple automation: which does your process actually need?

By Ben Gould · Published 12 August 2026

AI Agents
Workflow Automation
Process Automation
Reliability
AI Strategy

A simple automation follows steps you define. An AI agent decides the steps itself. Most processes described to me as "agent problems" turn out to be deterministic workflows with one or two judgement calls buried in them - and those are cheaper, faster and far easier to trust when you build them as a workflow with AI at the judgement points.

I build both, so I have no stake in talking you into either. But "agent" has become the word people reach for when they mean "automate something clever", and the mismatch costs real money. Here is how to tell which one your process actually needs.

What is the difference between an AI agent and a simple automation?

The difference is who chooses the next step.

  • A simple automation - a workflow - runs a path you designed. When an invoice arrives, extract the fields, match it to a purchase order, post it to the ledger, flag anything that does not reconcile. The route is fixed. The same input produces the same behaviour every time.
  • An AI agent is given a goal and a set of tools, and works out its own route. "Reconcile this month's invoices" - and the model decides what to look up, which tool to call, when it is finished. The route is decided at runtime, and it can differ on every run.

Everything else - which model, which platform, how clever the prompt - is detail. The question that decides your architecture is whether the sequence of steps is knowable in advance. For most business processes, it is.

How do the two compare in practice?

There is a middle option that gets skipped, and it is usually the winner: a deterministic workflow with AI called at the specific steps that need judgement.

Deterministic workflowWorkflow with AI stepsAutonomous agent
Who picks a pathYou, at design timeYou, at design timeThe model, at run time
PredictabilityTotalHigh - variation only at the AI stepLow - varies run to run
Cost per runNegligibleOne or two model callsMany model calls, unbounded
Failure modeStops loudlyStops, or one bad judgementWanders, loops, or fails plausibly
DebuggingRead the logsRead the logs, inspect the promptReconstruct a path you did not design
OversightExceptions onlyExceptions and spot-checksContinuous, until trust is earned
Best whenRules are clear and stableRules are clear, inputs are messyThe task genuinely cannot be pre-scripted

Read across that table and the pattern is clear. Autonomy is not a free upgrade - you buy flexibility with predictability, cost and the ability to work out what went wrong.

Why do most "agent" problems turn out to be workflows?

Because the thing that felt intelligent about the process was usually one step, not the whole process. Someone reads an email and decides which category it is. Someone looks at a scanned document and pulls out five fields. Someone judges whether a customer complaint needs escalating. Those steps need a model. The twelve steps around them - fetch, route, write to the CRM, notify, log - are plumbing, and plumbing wants to be deterministic.

Wrap the whole thing in an agent and you have handed the plumbing to a probabilistic system that will occasionally decide to do it differently. You get non-determinism where you wanted reliability, and you pay a model call for each step of it.

You do not have to take my word for the distinction. Anthropic - a company whose commercial interest lies in you building more agents, not fewer - draws exactly this line in its own engineering guidance, separating workflows, where "LLMs and tools are orchestrated through predefined code paths", from agents, where "LLMs dynamically direct their own processes and tool usage". Its recommendation is to find "the simplest solution possible, and only increasing complexity when needed" - and it is blunt about where that leads: "This might mean not building agentic systems at all" (Anthropic). When the model vendor tells you to reach for the workflow first, that is worth hearing.

The evidence supports the caution. In TheAgentCompany, a Carnegie Mellon and Duke benchmark of 175 real office tasks spanning software, project management, data, admin, HR and finance roles, the best-performing agent completed just 30.3% of them autonomously (arXiv). Those are precisely the long-horizon, cross-system jobs a business would most want to hand over - and roughly seven in ten still ended up needing a person. Agents work. They are just being sold for jobs a workflow would do better.

When does an AI agent genuinely earn its keep?

When the sequence of steps honestly cannot be known before the task starts. The signals:

  • The path depends on what it finds. Open-ended research, investigation, triage across systems where step three depends on what step two turned up.
  • The step space is large and sparse. Too many possible routes to enumerate, and most inputs use only a few of them.
  • A wrong turn is cheap and recoverable. Drafting, exploring, summarising - work a person reviews before anything irreversible happens.
  • The value is in the exploration itself, not in doing the same thing consistently every time.

Notice the shape of that list: it describes discovery work, not operational work. Month-end close, invoice processing, lead routing, onboarding, reporting - the processes that actually cost money - are repetitive by definition. Their whole value is that they happen the same way every time. That is a workflow, and building it as an agent means paying a premium to make it less reliable.

What does autonomy cost you that a workflow doesn't?

Four things, and they are all operational rather than technical:

  • Unbounded cost. A workflow's cost per run is fixed and knowable. An agent decides how many model calls to make, and a difficult input can cost ten times a typical one - in that same benchmark, the leading agent averaged 27 steps and around $4 per task attempted, whether or not it finished. Budgets and per-task limits stop being optional, which is one reason multi-model setups end up behind an AI gateway.
  • Harder debugging. When a workflow breaks, you read the logs and find the step. When an agent produces the wrong outcome, you are reconstructing a path you never designed, from a run that may not repeat.
  • Plausible failure. A broken workflow stops. A confused agent keeps going and returns something that looks right. The second failure mode is far more expensive, because it reaches your customers.
  • Real oversight. Anything an agent can do unsupervised, it can do wrongly unsupervised. Deciding where a person stays in the loop is part of the design, not a phase two.

None of this is an argument against agents. It is an argument for knowing which one you have chosen, and pricing it honestly.

Can you have both?

Yes, and this is what I build most often. Keep a deterministic skeleton - the triggers, the routing, the writes to your systems of record, the error handling - and call a model only at the steps that need judgement. Classification here, extraction there, a drafted reply somewhere else. Each AI step has a defined input, a defined output and a fallback when it is unsure.

You get the intelligence where it matters and predictability everywhere else. Just as usefully, you can change your mind: an orchestration layer such as n8n lets you swap the model behind any one step, or promote a step to something more autonomous later, without rewiring the process around it.

How do you decide, in practice?

Before you pick an architecture, answer four questions about the actual process:

  1. Can you draw it? If you can sketch the steps on a whiteboard, it is a workflow. Agents are for the processes you genuinely cannot draw.
  2. Where is the judgement? Mark the steps a person actually thinks about. Those are your AI steps. Everything else is plumbing.
  3. What happens when it is wrong? If a mistake is irreversible or reaches a customer, you want determinism and a human checkpoint, not autonomy.
  4. Is the process stable enough to automate at all? If it changes every month or nobody agrees how it runs, neither option will stick - fix the process first.

If the honest answers point at a workflow, build the workflow. It will ship in weeks rather than months, cost a fraction to run, and you will be able to prove what it saved - which is the whole point of a first AI project.

The bottom line

An agent decides its own steps; a workflow runs the steps you designed. Autonomy is a real capability, but you pay for it in predictability, cost and debuggability - and most of the processes that cost UK SMEs money are repetitive ones where those are exactly the properties you want to keep. The right answer for the large majority of operational work is a deterministic workflow with AI at the two or three steps that need judgement. Start there. Add autonomy when a process genuinely cannot be scripted, not because the word is in the brief.

Working out which of your processes is which is usually a half-hour conversation, not a project. If you have a process that feels too clever to automate, that is the kind of thing a thirty-minute discovery call sorts out - I build the workflow where a workflow does the job, and the agent only where it earns its place. See process automation and AI consulting for how I approach it.

Related reading

Or see how I put this into practice: services, case studies.