The difference between an AI agent and a chatbot
The two words are used interchangeably in sales conversations, and the distinction between them is the single largest driver of what a project costs and what can go wrong with it.
What actually separates them?
A chatbot answers; an agent acts. A chatbot returns text that a person reads and then does something with. An agent changes the state of a system — it creates the record, sends the message, issues the refund. The difference is consequence, not capability, and it should drive how the project is scoped, permissioned and governed.
Why the distinction is commercial, not technical
When a chatbot gets something wrong, a person reads a bad answer and wastes a few minutes. Annoying, recoverable, and usually caught immediately by the reader.
When an agent gets something wrong, it has already done something. A record was created, an email left the building, a credit was applied. Now you need to detect it, undo it, and work out what else was affected. That asymmetry is why the same underlying technology produces two projects of very different size.
Where the extra cost goes
Clients are often surprised that adding actions costs substantially more when the model is identical. The extra work is almost entirely governance: defining each action separately, scoping credentials to the minimum for each, deciding which need human approval, logging everything, and designing what happens when a multi-step sequence fails halfway.
| Dimension | Answering system | Acting system |
|---|---|---|
| What it changes | Nothing — returns text | Records, messages, transactions |
| Worst realistic failure | A wrong answer someone reads | A wrong action someone must find and undo |
| Permissions needed | Read-only | Write access, scoped per action |
| Approval design | Not applicable | Required on anything consequential |
| Audit requirements | Useful | Essential — every action logged and attributable |
| Testing surface | Are the answers right? | Are the answers right AND can wrong ones change anything? |
| Relative build cost | Baseline | Meaningfully higher, driven by governance not by the model |
Which should you build first?
The answering system, in almost every case, even when an acting one is the eventual goal. It builds the retrieval foundation an agent needs anyway, and it exposes something you need to know early: whether your documentation is actually good enough. Most organisations discover their knowledge base is patchier than assumed, and it is far better to learn that from a read-only assistant than from one with write access.
It also lets people calibrate. Teams that have used an assistant for a few months have a realistic sense of where it is strong and where it is not, and that judgement is what makes the subsequent conversation about which actions to permit a sensible one rather than a leap of faith.
The platform you build on does not change that sequence, only where the permission boundary is configured. On Microsoft 365 both stages live in the same tool, which is why a Microsoft Copilot Studio consultant will ask what the agent may write to before asking what it should say — the answering version and the acting version are the same agent with a different set of approved actions attached.
How do you tell what a vendor is proposing?
Ask a single question: what can it write to, and who approved that permission? A vendor proposing an answering system will say it writes to nothing. A vendor proposing an agent should be able to enumerate every action, its permission scope, and the approval step behind the consequential ones.
Vagueness in response to that question is the thing to worry about — more than the price, more than which model they name. If nobody has thought about the permission boundary before the proposal, nobody has thought about the failure modes either. The NIST AI Risk Management Framework gives you shared vocabulary for asking these questions in a way any competent vendor should recognise.
Common questions about the distinction
Is an agent just a chatbot with extra features?
No, and treating it that way is how projects go wrong. A chatbot returns text a person then acts on, so a bad answer wastes time. An agent changes the state of your systems, so a bad decision creates something you have to undo. The difference is in consequence, not in features, and it should change how the project is scoped and governed.
Which should we build first?
Almost always the answering system, even when the goal is an acting one. It builds the retrieval foundation an agent needs anyway, exposes how good your documents really are, and lets people calibrate their trust before anything can change a record. Going straight to actions means discovering your knowledge base is inadequate after the system already has write access.
How do we tell which one a vendor is proposing?
Ask one question: what can it write to, and who approved that permission? A vendor proposing an answering system will say it writes to nothing. A vendor proposing an agent should be able to list every action, its scope, and the approval step behind the consequential ones. Vagueness here is the warning sign, not the price.
Does an agent cost much more to build?
Meaningfully more, though rarely because of the model. The extra cost is in permission design, approval flows, action logging, rollback behaviour, and the far larger test surface — you now have to prove not only that answers are right but that wrong ones cannot silently change anything. Budget for the governance, not for the intelligence.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.