Chatbot vs AI agent

The short answer

A chatbot answers. An agent acts. That single difference determines the architecture, the cost, the risk profile and whether the thing ever moves a business number.

Everything else people argue about, how conversational it feels, which model is behind it, whether it has memory, is secondary. Start with whether it can change state in your systems. Definitions are in what an AI agent is and agentic AI.

What a chatbot actually does

It receives a question and returns text. At its best, grounded in your documentation and genuinely useful. At its worst, a search box with a personality.

This is a real product and sometimes exactly the right one. If most of your inbound volume is people who cannot find information you already publish, a well grounded chatbot solves that at a fraction of the cost and risk of anything else.

What an agent actually does

It takes an outcome and works toward it: reads context, calls systems, decides the next step, and changes something. Cancel the order, reschedule the appointment, issue the refund, update the record, complete the setup.

That is a categorically different object. It has permissions, it produces side effects, and it can be wrong in ways that cost money rather than just credibility.

The bolt-on trap

The common failure is a chatbot placed in the corner of a page as an afterthought, disconnected from the flow where the customer actually gets stuck. It answers questions nobody was asking at a moment nobody needed it.

AI moves a number when it sits at the decision point, not beside it. A widget on top of an unchanged funnel is a feature you can announce and not a result you can measure, which is the pattern behind checkout conversion and support deflection.

What changes technically when it can act

Permissions scoped to the requesting user. Confirmation on anything irreversible. Idempotency, so a retry does not refund twice. Full logging of every action for reconstruction. Deterministic validation of arguments before a call is made.

None of that is required for a system that only produces text, and all of it is mandatory for one that acts. It is most of the engineering, and it is why guardrails and observability stop being optional.

Cost and risk are different objects

A chatbot is cheap to build, cheap to run and its worst case is an embarrassing answer. An agent costs more to build, more to operate and its worst case is an unauthorised action on a real record.

The risk is also asymmetric with capability: severity is set by what the system is permitted to do, which is exactly why prompt injection matters far more once tools are attached. Compare the numbers in what an AI agent costs.

How to tell what a vendor is selling

Ask which systems it writes to, what happens when an action fails halfway, how permissions are scoped per user, and to see the audit log for a single action end to end.

A vendor selling a chatbot as an agent will answer with capability language and demo a conversation. One that has built agents will answer with mechanics. That question belongs on the list in vendor red flags.

How to choose for your case

Look at your contact or drop off reasons. If they are mostly informational, build the chatbot: faster, cheaper, lower risk, and it will resolve them.

If they are mostly requests, change this, cancel that, fix this charge, a chatbot will answer and resolve nothing, and you will have bought a deflection number instead of an outcome.

How to sequence it

Ground the answers first, on a narrow scope, and instrument what people actually ask. That corpus of real requests tells you which actions are worth building and in what order.

Then add actions one at a time, each with its own permissions, confirmation and audit trail. Going straight to a broad agent is the most reliable way to end up in why pilots fail, and building in this order is how we deliver production AI, end to end.