Automation means steps you specified: when an invoice arrives, pull these fields, check them against the purchase order, post to the ledger, notify the buyer if the totals differ. It runs the same way every time. When it breaks, it breaks loudly and in a place you can point at.
An agent means a language model deciding what to do next within limits you set. It reads something unstructured — an email, a call transcript, a contract — decides which of your tools to use, and produces an outcome. It handles input nobody could enumerate in advance, and it does not run the same way every time.
Ask the person who does the work today to write down the rule they follow. Not the summary — the actual rule, including the exceptions. What happens next tells you almost everything.
They can write it down: use automation. It will be cheaper to build, cheaper to run, and you will be able to prove what it did.
They cannot, because it depends on what the message says: that is the model's job — reading language and turning it into something structured your automation can act on.
They cannot, because nobody has decided: neither approach helps. The decision has to be made by a person before any system can execute it, and pretending otherwise is how pilots die.
In practice the argument is misframed. A support system is not an agent; it is a workflow with a classification step where a model reads the ticket, and a retrieval step where a model drafts an answer from your documentation. Everything around those two steps — routing, permissions, escalation, logging, the CRM write-back — is ordinary automation, because it should be.
That shape is deliberate. The deterministic frame is what makes the system auditable and cheap; the model is confined to the parts that genuinely need judgement about language. When a project goes wrong, it is very often because a model was handed a job a rule could have done.
Cost per run stops being negligible. Deterministic steps cost almost nothing. Model calls have a real unit price, so volume that was irrelevant to your infrastructure bill becomes a line item worth forecasting.
The same input can produce different output. That is the point, and it is also the problem. It means you need evaluation — a set of real cases with known good answers — rather than a test that passes once.
Failure gets quieter. Automation fails with an error. A model fails with a fluent, wrong answer, which is why citations, confidence thresholds and a human path for low-confidence cases are not optional extras.
Latency goes up. Seconds instead of milliseconds. Irrelevant in a support reply, occasionally decisive in a checkout flow or an API someone else waits on.
Take one process. Split it into steps and mark each step as rule or judgement. If every step is a rule, you do not need a model and any vendor telling you otherwise is selling. If one or two steps are judgement about language, that is where a model goes — and the rest stays deterministic.
If most steps are judgement and they are not about language but about your business — pricing, credit, hiring, who to fire from a supplier list — that is not an automation project yet. It is a decision-making project, and it needs a person to set the policy first.
How to rank candidates by volume, minutes and how clearly the rules can be stated.
The shape described here: a deterministic workflow with a model doing the reading.
The wider service: processes taken to production, with the model confined to where it earns its place.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy