The short answer.
A chatbot answers questions in a chat window. An AI agent reads and acts inside the systems that run your business — it checks the order, drafts the follow-up, logs it in the CRM — with permissions you set. Same intelligence underneath, completely different job. One is a better search box. The other is a worker.
That one distinction decides whether AI takes real hours off your payroll or just produces drafts somebody still has to act on. Most of the AI disappointment I hear from owners isn't the model failing — it's a chatbot being asked to do an agent's job.
The model isn't the difference. The wiring is.
Here's what surprises most owners: the chatbot and the agent can run on the exact same model. The difference isn't intelligence — it's access. A chatbot knows its training data and whatever you paste into the window. An agent is connected to your order system, your accounting, your CRM. It can look things up in live data and take the actions you've allowed — and nothing else.
That connection is infrastructure, not magic. The open standard that handles it is MCP — I've written a plain-English guide to what an MCP server is if you want the plumbing. For this article, one sentence covers it: MCP is the bridge that turns a model that talks into an agent that works.
Chatbot vs. agent, row by row.
Five rows. If you only read one thing on this page, read the last two.
| A chatbot | An agent | |
|---|---|---|
| Answers questions | Yes — from training data and whatever you paste in | Yes — from your live systems, with sources |
| Does work in your tools | No. It drafts; a person still does the clicking | Yes — checks, updates, sends, and logs, within permissions you set |
| Needs your systems connected | No — which is exactly why it's cheap | Yes — the connection is the actual build |
| Cost shape | Flat subscription, per seat | A build, priced against a measured leak |
| Where it breaks | The first question about your data — it guesses | Fuzzy scope — built before anyone measured the problem |
Sometimes a chatbot is enough. Buy the cheap thing.
Not every problem needs an agent. If your team answers the same forty questions over and over, a chatbot answers most of them before they reach your people, for the price of a subscription. If your operations manual is three hundred pages nobody opens, a chatbot that answers from it is a real upgrade. Same for the Q&A widget on your marketing site.
The pattern: when the deliverable is an answer — and a human is fine doing whatever comes after — a chatbot is the right buy. Don't pay build money for a chatbot job. If that's your situation, I'll tell you so, and it'll be the cheapest advice you get all year.
You need an agent when the answer isn't the job. The follow-through is.
Watch what actually happens after the question. A customer asks where their order is. The answer takes ten seconds — the job is checking the carrier feed, spotting the stalled shipment, sending the heads-up, and noting it on the account. A chatbot gives you the ten seconds. An agent closes the ticket.
Your aging report already knows who owes you money. The work is drafting the reminders in your language, sending them, logging every touch, and putting the two accounts that need a phone call on a human's desk. Or take dispatch: tickets, paperwork, and the crew list live in three different systems, and every morning somebody reconciles them from memory. An agent runs that same check from the systems themselves and surfaces what's missing before anyone rolls.
That's the test I use: if the value is in the doing, not the knowing, it's agent work. It's how I scope every build — details on the AI agent development page.
Keep reading: MCP vs. API — what's actually different? covers the plumbing underneath agents, and AI agent development shows what the builds cost and how they run.