AI Agents vs Chatbots vs Automation: Plain Definitions

Three words, roughly ten times the price between them.

An automation, a chatbot and an agent are three different systems that get sold under one vocabulary, and the vocabulary is blurred because the blur is profitable. The distinction worth holding onto in AI agents vs chatbots vs automation is not whether the thing talks. It is who decides the next step. In an automation you decided, once, at build time. In a chatbot the user decides and the system answers. In an agent the system decides, at run time, every time. That single axis predicts the price, the reliability and the way each one fails better than any feature list a vendor will show you. It also explains why a great many problems presented as agent problems are automation problems wearing a chat interface.

What is an AI agent, and what the other two are

Automation. A fixed sequence that runs on a trigger. An invoice arrives, fields are extracted, a record is created, a person is notified. AI can sit inside any step, doing the extraction or the classification, and the shape stays the same: the path was decided by whoever built it and does not change between runs. Most of the value companies get from AI is this, and it is the least discussed of the three because nobody sells a keynote about it.

Chatbot. An AI chatbot is a conversational interface over a bounded body of knowledge or a small set of actions. The user drives. The system understands the question, finds or composes an answer, and hands off when it should not answer. Its job is comprehension and retrieval, not decision-making, and the good ones are defined by what they refuse to do as much as by what they answer.

Agent. A system that is given a goal rather than a path, and chooses its own steps to reach it: reading a case, deciding which tool to call, calling it, reading the result, deciding again. Answering what is an AI agent honestly means saying it is a pattern rather than a tier, and that the word covers a real engineering pattern alongside a great deal of marketing. A useful test at any demo: ask whether the sequence of steps could differ between two runs with different inputs. If it cannot, you are looking at an automation with good presentation.

The three are not a maturity ladder, which is the implication most vendor decks carry. They are three tools with different jobs, and choosing the most autonomous one available is how you end up paying agent prices for a job an automation would have done more reliably. Our deeper treatment of the top of that range is in AI agents for business, and the craft of the middle one in building a brand-tailored chatbot.

What each costs, and why AI automation is the most reliable of the three

Published market ranges for a European SME build. An automation runs roughly €3,000 to €15,000 depending on how many systems it touches. A chatbot runs €3,000 to €8,000 for one or two workflows, more once it needs permissions over your own documents. An agent system runs €20,000 to €60,000, and its running cost climbs faster than either of the others because one task can make twenty model calls rather than one. The full breakdown by project type is in what a custom AI build costs.

Reliability moves in the opposite direction, and the arithmetic is worth doing on paper before anyone commissions anything. Suppose each individual step in a chain is 95 per cent reliable, which is a respectable number for a language model doing a judgement task. A five-step agent chain completes correctly about 77 per cent of the time, because the errors multiply rather than average out. Push it to eight steps and you are below 70 per cent. A fixed automation with one AI step inside it stays at 95 per cent, because the other four steps are ordinary code that either works or throws an error you can catch.

That is the whole reliability argument and it is not an argument against agents. It is an argument for counting the steps, capping them, and putting a human at the point where the compounding gets expensive. Vendors rarely lead with this because it makes the demo sound smaller, and the failure mode it produces is the one described in why AI projects fail: the system works impressively in the room and erodes trust over eight weeks of real use.

A decision path that takes four questions

Does the work start with a human question? If somebody has to ask something before anything happens, you need an AI chatbot, and the design problem is retrieval quality and the handoff rather than autonomy. The Biscoito.ai veterinary assistant is this shape: it resolves 60 to 70 per cent of owner enquiries in under five seconds, around the clock, and its hard rails on clinical questions are the part that took the work. Nothing about it needs to choose its own steps. The rest of our case studies divide along the same lines.

Does it start with an event, and is the path the same every time? A document arrives, a form is submitted, a status changes, and what should happen next is knowable in advance. Build an AI automation. This covers more business processes than most people expect once they write the path down, and writing the path down is the exercise that settles it.

Is the path genuinely different every time? Not merely branching, which an automation handles, but a case where the number and order of steps depends on what was found along the way. That is the agent case, and it is real: research across sources that are not known in advance, triage where the next lookup depends on the last answer, multi-system investigation.

What does one wrong answer cost? Ask this last and let it override the other three. If a mistake is a mild annoyance, the compounding arithmetic above is affordable. If a mistake sends the wrong invoice to a client or misses a regulatory deadline, cap the autonomy and put a person on the decision, whatever the demo suggested.

Where agents earn their place, and what they add to your risk

Agents genuinely win where the search space cannot be enumerated in advance. Reconciling a discrepancy across four systems when nobody knows which one is wrong. Answering a question that requires reading whichever documents turn out to be relevant. Triaging an incident where the second thing to check depends on what the first check returned. In those cases a fixed path would have to encode every possibility and would be unmaintainable within a year.

What they add is three failure modes that automations do not have. The first is the compounding above. The second is unbounded cost, because a system that decides its own steps can decide to take forty of them, and a spending cap is not optional. The third is that failures become hard to explain: when a fixed automation breaks, the log tells you which step failed, and when an agent reaches a wrong conclusion the honest answer is often that it took a reasonable path that happened not to work. That is uncomfortable in a regulated setting and it is the reason agents belong behind a human decision point in most business use.

The design that ships is usually a hybrid nobody puts in a headline: an automation for the known path, an agent confined to the one genuinely open step inside it, a step limit, a spending cap, and a human review queue for anything the system is not confident about. Less impressive in a demo. Considerably more likely to still be running next year.

Two traps worth naming

The chat interface on an automation problem. A team wants a report generated every Monday and specifies a chatbot to request it. Now a person has to remember to ask, phrase it correctly, and check what came back. The chat interface added a step and removed a guarantee. Ask whether anyone needs to have a conversation at all, or whether the thing should simply happen.

Buying autonomy as a hedge against unfinished thinking. When nobody can describe the process, an agent looks like the answer because it promises to work the process out at run time. It will not. It will produce plausible steps against an unstated goal, and the disagreement about what the process should be will surface later, with a system to blame for it. If two departments describe the workflow differently, no amount of autonomy resolves that, and the cheap fix is two weeks with a facilitator before anyone builds.