99% of "AI agents" are chatbots in a trench coat

Every week I sit through a deck presenting an "AI agent", and two questions later it turns out to be a language model with a nice interface in front of it.

This is not pedantry about terminology. The difference determines what the system can do, what it can break, and what it costs to run. Anyone buying an agent and receiving a chatbot is buying expectations that will not be met.

The test: four questions, two minutes#

Ask of any system put in front of you:

Does it plan? Does it break the task into steps itself, or are the steps written in the code beforehand?

Does it call tools? Can it decide to use a tool, read the result, and build on it?

Does it correct itself? When a step fails, does it notice and try another route, or stop, or continue with a wrong answer?

Does it know when it is finished? Does it have a success criterion it measures itself against?

What the difference means in practice#

The last row is the real criterion: if you know the steps in advance, you do not need an agent. An automated workflow is cheaper, faster and easier to debug. An agent earns its cost only when the steps themselves are unknown before execution.

Why the distinction matters financially#

A real agent calls the model many times per task: once to plan, once per step, once to read each tool result, once to decide what comes next.

Which means an agent can cost twenty times a chatbot for the same outcome. Sometimes that is worth it. Sometimes you are paying twenty times over for planning nobody needed.

The dangerous part: permissions#

A chatbot's mistake is wrong text, which you read and disregard. An agent's mistake is a wrong action on a real system.

Add prompt injection to that: any agent reading external content is reading text that may contain instructions aimed at it. The only safe rule is that everything arriving from outside is data, not commands.

Ask any vendor this#

The honest part#

The distinction I have drawn is a spectrum rather than a hard line. Plenty of systems sit in the middle: they plan a little within narrow bounds, or call two tools rather than twenty. That is entirely sensible engineering.

My objection is not to simple systems. It is to what they are called. A good automated workflow beats a poor agent in most real situations, costs less, and is easier to maintain. The trouble is that "agent" sells better, so it gets attached to everything.

In closing#

Agent is not a marketing adjective. It is an architecture with specific costs and specific risks. Whoever knows the difference buys what they need; whoever does not pays for planning in a system that does not plan.

Apply the four questions today to the nearest thing you have heard called an agent. Fewer than four yeses means you are looking at automation, and that is worth knowing before you sign.

And if you want your team building real agents, and knowing when not to, that is the route in the agents and automation course.

Common questions#

What is the difference between an agent and a chatbot?

A chatbot answers a question and stops. An agent plans its own steps at runtime, calls tools and reads their results, corrects course when something fails, and knows when the task is complete.

When do I not need an agent?

When you know the steps in advance. An automated workflow is then cheaper, faster, easier to debug and far more predictable. An agent earns its cost only when the steps differ case by case.

Why are agents more expensive?

Because an agent calls the model many times per task: to plan, per step, to read each tool result, and on every retry. The difference can reach twenty times for the same outcome.

What is the biggest security risk with agents?

Permissions combined with prompt injection. Any agent reading external content may read instructions aimed at it, and if it holds write or send permission it may act on them. Treat everything from outside as data, never commands.

How do I tell whether something really is an agent?

Ask four questions: does it plan itself, does it call tools and build on their results, does it correct itself on failure, and does it know when it is done. Fewer than four yeses means automation with a smart interface.