Three generations, one word for all of them
Part of the confusion is that "chatbot" and "agent" now get applied to three genuinely different technologies, and most buyers never see the distinction spelled out.
Scripted, decision-tree bots are the oldest generation — the "press 1 for billing" phone tree reborn as a chat widget. They match a customer's words against a fixed set of branches and follow whichever path lights up. Phrase a question in a way the tree didn't anticipate, and it stalls or loops.
LLM chat that answers from your documents is the generation most people mean when they say "chatbot" today. It reads a knowledge base, a policy document, or a product catalogue and generates a fluent, specific answer — a real improvement, because it handles phrasing nobody hard-coded for. But it still only replies. Nothing changes outside the conversation unless a person reads the transcript and acts on it themselves.
Agents that act are the third generation, and the one this whole guide is really about. An agent is given an objective rather than a script, decides which steps to take toward it, uses tools to carry those steps out in your actual systems, and verifies the result before it calls the job done. Our glossary entry on AI agents covers the mechanics of how that works if you want the plain-English breakdown.
Vendors blur all three under one label because "agent" sells better than "document Q&A bot" — more on how to see through that later in this guide.
What a chatbot produces vs. what an agent does
The practical test is simple: look at what comes out the other end.
A chatbot's output is text. A paragraph, a matched answer, a suggestion pulled from a document — useful, but it lives inside the chat window until a human reads it and decides what to do next. Ask a chatbot where an order is, and it will tell you what the tracking page says, in better sentences than the tracking page itself.
An agent's output is a changed state somewhere else, plus a summary of what it changed. Ask an agent about the same delayed order and, depending on the scope it was built for, it looks up the shipment, checks the carrier's actual tracking record, notifies the customer, updates the order note in your CRM, and flags the exception to your operations lead if the delay breaks a service promise. The reply you see is a report of work already done, not the work itself.
That verification step is the part people miss. A chatbot with a plugin bolted on can technically call an API — but calling an API and confirming the result actually landed correctly are different engineering problems. An agent that books a slot on a calendar and doesn't check whether the booking succeeded isn't really an agent; it's a chatbot that occasionally breaks things quietly instead of loudly.
Chatbot vs. AI agent, side by side
| Dimension | Chatbot | AI agent |
|---|---|---|
| What it produces | A text answer in a chat window | A completed action in a real system, plus a summary |
| Systems access | Usually none, or read-only access to a knowledge base | Scoped read/write access to the specific systems the job needs |
| Failure mode | Gives an unhelpful or wrong answer; conversation stalls | Can take the wrong action in a live system if boundaries aren't set correctly |
| Oversight needed | Light — occasional spot-checking of transcripts | Designed in from the start: approval rules, logging, a defined handoff point |
| Cost to build and run | Low to build, often a subscription or a prompt over your docs; low to run | Higher upfront for integration and testing, scoped with a clear price before work starts; ongoing monitoring is part of running it well |
| Best-fit use cases | FAQ deflection, pre-sales information, first-line triage that hands off cleanly | Work that spans more than one system, or ends in a changed record rather than an answer |
The failure-mode row is worth sitting with. A chatbot's worst case is a wasted five minutes. An agent's worst case is a wrong refund, a duplicate booking, or a CRM record updated with the wrong information — which is exactly why oversight has to be engineered into an agent from day one, not bolted on after something goes wrong.
When a chatbot is genuinely the right, cheaper answer
It's tempting, in an article comparing the two, to make the case for the more sophisticated option every time. That would not be honest, and it would waste your money.
If the bulk of your volume is repeated, informational, and low-stakes — business hours, pricing tiers, what a policy covers, where the nearest location is — a well-tuned chatbot reading from your actual documents answers most of it correctly, deploys fast, and costs a fraction of an agent build. The cases it can't resolve get handed to a person with the conversation already in front of them, which is still a real time saving even without any system changing on its own. Our FAQ deflection use case walks through exactly this shape of problem.
If the honest scope of your problem is "answer the same fifteen questions correctly, all day," recommending a custom agent to solve it would be selling you a system you don't need. That's true whether we say it or a chatbot vendor does — the difference is whether the person telling you has anything to gain from steering you toward the pricier build.
When the work actually needs an agent
An agent earns its cost when the job doesn't end at an answer. Three signals tend to show up together:
- The task touches more than one system. The expensive part of most operational work isn't deciding what to do — it's carrying information between tools that were never built to talk to each other. A chatbot can't do that carrying; it can only describe what someone else should do.
- Every case is shaped the same but detailed differently. A pure repeat task belongs in a plain script. A pure judgment call belongs with a person. Agents sit in the gap — qualifying a lead, triaging a ticket, chasing a missing document — where the pattern holds but the specifics never quite match the last one.
- People are the bottleneck, not the thinking. If a task happens a handful of times a month, leave it manual. If it happens constantly and someone is permanently behind on it, that backlog is what an agent build is actually paying to remove.
If only one of those is true, an agent is probably premature. Our guide to build vs. buy for AI goes further into weighing a custom build against ready-made tooling once you've confirmed the shape fits.
A quick checklist: which one are you actually looking at?
Run your own workflow through these four questions before you talk to anyone selling either option:
- Does the job end with an answer, or with something changing? An answer that a person then acts on manually is chatbot territory. A record that needs to update itself is agent territory.
- How many tools does a person currently touch to finish this by hand? One system, a chatbot might cover it. Three or four systems, you're describing an agent.
- What happens when it gets something wrong? A mildly annoying re-ask is low stakes. Money moving, a customer being told the wrong thing, or a record being corrupted is the kind of stakes that require the approval rules and logging an agent build is designed around.
- How often does this happen? Rare enough to handle by hand, leave it alone. Frequent enough that a person is always catching up, that's worth building for.
"Agent" is a marketing word now — the questions that expose what's really being sold
Because "agent" currently carries so much attention, plenty of things marketed under that name are a chat interface with a system prompt describing itself as agentic, or a fixed workflow automation with no real decision-making inside it at all. The word "agentic" gets stretched to cover almost anything with an LLM in the loop, which makes it a poor signal on its own.
Four questions cut through the branding, and any vendor building a genuine agent should answer them without hesitating:
- "What does it actually change in our systems, beyond generating text?" If the honest answer is "it can suggest a reply," you're looking at a chatbot, whatever the pitch deck calls it.
- "What happens when it isn't confident — does it guess, or does it stop and hand off?" A real agent has a defined edge and a routing rule for reaching it. If there isn't one, there's no autonomy being managed, just unmanaged risk wearing the word "agent."
- "Can you show me a decision it made that wasn't the obvious one?" This reveals whether there's real reasoning over options, or a decision tree wearing a chat interface.
- "Who is accountable for its actions, and how is every one logged?" Anything with write access to a real system needs an audit trail. If a vendor can't produce one, the oversight the word "agent" implies was never actually built.
Our comparison of a custom agent against off-the-shelf copilot tools goes deeper into evaluating vendors making this exact pitch, including where a ready-made platform is genuinely the smarter buy.