Chatbot or AI agent?
One answers questions. The other does things — and doing things is where the risk, the integration work and most of the cost live.
A chatbot answers from what it knows. An agent takes actions in your systems — booking, refunding, updating records — and that difference is the whole project. Most businesses asking for an agent need a good chatbot on accurate content first, because an agent built on bad answers takes wrong actions faster.
Updated August 2026
Short answer
Start with answering. Move to acting only where a specific action is worth automating and can be undone.
Answering versus acting
The line is simple: can it change anything? A system that reads your documentation and answers questions is a chatbot, however capable it sounds. A system that issues the refund is an agent, however simple it looks.
That line is also where the engineering is. Answering needs good retrieval over accurate content. Acting needs authentication, permissions, integration with the systems that hold the record, an audit trail, and an answer to what happens when it acts wrongly.
The last point is the one skipped most often. A chatbot that gets something wrong gives a bad answer and a person notices. An agent that gets something wrong has already changed the record. Every action needs to be reversible, logged, and bounded — or gated behind a human for anything consequential.
There is a practical order that works: build the answering layer, watch real conversations for a few weeks, and see which actions people are actually asking for. That list is almost never the one anyone predicted, and it turns an open-ended agent project into two or three well-defined ones.
The unglamorous prerequisite for both is content. Most disappointing deployments are not model failures — the documentation was contradictory, out of date, or never written down, and the system faithfully reproduced that.
Side by side.
| Chatbot | AI agent | |
|---|---|---|
| What it does | Answers from your content | Takes actions in your systems |
| Main engineering | Retrieval and content quality | Integration, permissions, audit |
| Time to useful | Weeks | Months, and staged |
| When it is wrong | A bad answer, correctable | A changed record, needs reversing |
| Prerequisite | Accurate documentation | Everything the chatbot needed, plus system access |
| Measured by | Resolution rate, reviewed conversations | Actions completed, actions reversed |
| Where to start | Here, almost always | After you know which actions matter |
Build a chatbot when
- Most incoming questions are informational
- You want something useful in weeks, not quarters
- Your documentation is accurate, or you are willing to make it so
- Nothing needs to change in a system to resolve the request
Build an agent when
- A specific, repetitive action consumes real staff time
- That action can be scoped narrowly, logged and reversed
- The systems it touches have APIs you can authenticate against
- You already know from real conversations which actions people want
Where these projects fail
Building on content nobody has checked
The most common cause of a bad deployment by a wide margin. If two documents disagree, the system will confidently pick one. Fix the content first; it usually improves your human support at the same time.
Giving an agent unbounded permissions
Scope every action to the narrowest thing that works, make it reversible, and log it. An agent with broad write access to production systems is a risk you have taken on rather than a feature you have shipped.
No route to a person
Some conversations must reach a human quickly, and the ones that must are the ones that matter most. A system with no exit turns a solvable problem into a lost customer.
No measurement
Without a resolution rate and a sample of real conversations reviewed weekly, nobody knows whether it is working. Deflection alone is not the measure — a conversation that ends because someone gave up counts as deflected.
Questions that resolve it
Answer the second one honestly before scoping anything.
Does it need to change anything in your systems?
No — a chatbot, and the project is retrieval and content. Yes — an agent, and the project is integration, permissions and audit. This is the whole distinction.
Is your documentation accurate and consistent today?
If a customer would get conflicting answers from two pages, the system will too. This is a content project before it is an AI project, and skipping it is the standard way these fail.
What are the top five things people actually ask?
Pull them from real tickets, not from assumption. If the top five are informational, a chatbot resolves most of your volume without an agent's risk.
If it acts wrongly, what happens?
For each action: can it be reversed, is it logged, would anyone notice? Anything failing those three needs a human in the loop, and that is a design decision, not a limitation.
What people ask next.
That is the order we recommend. The answering layer is the foundation, and a few weeks of real conversations tell you which actions are worth automating — usually not the ones anyone predicted.
Ground every answer in retrieved content, and have it say it does not know rather than guess. That behaviour is a design decision. Then measure it — an evaluation set of real questions with known-good answers, scored on every change.
It depends on the model. Hosted APIs mean data leaves your infrastructure; open-weight models on your own servers mean it does not, at the cost of running them. Where data genuinely cannot leave, that constraint decides the architecture and should be raised first.
Chatbots are usually modest — retrieval infrastructure plus tokens per conversation. Agents cost more per interaction and more to maintain, because every system they touch is one that can change underneath them.
— other comparisons
Tell us the constraint.
Budget, timeline, or who maintains it after launch — whichever is hardest to change. We will tell you which option fits, including when it is not us.