What an AI agent actually is, and what it is not

A chatbot answers a question. An agent finishes a task. That distinction sounds small until you try to buy one, at which point almost every vendor calls their product an agent and the word stops meaning anything.

Here is the line we use internally, and the one we explain to clients in the first meeting.

The difference is whether it can act

Ask a chatbot to check whether an invoice was paid and it will tell you how to check. Ask an agent and it will open the accounting system, look, and answer with the date and the amount.

The model in the middle might be identical. What changes is everything around it: the tools it is allowed to call, the permissions those tools carry, and whether anything happens when it decides to do something. An agent is a model plus the authority to use software on your behalf.

That authority is the whole design problem. It is also why the interesting questions in an agent project are rarely about the model.

What an agent needs before it works

An agent that can act needs four things in place, and the model is only one of them.

• Tools it can call. Usually your existing systems, reached through an API or, when there is no API, through something that drives the interface.
• A definition of done. "Handle the email" is not a task. "Reply with the tracking number, or escalate to a human if there is no order matching the address" is.
• A record of what it did. Every call, every argument, every result. When an agent gets something wrong you need to be able to read back the exact sequence rather than guess.
• A boundary it cannot cross. Refunds above a threshold, anything that emails a customer, anything that deletes. These go to a person.

Most failed agent projects we see failed on the second and fourth points. The model was fine. Nobody had written down what finished looked like, or what the agent was forbidden to touch.

Where agents earn their keep

The work that suits an agent has a particular shape. It is repetitive, it spans more than one system, and a competent person could do it with clear instructions but it would bore them.

Moving data between a CRM and an invoicing tool. Reading a supplier email, extracting the order lines, and putting them somewhere structured. Watching a shared inbox and drafting the reply that a human then sends. None of this is glamorous, which is rather the point: the value comes from it happening two hundred times a month without anyone thinking about it.

Work that does not suit an agent tends to be the opposite. One-off decisions. Anything where being wrong is expensive and hard to detect. Anything that depends on context that lives only in somebody's head.

The honest version of the tradeoff

An agent will not be right every time. Neither is the person currently doing the task, but the failures look different, and organisations are much better at absorbing human error than machine error.

So the question to ask a vendor is not "how accurate is it". It is "what happens on the runs where it is wrong, and how quickly will I know". If there is no good answer to that, the accuracy number is decoration.

We build AI chatbots and agents for businesses, and the first thing we do on any agent project is write down the failure cases before writing any code. It is less exciting than a demo. It is the reason the thing still works in month six.

If you want to see the shape of these projects in practice, what we have built is a reasonable place to start.