The two words get used interchangeably in the market, yet the difference between them decides the cost, the risk and the oversight model of the whole project. Vendors happily call an ordinary chatbot an “agent” because it reads better in a proposal; the reverse happens too, when a company asks for a “chatbot” while describing a system meant to do work in the CRM on its own. It is worth getting the terms straight — not for academic tidiness, but because this difference determines what you are signing and what can go wrong.
A chatbot: the conversation is the whole job
A chatbot holds a conversation, and that is where its task ends. It answers questions from a script, a knowledge base or documents it searches — modern versions do this genuinely well. But the output of its work is always the text of an answer. A chatbot does not create an order, move an appointment or issue a correction — at most it can tell you how to do it, or hand the case to a person.
One clarification before going further: this split is about what the system can do, not about what it looks like. A tool that talks in chat but can also create a ticket, move a booking or update the CRM is, in this split, an agent with a chat interface — and it carries every consequence described below, whatever the offer calls it. A “chatbot” in the strict sense is a system whose only output is an answer.
That boundary has an important consequence: a chatbot’s mistake is wrong information. It can be costly reputationally — especially since a chatbot usually talks directly to customers — but it changes the state of no system. There is no action to roll back; what needs fixing is the knowledge base the answer came from. That does not mean there are never consequences — an answer that discloses personal data, or misleads a customer on something that matters, can require a correction and sometimes a breach notification.
An AI agent: a goal, tools and permissions
An AI agent is given a goal, not a question. “Book a service visit for this customer next week”, “assemble the documents for this complaint”, “prepare an offer from this enquiry”. To deliver the goal, the agent breaks it into steps and executes them in your systems: checking the calendar, creating the CRM record, preparing the document, sending a message for approval. For that it needs tools — access to systems — and this is the heart of the difference.
An agent has permissions, so its mistake is not wrong information but a wrong action: a record in the wrong file, a visit booked with the wrong person, a document sent too early. That is why an agent project starts with questions a chatbot project never poses: what exactly the agent may do, what it may never do, where the log of its actions lives, and which decisions always wait for a person. How those boundaries are set — and what happens when the agent gets something wrong — is described on our AI agent implementation page: these are questions about permissions and oversight, not about the model.
A practical test: what happens after a mistake
If an offer leaves you unsure which kind of system you are looking at, ask one question: what has to be done when the system gets it wrong? If the answer is “correct the reply and the knowledge base” — it is a chatbot, whatever the vendor calls it. If the answer requires undoing an action in a system — correcting a record, cancelling a booking, recalling a dispatch — it is an agent, with everything that follows: permissions, an action log and a pilot with approval.
The test works in the other direction too, when you write requirements. If the description of your “chatbot” contains verbs like “will create”, “will change”, “will issue”, “will send” — you are designing an agent, and it is worth naming that before the vendor’s price list does.
When a chatbot is enough
A chatbot is the right tool when the work genuinely consists of providing information: answers to recurring customer questions, searching documentation and procedures, a first line of support that hands harder cases to people. The condition offers rarely mention: a chatbot is exactly as good as the knowledge base it works from. If the answers live scattered across mailboxes and people’s heads, the “chatbot” project is in reality a “putting the knowledge in order” project — and an honest offer says so at the start, not after the go-live.
When you need an agent
An agent makes sense when the value lies in doing the work rather than answering, and when there are too many paths to write down as rules for classic automation. Handling an enquiry that needs three systems checked, assembling documents from attachments and registers, preparing records and replies from what was agreed — these are agent tasks. Where the line between an agent and simpler automation runs is described on our AI automation page: if the process can be written down as a fixed list of steps, an agent is over-engineering and a more expensive way to get the same result.
The third answer: back office first, conversation later
In practice the right answer is most often neither “a chatbot” nor “an agent right away”, but “back-office automation first”. Before anything starts talking to customers, it is far safer to automate the work around the conversation: qualifying and registering enquiries, preparing replies for a person to approve, tracking case completeness. The results show in the same places — faster response times, less retyping — and a mistake stops at a person before it reaches the outside. We develop this argument on the customer service automation page, which describes what is worth automating before a chatbot.
That order has one more advantage: it builds exactly the foundations a chatbot and an agent need. An orderly knowledge base, described processes, working integrations — this is not work done “instead of” a chatbot or an agent, but their cheapest possible beginning.
How to settle it for your company
Three questions organise the decision. First: does the value lie in information or in work getting done? Information points to a chatbot, execution to an agent. Second: can the process be written down as a fixed list of steps? If so, simpler automation is enough and an agent is unnecessary. Third: do the orderly knowledge and described processes the system would work from already exist? If not, the first project is the back office — regardless of what was meant to sit at the front.
And if the outcome of that test is not obvious, that is a good sign it is time to talk about a specific process rather than a technology. Describe yours to us — we will tell you which variant we see as the first step, including when the answer is “none of the above, for now”.