AI agent vs chatbot: which does your business need?
These two words get used interchangeably in sales material and they describe genuinely different systems with different costs, different risks and different reasons to fail. The distinction is simple once stated: a chatbot answers questions, an agent takes actions. We build both, and we talk clients out of one of them regularly.
Build a chatbot if the job is answering questions from information you already have — it is cheaper, faster to ship and its worst failure is a wrong answer. Build an agent if the value is in the system doing something on your behalf: booking, updating records, moving work between tools. An agent needs permissions, an audit trail and a human checkpoint on anything irreversible, and that governance is most of the real cost.
When each one is the right call
Build a chatbot
- People keep asking the same questions your documentation already answers
- The win is deflecting support volume or qualifying enquiries
- You want something live in weeks, not a quarter
- A wrong answer is embarrassing but not expensive
- You need it to hand over to a human cleanly when it is out of depth
Build an agent
- The value is in work being done, not in a question being answered
- A task spans several systems and someone currently copies data between them
- The steps are well defined but the inputs are messy and human
- You can define exactly what it is allowed to touch, and what it is not
- You are prepared to review a log of what it did
The differences that actually matter
| Chatbot | Agent | |
|---|---|---|
| What it does | Answers from a body of knowledge you give it | Decides on a sequence of steps and carries them out |
| Reaches into your systems | Reads. Occasionally creates a ticket or a lead | Reads and writes — that is the point of it |
| Worst realistic failure | A confidently wrong answer | A confidently wrong action, already taken |
| What governs it | The content it is allowed to draw on | Explicit permissions, tool boundaries and approval steps |
| Time to something usable | Weeks | Longer — most of it spent on the guardrails, not the model |
| Running cost | Predictable, roughly per conversation | Variable — a task can take many model calls and several retries |
| What it needs from you | Good, current documentation | Well-defined processes and API access to the tools involved |
| How you know it works | Answer quality, deflection rate, handover rate | Task completion, intervention rate, and an audit log you actually read |
| Where it usually goes wrong | Stale or contradictory source content | Scope: it was given more autonomy than the process deserved |
| Human in the loop | On escalation | On anything irreversible, by design |
Neither column is a verdict. Every row is a trade-off, and which side of it you want depends on the project — which is what the sections below work through.
Autonomy is a liability decision, not a technical one
The interesting question about an agent is never whether it can perform a task. Given tools and a clear objective, it usually can. The question is what happens the time it is wrong, and who is accountable for that.
An agent that issues a refund, sends a message to a customer, updates a CRM record or cancels a booking has done something real. There is no undo on a sent email and often no clean undo on a financial action. So the design work that matters is not prompting — it is deciding which actions the system may take alone, which require a human to approve, and which it may never take under any circumstances.
In practice we draw that line by consequence and reversibility. Read anything. Draft anything. Take reversible internal actions freely. Require approval for anything a customer sees or anything involving money. Never grant a capability that has no business reason to exist, because an unused permission is only a dormant incident.
The corollary is that a good agent build is mostly ordinary engineering: authentication, scoped tokens, idempotency, retries, logging and a review surface. The model is the least interesting component, and the projects that fail are almost always the ones that treated it as the only component.
Answering and acting are different products
A chatbot is a retrieval problem with a conversation on top. Its job is to find the right passage in material you already have and put it in plain language, and its quality is almost entirely determined by the quality and currency of that material. If your documentation is contradictory, the bot will be confidently contradictory, and no amount of prompt engineering will fix a source-of-truth problem.
An agent is a control problem. It decides which tool to call with what arguments, observes what happened, and decides again. That loop is what makes it useful and it is also what makes it hazardous, because a small misreading early can send the rest of the sequence somewhere you did not intend.
The practical consequence is that they fail differently and therefore need different work. A chatbot gets better with better content and better retrieval. An agent gets better with tighter tool definitions, narrower permissions, better failure handling and a human checkpoint in the right place. Teams who ship an agent expecting the chatbot workflow are usually surprised by how little of the effort is spent on the model.
Start with the boring one, almost always
Our default recommendation is to build the chatbot first even when the client came in asking for an agent, and it is not a hedge. It is because the chatbot answers the question the agent project would otherwise discover the expensive way.
Shipping a chatbot forces you to consolidate your knowledge into something coherent and current, and that asset is a prerequisite for the agent anyway. It also gives you real transcripts, and transcripts are the only honest source of truth about what people actually want your system to do. The list of tasks you thought you needed to automate before launch and the list the transcripts produce after a month are rarely the same list.
It is also the cheaper way to find out whether an AI surface fits your business at all. If people do not use the chatbot, an agent was never going to be the answer, and you have found that out for a fraction of the cost.
The exception is when the value is unambiguously in the doing rather than the answering — an internal process where someone spends hours a week moving data between two systems that will not talk to each other. There the task is already specified, the failure mode is contained inside your own operations, and going straight to an agent is the right call.
What it costs to keep running
Both of these are systems rather than projects, and the ongoing cost is more predictable than teams expect provided it is planned for rather than discovered.
A chatbot costs roughly per conversation, which makes it easy to model: estimate conversations per month and multiply. The recurring work is content maintenance. When your product, pricing or policies change, the source material has to change with them, or the bot starts confidently telling people something that was true last quarter. Whoever owns the documentation owns the chatbot, and if nobody owns the documentation the project has a problem that predates the AI.
An agent is more variable, because one task may take many model calls and some will be retried. That is manageable with caps, timeouts and cheaper models on the mechanical steps, but it needs measuring per task rather than per conversation, and it needs a ceiling so a loop cannot run up a bill.
The recurring cost people forget on an agent is attention. Someone has to read the log periodically and ask whether the actions still look right. An agent nobody reviews is not automation, it is an unmonitored process with write access, and that is a different risk category from the one that was signed off.
Answered before you ask
What is the actual difference between an AI agent and a chatbot?
A chatbot answers; an agent acts. A chatbot takes a question, finds the relevant information in material you have given it, and replies in plain language — its output is words. An agent is given an objective and a set of tools, and it decides which tools to use in what order to achieve it — its output is changes in your systems, such as a record updated, a booking made or a message sent. Everything else follows from that. Because an agent changes things, it needs permissions, boundaries, logging and usually a human approval step on anything irreversible, which is why an agent build spends most of its effort on control rather than on conversation quality. Many real deployments are both: a conversational surface for asking, with a small number of carefully scoped actions behind it.
Can an AI agent do something I did not authorise?
Only if the system was built to allow it, which is why the permission design is the project rather than an afterthought. An agent can only use the tools it is given, and each tool should be a narrow, specific capability with its own scope — not broad access to an account. Built properly, the agent holds credentials that can do exactly the small set of things it is meant to do and nothing else, every action is logged with its inputs, anything irreversible or customer-facing goes through a human approval step, and there are hard limits on how many actions it can take in a run. The risk is real and it is entirely a design decision. Ask any vendor which specific permissions their agent will hold and what it cannot do; if that question does not have a precise answer, the system is not ready to be given write access.
Do I need my own data or documentation before starting?
For a chatbot, yes, and it is the single biggest determinant of whether the result is any good. You do not need it to be tidy — we routinely work from a mix of help pages, PDFs, past support threads and things that only exist in someone's head — but it does need to exist and it needs to be current, because a bot trained on last year's pricing will quote last year's pricing with complete confidence. Part of the build is usually consolidating that material and finding the places where two sources disagree, which is often independently valuable. For an agent the equivalent requirement is different: instead of documentation you need clearly defined processes and API access to the systems involved. If a task is only ever performed by one person improvising, it needs to be written down before it can be automated.
Which model should it run on, and am I locked into that choice?
The right model depends on the job and it should not be a permanent decision. Retrieval-based answering usually runs well on a small, fast, cheap model, because most of the quality comes from the retrieval rather than the reasoning. Agent loops that plan multi-step work benefit from a stronger model on the reasoning steps, with cheaper models handling the mechanical ones. We build behind a thin abstraction so the model is a configuration value rather than something woven through the codebase, which means a change is a config change and a round of evaluation rather than a rewrite. That matters more than the initial choice, because the sensible answer moves every few months and you should be able to follow it without a project.