AI agents vs AI automation
One picks its own steps. One follows yours.
Both are built on the same models, which is why two vendors can describe them so differently. What separates them is whether the steps can be written down before the work arrives.
Ask us which one fitsWhy two vendors gave you two answers
The confusion is mostly a naming problem. AI automation already has a model inside it, reading the invoice or classifying the email, so a vendor can call that an agent without lying. Nothing in the two words tells you which of them you were actually shown.
One question settles most of these. Could you write the procedure on a single page, hand it to a new starter, and have them work through it without asking you anything? If yes, you want automation, and paying for an agent buys unpredictability you did not need.
Where it bites
Where the two genuinely diverge
Both run on the same models and both can read an email or a PDF. The divergence is in who decides what happens next, and almost everything else follows from that.
Who chooses the next step
Automation runs the path you drew, and a person can point at the branch that fired. An agent chooses its next tool call per case, at runtime.
The case you did not anticipate
An automation with no matching branch drops the case into a human queue. An agent will attempt it — which is either the feature or the incident.
How you prove it works
Automation you test by assertion: this invoice yields these fields. An agent needs a scored evaluation set, because one input can take two different routes.
What it is allowed to touch
An automation touches only the endpoints you wired. An agent needs a written tool allowlist and a per-run spend cap, the document your risk review will ask for.
What a single run costs
An automation makes a fixed number of model calls per case. An agent loops until it decides it has finished, so cost per run has a tail.
How each one fails
A workflow fails loudly: the step errors and the retry queue fills. An agent usually fails plausibly, handing back a confident wrong action nobody queries.
What the log proves afterwards
Automation logs map onto a written procedure, which is what a compliance reviewer asks to see. An agent trace shows the route taken, not the route owed.
What has to exist first
Automation needs credentials and connected tools. An agent also needs written knowledge to ground its answers in, and a named person who signs off when it is unsure.
What counts as finished
An automation is finished when the last step returns. An agent judges that for itself, so a step ceiling and a time limit do the stopping.
Trade-offs
Four dimensions worth deciding on
Read these as trade-offs, not scores. Each one has a side that is genuinely worse, depending on who ends up living with the thing.
- COST OF CHANGE
- Cheaper on agents, if evals exist
- Adding a case to an automation means drawing a new branch. Adding one to an agent is often a prompt and a tool. That saving disappears the moment nobody re-runs the evaluation set.
- TIME TO LAUNCH
- Automation, by a matter of weeks
- One focused workflow ships in roughly 2–4 weeks. An agent wants scoping and a pilot on real cases before a 4–8 week build, and the pilot is where some agent projects sensibly stop.
- WHO MAINTAINS IT
- An ops lead, or an engineer
- An operations person can edit an automation branch the same day. Agent tuning means reading traces and re-scoring, which needs an engineer. The catch is that the model step inside an automation drifts too, and usually nobody owns it.
- WHAT BREAKS FIRST
- A renamed field, or a model update
- Automations break at the integration edge when a vendor renames a field, and they break in the open. Agents break when a provider ships a new model version and behaviour shifts quietly, which is what the evaluation set is for.
Which one to build
We build both sides of this, so read the steer as it is written. Most teams arriving at this page should build the automation first, and a fair number never need the agent at all.
Choose AI automation if…
- You could write the procedure on one page for a new starter
- The same shape of case arrives daily, like invoices or inbound email
- The same input must produce the same output every time
- An ops lead will own it after launch, not an engineer
Choose AI agents if…
- The task branches in ways you cannot list before seeing the case
- Finishing it means reading something, then deciding what to do next
- You have documents or ticket history the answers can be grounded in
- You can name who signs off when the system is unsure
Frequently Asked
Questions
Common questions from teams choosing between an agent and an automated workflow.
For most teams, the automation. If you can already describe the steps to a new starter, an agent adds a decision-maker you did not need and a class of failure you cannot assert against. Build the workflow, then read the cases that fall out to the human queue. If that fallout is small and repetitive, add branches. If it is large and each case is odd for a different reason, you now have the evidence that an agent is worth scoping.
Sometimes, and it is worth asking what they mean. A workflow that calls a model to read an email and pick a route is already doing the part most people mean by AI. What an agent adds is choosing its own sequence, including steps nobody anticipated. If your flows keep breaking because reality has more cases than you have branches, the claim is fair. If they break because an API changed a field, an agent breaks on that too.
Not wasted. The expensive part of an agent project is rarely the model. It is the connective work: authenticated access to the CRM, a way to write back to a ticket, an endpoint that issues the refund. An automation builds exactly those, and an agent later calls them as tools. What does change is the shape of the endpoints, because an agent needs honest names and clear errors to use them reliably. You also end up with real transcripts to scope against.
Build cost tracks scope on both, and we quote per project rather than from a price list. The running shape differs. An automation makes a predictable number of model calls per case, so usage rises with volume in a straight line. An agent loops until it judges the task done, so per-run cost has a tail and needs a hard cap. Both carry maintenance: new cases for the automation, prompt and permission tuning for the agent, plus re-scoring after a model upgrade.
The same two mechanisms, applied differently. In an automation you name the steps that stop for a signature, usually anything moving money or touching a customer record. In an agent you write an allowlist of the tools it may call, cap spend and time per run, and set a confidence threshold below which it escalates rather than guesses. The difference is that an automation's limits are visible in the flow, while an agent's have to be written down separately and reviewed.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.