AI Agent vs. Automation: How to Tell What You Actually Need
A workflow can be worth a lot without being agentic. The question is which one you are buying, and whether the added autonomy, complexity, and risk actually serve the job.
Every software vendor seems to have an AI agent now. Gartner put a number on how much of that is real.
Source: Gartner, June 2025.
Many of the rest are existing assistants, automations, and chatbots with a new label. Gartner calls it agent washing.
That is a marketing problem for the vendors. It becomes your problem the moment the label starts driving the architecture.
A workflow can be worth a great deal without being agentic. In the same research, Gartner’s Anushree Verma made the point directly: many use cases positioned as agentic today do not require agentic implementations. So the useful question in a vendor meeting is not whether the thing on screen deserves the word. It is which of the two you are buying, and whether the autonomy you are paying for actually serves the job.
The three questions that expose the label
I use three questions. They take about five minutes in a demo, and they do not require anyone to define “agentic”.
Three questions, in order
Stop at the first question that comes back “no”. Each one you clear moves the system further from a fixed path and closer to something you have to govern.
Can it invent new steps to complete its work? An agent decides the sequence at run time. Given a goal, it picks what to do first, looks at the result, and picks the next thing. Automation runs a sequence somebody drew in advance. Ask the vendor to describe a case where the software chose a path the team did not anticipate, and what it did.
Can it act across more than one system? Reading from four systems and writing a summary is retrieval. Acting means it changed a record in the CRM, moved a ticket, posted a document, sent something. Ask which systems it writes to, under whose credentials, and what happens when one of those writes fails halfway through.
What does it do when it hits bad data or a new edge case? This is the one that separates the categories fastest. Automation errors, stops, and routes to a person. An agent tries something else, and that is the behavior that has to be governed. Ask what the software did the last time it met a record it had never seen.
What the questions are really testing
All three are asking the same thing in different ways: how much of the decision-making moved from your team into the software. That number is what drives the permissions you have to grant, the review you have to staff, and the observability you have to build.
What autonomy actually costs
An agent changes what you have to trust software to do. When the sequence is fixed, you can inspect it. When the sequence is decided at run time, you inspect behavior instead, and that is a different discipline with different costs.
Six of them show up on every engagement.
What the same job costs on each side of the line
Five of those rows are a bill. The sixth runs the other way: automation is cheaper to run and more expensive to change. If your process shifts often, or the inputs are messy in ways nobody can enumerate, the agent’s flexibility is the thing you are actually buying.
The part that gets skipped
The failure mode of automation is that work stops. The failure mode of an agent is that work continues in the wrong direction, across systems, until somebody notices.
Which is why containment, not capability, is usually the harder half of the build.
Automation or an agent: what the work is telling you
Automation gets treated as the consolation prize. It should not be. When the work is genuinely repeatable, deterministic execution is the higher-quality answer: it does the same thing every time, it is cheap, it is easy to audit, and it fails loudly.
Payroll runs, invoice matching against a clean ledger, provisioning from an approved request, scheduled reporting off a warehouse.
That last one is the safest place to start. It gives the agent room to be useful and gives you a containment boundary while you build the evidence to widen it.
Putting a model in the middle of genuinely repeatable work adds variance to work that had none. Putting fixed rules around genuine judgment moves the work into an exception queue that a person now owns forever.
Run your workflow through these six
Most real workflows split: a deterministic spine with one or two genuinely judgment-heavy steps. That is a normal answer, and usually the cheapest one to run.
Operating question: How much does the sequence vary?
- Points to automation
- Somebody can draw the steps on a whiteboard and they hold for most cases.
- Points to an agent
- The path depends on what the work turns up, and the team decides as they go.
Operating question: Where does the context live?
- Points to automation
- One or two systems, structured fields, already integrated.
- Points to an agent
- Scattered across CRM, email, tickets, documents, and files people maintain by hand.
Operating question: What happens on an unseen case?
- Points to automation
- Stopping and escalating is fine. Volume is low enough that people absorb it.
- Points to an agent
- Exceptions are frequent enough that the escalation queue is the real cost.
Operating question: Who checks the output?
- Points to automation
- Nobody needs to. Correct is verifiable by rule.
- Points to an agent
- A named reviewer already exists, or you are prepared to staff one.
Operating question: What can it change?
- Points to automation
- Writes are narrow, reversible, and inside one system.
- Points to an agent
- Writes cross systems, so you need scoped permissions, approval gates, and undo.
Operating question: Can you explain a decision later?
- Points to automation
- The run log is the explanation.
- Points to an agent
- You need traces, sources, and evaluations, and someone has to own them.
The failure in each direction
Buying an agent for deterministic work is the expensive mistake. You pay a premium, you inherit a governance program, you staff a review queue, and you introduce variance into work that used to be exact. The pilot usually looks fine, because pilots run on clean cases. The cost shows up when the volume does.
Buying automation for judgment work is the quiet one. It works for the cases somebody thought of, and everything else lands in an exception queue that a person now owns forever. The tool reports high automation rates while the team does the same amount of work, in a worse order. Nobody escalates it, because nothing broke.
Both failures come from the same place, which is choosing the category before describing the work.
What to ask in the meeting
The three questions expose the label. These six get at whether you can actually run the thing, and the gap between the two answer columns is the tell.
A vendor with a real agent has ready answers to all six, because they had to build them. A vendor who rebranded a workflow tool will answer the first two well and get vague on the rest. That is more reliable than anything on the slide.
How we decide
On a Metacto engagement we map the workflow before naming the category. What triggers it, where the context comes from, what decisions get made, who reviews, what gets written back, and what the team does today when something unexpected arrives.
Most workflows come back mixed.
One workflow, split by what each step actually needs
A renewal-prep workflow, drawn the way we would scope it. Five of the six steps stay as plain integration. One step is doing the judgment, and it is the only one that needs an agent.
There is a deterministic spine that should stay deterministic, and one or two steps where a person is doing real judgment on scattered context. The agent goes on those steps. Everything else stays as plain integration, because it is cheaper to run and easier to trust.
That is the whole framework: put autonomy only where the work needs it, contain it where it touches systems, and measure the same thing before and after so you can tell whether the workflow changed.
The label is the vendor’s decision.
The architecture is yours.