A chatbot answers, an agent gets it done
The word agent has been used so much this past year that it has stopped meaning anything specific. Let us pin it down.
A chatbot takes a question and returns text. However good the model behind it, the output is always language. Ask it to change your delivery date and it will explain, very clearly, how to change it.
An agent takes the same request and does something: it finds the order in the system, checks whether it is still within the window under the company's rules, changes the date, records it in the CRM and confirms it is done.
The difference is not the language model. It is that somebody gave it tools and permission to use them. An agent is a model, plus a set of actions it can run, plus the rules that decide when to run them.
Put like that it sounds like one more step. In practice it changes the whole project: the moment a system can write to your CRM, you are no longer trialling a tool, you are putting software into production.
The four processes where they work today
This is not a list of what will be possible one day. These are the four places where we have seen agents running in real companies and holding up for months without anyone rescuing them.
- Lead qualification. A form comes in, the agent looks up the company, checks its size and sector, matches it against the ideal customer criteria, scores the opportunity and drops it into the right stage of the pipeline. The salesperson opens the CRM and finds the work already done. It is the most profitable case because the alternative, someone qualifying by hand, is slow and gets done badly on Friday afternoons.
- Document reading. Invoices, contracts, delivery notes, CVs, tender documents. The agent pulls out the fields that matter, normalizes them and drops them into a table. The gain here is measured in hours a month and is easy to calculate before you start.
- First-line support. It answers from the company's real documentation, and the moment it detects anger, a complaint or something outside its remit, it hands the conversation to a person with the context already summarized. The key is the second half of that sentence, not the first.
- Recurring reports. That weekly summary someone assembles by hand from four sources. The agent gathers the data, cross-references it, writes the draft and leaves it ready for a person to review and send.
What those four have in common
Look closely and all four share three things.
The process already existed. Someone was doing it by hand and it could be written on one page. Agents do not invent processes, they run them. If nobody can explain how a lead gets qualified today, automating it does not fix that: it freezes the mess permanently.
Mistakes are cheap. If the agent scores a lead wrong, the salesperson fixes it in ten seconds. If it pulls the wrong field off an invoice, it shows up in review. None of the four make irreversible decisions.
There is a human at the end of the chain. Not reviewing everything, but at the point where the output reaches the world: the email that goes out, the invoice that gets posted, the reply to the angry customer.
The three reasons these projects fail
This is where projects break, and none of the three is about technology.
The process is not written down anywhere. By far the most common. The company wants to automate something five people do five different ways, each with their own exceptions held in their head. The project quietly turns into an exercise in documenting how the company works. That is valuable, but it is not what was bought or budgeted for.
The data is scattered and does not connect. The agent needs to look at the CRM, the ERP and a spreadsheet someone in admin keeps. If those three have no way of being queried, the real work is not AI: it is integration. And that is where most of the budget goes on the projects that go wrong.
Mistakes are expensive and nobody reviews them. Any process where being wrong carries legal, financial or safety consequences needs a person validating. If the saving you were after was precisely removing that person, the business case does not hold. Better to know that before signing.
What to ask before hiring anyone
If you are weighing up suppliers, these five questions separate the ones who have done this from the ones who will learn on your money:
- What happens when the agent gets it wrong? If the answer does not cover how it is detected, who reviews it and how it is corrected, there is no design behind it.
- Where is my data stored and which model processes it? That is a GDPR question, not idle curiosity. And with the AI Act now in force, get the answer in writing.
- What if I want to switch model provider next year? If the agent is welded to a single provider with no layer in between, you have bought a dependency, not a solution.
- What does it cost to run each month? Not the build: the consumption. An agent processing a thousand documents a month has a variable cost you should know up front, not discover on the invoice.
- Will you let my team understand it? If the supplier walks away and nobody on your side knows where a rule is changed, you have a problem with a date on it.
Where to start if you have done nothing yet
Our recommendation is nearly always the same and it is not exciting: take the most boring, most repeated process you have and automate that one first.
Not the most ambitious. Not the one that would look best in a board deck. The boring one.
There are three reasons. It tends to be well documented precisely because it is routine. The saving can be measured without argument: hours before, hours after. And the one that matters most, the team learns to work with an agent somewhere being wrong costs nothing.
After that first one, the company knows what to ask for, what to demand and what to distrust. That is when it makes sense to go after the big process.
Starting the other way round, with the ambitious visible project, is the most common route to a very handsome demo that nobody is using three months later.
Frequently asked questions
A chatbot generates text; an agent takes action. A chatbot explains how to change a delivery date; an agent goes into the system, checks the rules, changes it and logs it. Technically, the agent has tools connected and permission to use them, which turns the project into a software integration rather than a trial of a tool.
A well-scoped case with the process already documented takes three to six weeks. If you have to integrate systems that do not expose their data, the timeline is set by the integration, not the AI, and that pushes it to two or three months. When someone promises two weeks without having seen your systems, they are assuming everything will connect smoothly, and it almost never does.
It replaces tasks, not people. In the cases that work, what disappears is the repetitive work (qualifying, extracting, summarizing) and what remains is judgment, the client relationship and the exceptions. If the business case depends on removing a whole role, it usually means the process carries more judgment than it looked like, and the plan is worth revisiting.
Two frameworks at once. GDPR, if the agent handles personal data: you need to document the legal basis, the processing and, in high-risk cases, run an impact assessment. And the EU AI Act, which sorts systems by risk level and requires transparency, human oversight and traceability. Both belong in the architecture phase: rebuilding a system to comply afterwards costs far more than designing it right.
Two costs worth separating. The build, which is one-off, and the running cost, which is monthly and varies with the volume it processes. That second one depends on the model you use and how often it gets called, and it is the one that surprises people who never calculated it. Always ask for an estimate based on your real volume, not on an example.