AI agents and chatbots are not the same thing, and the difference is verifiable

If you have ever typed “LET ME TALK TO A HUMAN” into a company’s chat window, you already know what a chatbot feels like when it hits its ceiling. What almost nobody explains is where that ceiling sits, and why an AI agent moves it.

The short version: a chatbot looks things up, an agent makes calls.

A chatbot finds an answer that already exists

A chatbot, even a modern one with a language model behind it, does one thing: it finds the best answer inside whatever you loaded into it. You upload the manual, the policies, the website, and it answers from there.

That works perfectly as long as the answer is written down somewhere and does not change:

• “What time do you open?”
• “What is your return policy?”
• “Do you ship to Denver?”

And it collapses the moment the answer depends on live data:

• “Do you have SKU 4021 in a medium?”
• “What does it cost to ship three kilos to Bogota?”
• “Can you book me Thursday afternoon?”

None of those three is answered by reading a document. They are answered by querying a system. And a chatbot does not query systems, which is why the only honest exit it has left is “an advisor will contact you.” That sentence is not a copywriting failure. It is the edge of the technology.

An AI agent calls tools

An agent has, on top of the model, a list of tools. Each tool is a concrete function against a real system, with a name, parameters and permissions.

That is not a metaphor. In our case the tools are published by name on every record in the catalog, and that list comes out of the code, not out of a marketing deck. The native CRM, for example, exposes crm_create_contact, crm_update_contact, crm_search_contacts and twenty-one more. The scheduling connector exposes agenda_get_event_types, agenda_get_slots and agenda_create_booking.

With that list, “book me Thursday afternoon” stops being a promise and becomes a three-call procedure:

1. agenda_get_event_types returns which services can be booked and how long each one runs.
2. agenda_get_slots returns the openings that are genuinely free between two dates.
3. agenda_create_booking reserves the exact slot the person picked.

The Met does not invent the time. It reads it. And it does not retype it by hand, which is where time zone errors get in.

That ability to connect a model to real tools rests today on an open standard, the Model Context Protocol. The fact that it is a standard rather than one vendor’s invention matters for a practical reason: an agent’s tool list can be inspected, and therefore verified.

The table that helps, and the one that does not

Almost every comparison you will find comes with a table of adjectives: “rigid” versus “fluid,” “literal” versus “contextual.” All true, all useless, because none of it can be checked before you sign.

Here is the version you can actually check:

What you ask the vendor	Chatbot	AI agent
Which tools can it call?	Not applicable: it calls nothing	A list, with names
Which credentials does it need?	None, or just the channel	One per connected system
What happens when the external system fails?	Not applicable	There has to be an answer
Can it write, or only read?	It only returns text	Depends on what you enable
Where is what it did recorded?	In the conversation	In the conversation and in the system

If the answer to the first question is a category (“it integrates with your CRM”) instead of names, you are still looking at a chatbot with better conversation.

Executing also means being able to get it wrong

Here is the part most articles on this topic leave out, and the part most worth reading.

A chatbot fails loudly: it says it does not understand, the customer gets annoyed, you hear about it. An agent fails quietly: it creates the order with the wrong quantity, and you hear about it when the complaint arrives.

Which is why “what tools does it have?” is really a security question, not a capability question. An agent that can only read cannot break anything. One that can write needs explicit limits, and those limits have to be written down before you turn it on.

That is the reason several of our integrations are deliberately read-only, and the reason every record in the catalog carries a block spelling out what it does not do. Querying an ERP is not the same as modifying it. Creating an invoice record is not the same as filing it with the tax authority.

How to decide which one you need

This is not a technology decision. It is a decision about which questions reach you.

Take a hundred real conversations from last week and sort them into two piles: the ones answered by information that is already written down, and the ones that need something looked up or changed. If the first pile is the majority, a well-loaded chatbot solves your problem and costs less.

If the second pile is the majority, no chatbot is going to serve you no matter how well it converses, and what you are looking for is a Met with your systems connected.

Most of the businesses we look at have a bigger second pile than they expected, and the surprise always comes from the same place: stock, price and availability questions feel simple to answer, but not one of them is answered by reading a document.