Agent or chatbot. The difference isn't how clever it is, but what it's allowed to do.
It's the most expensive confusion around right now. Two things that look like close relatives are sold under the same name, have prices an order of magnitude apart, and fail for opposite reasons. The line between them is sharp, and one question is enough to spot it.
A chatbot produces text. An agent produces a change. At the end of a conversation with a chatbot there's an answer. At the end of an agent's work there's a line written in business software, a drafted email, a generated document.
Four capabilities make an agent: retrieving from authorised sources, deciding within rules written in advance, carrying out an action, and stopping when evidence is missing.
The fourth is the one nobody sells, and it's the most important. A system that can't abstain isn't autonomous; it's just quick at getting things wrong.
You almost always need less than you're being offered. If the step is always the same, a script costs less and breaks less often.
The definitions, one by one, are in the AI and automation glossary. What matters here is the choice: which of the two to ask for, and how to spot when you're being sold one dressed up as the other.
The question that separates the two
After the system has answered, does something need to happen?
If the answer is no, you need a chatbot, and a good chatbot costs little. A customer asks for opening hours, return terms, whether a product contains an allergen. The system draws on documents that already exist and answers. Job done. All the value lies in the quality of the sources and the clarity of the answer.
If the answer is yes, you're in different territory. A customer writes to move a booking, and something has to change in the calendar. An invoice arrives from a supplier, and something has to go into a spreadsheet. A foreign buyer asks for a spec sheet, and someone has to produce it in the right language. Here the text is the means; the result is somewhere else.
The four capabilities that make an agent
You recognise an agentic system by four things it can do. If one is missing, what you have in front of you is a chatbot with buttons.
| Capacity | What it means | How it's checked |
|---|---|---|
| 01 · Retrievefrom authorised sources | It searches within a closed list of documents, folders and systems it has been given, and says where each answer comes from. |
Ask it a hard question and see whether it cites the file. If it doesn't cite, it didn't search: it remembered. |
| 02 · Decidewithin written limits | It chooses between options someone listed before it was built, not between every option imaginable. |
Ask for the list of permitted actions. It has to exist on paper, before the code. |
| 03 · Actand leave a record | It carries out the action in a real system and records what it did, when, on which record, with what outcome. |
Ask to see the execution log. If the log doesn't exist, the action can't be verified. |
| 04 · Stopwhen evidence is missing | When the source isn't there, the case falls outside its scope or a criterion fails, it abstains and alerts a person. |
Ask it a question it can't answer. If it answers anyway, that system will lie to one of your customers too. |
The fourth is what separates a serious supplier from a salesperson. A system that stops looks less powerful in a demo and costs much less in production.
Where a chatbot goes wrong
A chatbot almost always fails for one reason: it was given sources nobody kept up to date. It answers confidently using last year's price list, or a procedure the business changed in March. The model isn't wrong; the upkeep of the sources is.
The second way is an undeclared scope. An assistant meant to answer questions about products and opening hours ends up giving advice on a dispute, because nobody told it where to stop.
Where an agent goes wrong
An agent fails in costlier ways, all of them predictable.
It does something it wasn't supposed to. The permitted actions weren't a closed list, so it found one more. You prevent this by writing the list beforehand, not by correcting afterwards.
It does the right thing at the wrong moment. It sends a payment reminder to a customer who paid yesterday, because it was reading old data. You prevent this by deciding which source is right when two contradict each other.
It carries on when it should have stopped. The case was outside its scope and nobody had written a condition for abstaining. That's the mistake that reaches the customer.
The three things that make an agent safe are written before the first line of code, or they never get written.
When you need neither
I'll say it, because nobody selling AI will. If a step has stable input, stable transformation and stable output, the right solution is a deterministic script: it costs less, breaks less often, and when it does break you can see why straight away.
A report that takes the same fields every Monday and puts them in the same spreadsheet doesn't need to interpret anything. Putting a language model in the middle adds a cost per run, some uncertainty and one more point of failure, in exchange for nothing. Autonomy comes at a price, so it belongs only where the process genuinely has to interpret a changing context.
The four questions to ask anyone pitching it to you
They work with any supplier, and you don't need to know how to code.
Which sources does it read from, and who authorised them? A good answer is a list. A vague answer means it'll also read things it shouldn't.
Which actions can it take, one by one? If the list doesn't exist in writing, neither does the limit.
What happens when it can't find the answer, or a service doesn't respond? The right answer describes specific behaviour: it stops, it alerts someone, and the person receiving the alert has a name.
Where is what it did recorded, and who can read it? Without a log there's no oversight, and without oversight there's no compliance. Italian law on AI asks for exactly this: traceability and a person able to correct things.
In one line
A chatbot saves you answers. An agent saves you steps. The first is judged on how up to date its sources are, the second on how tight its limits are. And almost every business that asks for the second finds, at the first question, that the problem is solved by the first, or by neither.
How we design a system like this, and what we measure before building it, is on the method page. The pieces already built, one by one, are in services.
Questions and answers
What's the difference between a chatbot and an AI agent?
A chatbot produces an answer and stops there: the result is text. An agent retrieves information from sources it has been authorised to use, decides within rules written in advance, carries out an action in a real system and leaves a record of what it did. The result of an agent's work is a change of state somewhere, not a sentence.
When is a chatbot enough?
When the job is answering questions about information that's already written down, and nobody has to do anything after the answer. Opening hours, terms, procedures, product sheets. If after the answer something needs to happen in business software, a calendar or an inbox, a chatbot isn't enough, and bolting extra pieces onto it makes it fragile.
Can an AI agent get things wrong and do damage?
Yes, which is why the limits are written before the code. A well-designed agent has a closed list of permitted actions, a human approval point on anything that touches a customer, money or an outgoing message, and the ability to stop when a source is missing instead of making something up. An agent without those three things is a risk, not a tool.
What should I ask someone pitching me an AI agent?
Four questions. Which sources does it read from, and who authorised them? Which actions can it take, listed one by one? What happens when it can't find the answer or a source doesn't respond? Where is what it did recorded, and who can read it? If any of the four answers is vague, the system hasn't been designed; it's been assembled.
Do you need an agent to automate a repetitive process?
Hardly ever. If the input, transformation and output are always the same, a deterministic script costs less, breaks less often and is easier to understand. Autonomy is only needed where the process has to interpret a changing context. Adding an agent where a rule would do introduces unpredictability without adding value.
Which of the two you need depends on the work, not the technology.
The difference between them matters when you look at a specific job: how many enquiries come in each week, how much time answers written by hand cost, what has to stay in a person's hands. The Diagnostico measures five dimensions in five minutes. No spam: the report is yours, and we only write to you if you ask us to.