In this guide
AI Agent vs Automation
Automation runs steps a person decided in advance. An AI agent is given a goal and works out the steps itself, while it runs. Automation does the same thing every time. That's exactly what you want for most business processes, and exactly what fails the moment something unexpected turns up. If you already have automation that works, the useful question usually isn't whether to replace it. It's which single step inside it needs judgment.
What automation is
Automation is software doing a sequence of steps nobody has to supervise. A scheduled script that pulls yesterday's sales into a report. A rule in a tool like Zapier or Power Automate that files an attachment when an email arrives. A robotic process automation bot — RPA, which often drives an application's screen the way a person would, clicking and typing, when there's no API between the two systems to use instead. An API being a direct connection one program offers another.
Different tools, one shared property: a person wrote down every step and every branch beforehand. Nothing is decided while it runs. Give it the same input twice and you get the same behavior twice — deterministic, in the jargon — which makes it cheap, fast, and straightforward to audit when someone asks what happened.
An agent works without written rules
An agent isn't given the steps. It's given the goal, and a model — the AI system generating the responses — decides each move while it runs, which is why it can handle a case nobody wrote a rule for. The AI agent page covers the loop.
The differences that matter here
| Automation | AI agent | |
|---|---|---|
| Input nobody anticipated | Breaks, or silently does the wrong thing | Often handles it |
| Marginal cost per run | Near nothing, licensing aside | Much higher — several model calls |
| When a system it touches changes | Stays broken until someone fixes it | Usually keeps working |
| Explaining what it did | Read the steps — they're fixed | Read the log of what it chose, afterward |
| Ongoing upkeep | Someone rewrites the rules when the process changes | Someone watches the outputs and adjusts the instructions |
Where automation actually breaks
Automation fails in two specific places, and those are the only spots where AI reliably earns its cost. If a process has neither problem, adding an agent makes it slower, more expensive, and less predictable in exchange for nothing.
Input that isn't structured
A rule can read a column in a spreadsheet. It cannot read "hi, can you push my delivery to next Tuesday — the earlier one was fine though" and work out which order is meant and what date to set. Free text, emails, PDFs from suppliers who each use their own layout, scanned documents, phone transcripts: this is where written rules run out, because there's no finite list of shapes the input will arrive in.
Things changing underneath it
Automation is coupled to the exact shape of whatever it touches. An RPA bot drives a screen by looking for particular fields in particular places, so a vendor's interface redesign breaks it. A script tied to a fixed file layout breaks when a column moves. The work itself didn't change; only its packaging did, and the automation can't tell the difference. Models are more forgiving here — one reading an invoice is far less likely to break outright when a supplier moves the total to the other side of the page, though its accuracy can still slip.
Which one does your process actually need?
Start by assuming automation, because for most processes it's the better engineering choice, not a compromise. Predictable, auditable, and effectively free per run are real advantages, and an agent gives up all three. Payroll runs, scheduled reports, moving structured records between systems — none of these want a model making decisions in the middle. If you're choosing an architecture from scratch rather than changing something you already run, agent vs workflow is the version of this question written for developers.
Reach for an agent when one of those two failures is genuinely present and there's no way to write the rules down. Working out why one customer's order never shipped is a good case: the answer might sit in the warehouse system, the payment processor, or the courier's records, and which one is worth checking next depends entirely on what the last one said. Nobody can write that sequence in advance, because it's different every time.
For most existing processes the answer is neither extreme. Keep the fixed process and put a model at the one step that needs judgment. Invoice handling is the standard shape: a model reads the incoming PDF and pulls out supplier, amount, and date, because that's the part rules can't do. Validating the amount, matching it against the purchase order that authorised the spend, and posting it to the ledger — the company's official record of money in and out — all stay as ordinary automation, because those steps are known and you want them exactly repeatable. That hybrid has a name and its own page: the agentic workflow.
Decoding "agentic automation"
Automation vendors now sell "agentic automation" or "agentic process automation," and the phrase covers two quite different products. One is a real agent deciding its own steps. The other, more common, is a fixed process with a single model call added at one point — the hybrid above.
Both can be sensible purchases. They fail differently and they bill differently. A fixed process with a model at step three has one place that needs watching. An agent directing the whole process can go wrong anywhere in it, and charges for several model calls on every run. Worth settling which one is on offer before comparing prices.