Is an AI agent just automation with a language model bolted on?

No, and the difference is not the model — it is who decides the steps. In automation you write the sequence and the software executes it identically every time. In an agent, the sequence is chosen at runtime based on what actually arrived. You can bolt a language model onto a fixed workflow and it is still automation, which is often exactly right. It becomes an agent when the software is choosing what to do next rather than following your ordering.

How do I tell whether my problem needs automation or an agent?

Take twenty real examples of the work and try to write the rules down. If you can specify what should happen for all twenty in a way a colleague could follow without judgement, it is an automation problem and you should build a workflow — it will be cheaper, faster and more reliable. If you keep writing 'it depends' or 'well, if the customer means X', the variation is the actual work, and that is where an agent earns its cost.

Which is cheaper to run day to day?

Automation, usually by a wide margin. A workflow that moves a row between two systems costs a fraction of a rupee in compute and does not get more expensive when it runs more often in any meaningful way. An agent reasons over every input, which costs real money per interaction and scales with your volume. That cost is worth paying when the alternative is a person doing the judging, and hard to justify when the alternative is a rule you could have written down.

What does failure look like for each?

This is the asymmetry that should drive the decision. Automation fails loudly and identically — the API call errors, the row does not move, something is visibly broken and somebody gets an alert. An agent fails quietly and plausibly: it produces a confident, well-formed, wrong answer that looks exactly like a right one. Detecting the second kind is genuine engineering work, which is why agents need grounding, hard constraints and escalation paths that a workflow simply does not.

Can an agent and a workflow work together?

That is what almost everything worth shipping actually looks like. The agent handles the messy front — understanding what someone meant, in whatever words they used — and then calls deterministic tools to do the consequential parts. Checking stock, reserving an item, writing a record and issuing a payment link should all be ordinary code with ordinary error handling. Let the agent decide which tool to call, and never let it improvise the tool's job.

Do we need an agent if our data is already structured?

Probably not, and structured data is a strong signal you have an automation problem. Agents earn their keep when the input is unstructured — free text, a photographed document, a customer describing a problem in their own words. If the input is already fields in a system, the interesting question is what should happen to those fields, and that is usually a rule you can state. Reach for an agent at the point where something has to be interpreted, not moved.

Agents vs automation

Most things sold as an AI agent should be automation.

We build AI agents, so this page argues against a chunk of our own pipeline. Automation follows rules you wrote; an agent decides at runtime. Determinism is a feature, not a limitation — and the difference in how the two fail should usually settle the question.

The distinction is who decides

Both words have been stretched until they mean almost anything, so here is the version that is actually useful when you are choosing.

Automation

You wrote the sequence. When this happens, do that, then that. The software executes it identically every time, and if the input is unexpected it stops.

Agent

It chooses the sequence. It reads what actually arrived, decides which steps apply, and handles inputs nobody enumerated in advance.

Notice what is not in that distinction: the presence of a language model. You can put a model inside a fixed workflow — to summarise a field or classify a row — and the thing is still automation, because you still wrote the order of operations. It becomes an agent when the software is deciding what to do rather than following your ordering. That is the line, and it is the one that changes what the project costs and how it fails.

Automation is the default, and usually the right answer

There is commercial pressure in this industry to describe every problem as an agent problem, because agents are what people are budgeting for. It is worth resisting, because a deterministic workflow beats an agent on almost every axis when the rules are actually knowable.

It is cheaper per run, by orders of magnitude, and the gap widens with volume.
It is auditable. You can point at the rule that produced an outcome, which matters enormously if anyone regulated ever asks.
It is testable. Same input, same output, forever. You can write a test that stays true.
It fails visibly rather than confidently, so you find out from a monitor and not from a customer.

If your problem is moving data between systems, applying a pricing rule, generating a document from fields, or triggering something on a schedule, you want business process automation and you should not pay agent prices for it. We would rather scope that honestly than sell the more expensive thing.

Where a workflow actually breaks

Automation has a specific failure boundary, and it is not complexity — a workflow can be enormously complex and still work. It is unenumerable variation. The rules stop being writable when you cannot list the cases in advance.

You can tell you have crossed the boundary by how the specification conversation goes. If every third sentence is “well, it depends”, or the person who does the job today keeps saying “you just know”, the judgement is the work. A workflow at that point becomes a growing pile of exceptions that somebody maintains forever, and each new exception costs a developer.

Still automation

Move a paid order into the ERP
Apply dealer-specific pricing
Send a reminder three days before a due date
Reconcile a payment to an order reference

Now an agent

Work out what a customer meant in Hinglish
Read a photographed invoice with no fixed layout
Decide which of forty products answers a vague question
Judge whether a complaint needs a human now

The failure asymmetry nobody prices in

If you take one thing from this page, take this. The two technologies do not fail in comparable ways, and the difference should weigh heavily in the decision.

Automation fails loudly. The API returns an error, the field is missing, the job stops. Something is visibly broken, an alert fires, and the blast radius is bounded because nothing downstream ran.

An agent fails quietly and plausibly. It produces a fluent, confident, well-formatted answer that happens to be wrong, and it looks exactly like the hundreds of correct answers around it. Nobody gets an alert. The customer acts on it. You find out later, from them.

That is why a serious agent build spends most of its effort on things that have no equivalent in a workflow project: grounding every claim in live data so the answer has a source, hard structural limits on what may be promised, escalation as a designed outcome rather than a fallback, and enough observability to notice a quiet drift. If a vendor quotes you an agent as though it were a feature build, they have not priced any of that in — which is covered in more depth in how agent development actually works.

What actually ships is both

In practice the question is rarely either-or. Nearly every system worth building puts an agent at the messy front and deterministic code behind it.

The agent’s job is interpretation: work out what this person means, in whatever words they used, and decide which capability applies. Everything after that — checking stock, reserving the item, generating the payment link, writing the order, sending the confirmation — is ordinary automation with ordinary validation and ordinary error handling.

The design rule we work to: let the agent choose which tool to call, and never let it improvise the tool’s job. An agent that decides a refund is appropriate is a design decision you have to defend. An agent that decides to escalate a refund request to a person, who then triggers a deterministic refund process, is a system you can leave running.

The test, in one afternoon

You do not need a discovery workshop for this. Take twenty real examples of the work — twenty actual customer messages, twenty actual invoices, twenty actual tickets — and try to write down the rules.

All twenty specify cleanly? Automation. Build the workflow, spend a tenth of the money, and get something auditable.
Fifteen specify, five are odd? Automation for the fifteen, a human queue for the five. Revisit when the five become fifty.
You keep writing “it depends”? The variation is the work. That is an agent — and now the real question is what it is allowed to do when it is unsure.
You cannot get twenty real examples? Stop. Neither technology helps with a process nobody can show you running, and this is the most common reason these projects fail before they start.

If the honest answer comes out as automation, that is a good outcome and we will say so — our consulting is priced separately from build work precisely so that recommendation costs us nothing to make.

Frequently asked questions

Is an AI agent just automation with a language model bolted on?: No, and the difference is not the model — it is who decides the steps. In automation you write the sequence and the software executes it identically every time. In an agent, the sequence is chosen at runtime based on what actually arrived. You can bolt a language model onto a fixed workflow and it is still automation, which is often exactly right. It becomes an agent when the software is choosing what to do next rather than following your ordering.
How do I tell whether my problem needs automation or an agent?: Take twenty real examples of the work and try to write the rules down. If you can specify what should happen for all twenty in a way a colleague could follow without judgement, it is an automation problem and you should build a workflow — it will be cheaper, faster and more reliable. If you keep writing 'it depends' or 'well, if the customer means X', the variation is the actual work, and that is where an agent earns its cost.
Which is cheaper to run day to day?: Automation, usually by a wide margin. A workflow that moves a row between two systems costs a fraction of a rupee in compute and does not get more expensive when it runs more often in any meaningful way. An agent reasons over every input, which costs real money per interaction and scales with your volume. That cost is worth paying when the alternative is a person doing the judging, and hard to justify when the alternative is a rule you could have written down.
What does failure look like for each?: This is the asymmetry that should drive the decision. Automation fails loudly and identically — the API call errors, the row does not move, something is visibly broken and somebody gets an alert. An agent fails quietly and plausibly: it produces a confident, well-formed, wrong answer that looks exactly like a right one. Detecting the second kind is genuine engineering work, which is why agents need grounding, hard constraints and escalation paths that a workflow simply does not.
Can an agent and a workflow work together?: That is what almost everything worth shipping actually looks like. The agent handles the messy front — understanding what someone meant, in whatever words they used — and then calls deterministic tools to do the consequential parts. Checking stock, reserving an item, writing a record and issuing a payment link should all be ordinary code with ordinary error handling. Let the agent decide which tool to call, and never let it improvise the tool's job.
Do we need an agent if our data is already structured?: Probably not, and structured data is a strong signal you have an automation problem. Agents earn their keep when the input is unstructured — free text, a photographed document, a customer describing a problem in their own words. If the input is already fields in a system, the interesting question is what should happen to those fields, and that is usually a rule you can state. Reach for an agent at the point where something has to be interpreted, not moved.