What is an AI agent, and how is it different from a chatbot, RPA or a workflow tool?

"Isn't an AI agent just a chatbot with a new label?" It's a fair suspicion. These days the word shows up on almost any product with a language model inside it. So what is an AI agent, in terms that help you decide whether to buy one? Here is the short version. A chatbot answers a person. A workflow tool runs a fixed chain of rules. An RPA bot clicks its way through screens. An AI agent completes a piece of work inside your systems, even when the input looks different every time.

Definitions only get you so far, so below we send one ordinary email to all four and watch what each of them does with it.

What is an AI agent, compared with the other three?

A chatbot lives in a chat window. It answers questions, summarises documents and drafts text, and a person reads the result. It doesn't enter anything into your ERP, and it does nothing until someone asks it something.

Workflow tools such as Make, Zapier, n8n or Power Automate connect systems through their APIs. An event starts them, say a new row in a spreadsheet, and they run a chain someone built in advance: copy field A to field B, send anything over 1,000 euros for approval. They're fast, cheap to run and reliable, as long as the data arrives in the same shape every time.

RPA (robotic process automation) operates a program's user interface the way a clerk would: open the form, paste a value into field 3, click save. It's how you reach older systems that have no API. The bot still follows a fixed script. It just executes that script on the screen.

An AI agent gets a task and a set of tools. It reads whatever comes in, including free text, PDFs and ambiguous emails, and works out which step it needs next: look something up in the ERP, match a master record, create a draft, prepare a question for the customer. The language model handles the understanding. You decide which tools it may use, which rules it follows and where it has to stop. When it isn't sure, it flags the case instead of guessing.

One email, four tools

The example below is made up for illustration. It isn't a client case.

Say a wholesaler of medical and care supplies receives this email from a regular customer on a Tuesday morning: "Same as last week please, but 20 boxes of nitrile gloves size M instead of 12. This time deliver to our new branch in Bochum, Hattinger Straße 12. Thursday would be great." No attachment, no item number, no customer number.

The chatbot

Someone in the sales office pastes the email into a chat window and asks for a summary. That part works: customer, quantity, size, new address, date. But the chatbot has no idea what "same as last week" means, because it can't see the ERP. The order still gets typed in by hand. The chatbot saved her the reading. The looking up and the typing are still hers.

The workflow tool

The workflow fires on every new email in the orders inbox. It was built for orders that arrive as an Excel sheet with columns for item number and quantity. This email has neither. The workflow finds nothing to map, so the message ends up in an error queue, or in the worse case the run just stops and nobody notices. You could add a branch for "same as last week". Then the next customer writes "the usual" or "same quantity as always", and every new phrasing needs another branch.

The RPA bot

The bot can open the order screen in the ERP and fill it in. It needs to pick the values up from a fixed place, though, like row 4 of a spreadsheet. Here the values are buried in a sentence, so there's nothing for it to copy. RPA earns its keep when a tidy list has to move into a system that has no API. Free text isn't that.

The AI agent

The agent reads the email and classifies it: a new order that refers back to an earlier one. The sender's address identifies the customer. In the ERP it finds last week's order, 12 boxes of nitrile gloves size M, with the item number and the agreed price. It keeps item and price and sets the quantity to 20. The Bochum address isn't in the customer master, so the agent attaches it to this order as a one-off delivery address and suggests creating it as a new record. It doesn't touch the master data itself. It turns "Thursday" into a date and checks that stock covers 20 boxes.

Then it creates the order with the status "to review". Every field carries a note saying where the value came from: the email, last week's order, or the master data. The person in the sales office opens a finished draft with a single highlighted item, the new address. She checks it and approves. Only then does the order confirmation go to the customer.

If the customer had placed two different glove orders last week, the agent wouldn't pick one. It would show both and draft a short question to the customer, ready for her to send.

What an agent is made of

Three parts work together in that example: a language model that understands the input, fixed rules for anything that can be written down as a rule, and a short list of tools such as reading the ERP, creating a draft and writing a question. If a customer has sent the same Excel sheet for years, the agent reads it with a fixed rule, because that's faster and cheaper. The model only steps in where rules run out.

That's why "agent or workflow tool?" is often the wrong question. A well-built agent contains the fixed chain wherever it fits and adds the steps where, until now, a person had to read something and make a call. How far it goes is your decision. In the example it may create drafts, but it can't send confirmations or change master data.

Which tool fits which process

If the data always looks the same and both systems have an API, a workflow tool will do. If employees or customers need answers from a fixed body of knowledge, a chatbot is the right choice. If an old system only has a screen and the data arrives in neat rows, RPA can bridge the gap, provided the screen rarely changes. An agent pays off wherever a person currently reads free text, looks things up in two or three systems and then enters something: orders from emails, supplier confirmations, requests to a hospital's patient administration, transport orders at a haulier.

When a vendor pitches you an "AI agent", three questions sort things out. What does it read, fixed fields only or free text as well? Where does it write, into a chat window or into your systems? And what does it do with the case nobody planned for: stop, guess, or flag it and ask? The answer to the last one tells you whether you're looking at an agent or a relabelled chatbot.

What Sophera Consulting builds

Sophera Consulting builds AI agents for individual processes, at a fixed price and with no subscription. An agent takes one to two days to set up, and testing with your real cases happens the same week. Not every process needs an agent, so we build whatever fits yours best: a workflow, an RPA solution, an agent or a mix of them. Every agent comes with a maintenance agent that watches the interfaces for changes and tests new model versions against old cases. The only running cost is the usage fee for the AI models, billed directly to you. The models run on European infrastructure, or on your own hardware if you prefer. Which of your processes makes a good first agent is what we work out in the free automation check.

Our recommendation

Pick the process where someone currently reads emails or PDFs and types the contents into your system. Put aside ten real inputs from the last few days, messy ones included. Ask every vendor what their tool does with exactly those ten, and have them show you. A tool that only copes with the clean ones leaves the real work with your team.