Almost every conversation about automation this spring starts with the word agent. What people usually mean is: something with AI in it that does more than a chat window. The vagueness is convenient, and it is expensive. Between a system that answers and a system that acts sits all of the real work.
A chatbot answers, an agent acts
A chatbot takes a question and hands back text. Whatever happens next is still your job. An agent takes an assignment and works through it. It opens the incoming email, recognises the order enquiry inside it, pulls out the customer number, the article number and the quantity, creates a record in your system and sends back a short note saying exactly that. The chatbot produces language. The agent changes your data.
That is not a small step up. A clumsy chatbot sentence annoys a customer for ten seconds. A wrongly created record travels through your process chain, becomes a delivery, becomes an invoice, shows up in your accounts and, on a bad day, is only spotted at the close of the quarter. Putting agents to work moves the risk out of your communication and into your substance. That can pay off. It assumes you know what you are doing.
Where agents genuinely carry their weight
An agent earns its keep where a task keeps coming back and where you can tell straight away whether it was done correctly. Reading incoming invoices and preparing the payment run. Sorting service requests and routing them to the right team. Pulling supplier lists into one consistent format so the article data can be compared at all. Nobody enjoys this work, it is easy to describe, and a mistake shows up the same day.
We run our own platform and we use agents there for exactly this kind of groundwork. The value does not come from intelligence. It comes from repetition. A person copying line items out of a PDF for the fortieth time that afternoon gets sloppy. An agent will not. It makes other mistakes instead, and at least those are predictable.
And where they reliably fall over
The usual reason an automation project dies is not technical. It is that the process was never described properly in the first place. Ask five people in a company how a complaint is handled and you get five versions, each convinced it is the correct one. A person smooths over those contradictions without noticing. An agent does not. It sets the version that happened to be in its instructions in concrete.
The second killer is data quality. If the same company exists four times in your system under four spellings, the agent will happily create the fifth record. And the third case where I would advise against it: tasks where a mistake is costly and stays invisible for a long time. Pricing. Credit decisions. Anything that sets a deadline. Speed does you no good when the damage lands on your desk six months later.
My honest view after a few of these projects: the most expensive mistake is to point an agent at a process you cannot explain yourself. The automation then only exposes what was already unclear, and to everyone involved it feels like a technology problem. It is not one.
Permissions need boundaries
An agent that is supposed to act needs access. It needs an account, it needs write permissions, and at that moment it is a user like any other. Just faster. Treat it accordingly. Give it its own technical account rather than the login of an employee. Give it precisely the rights its one task requires and nothing beyond that. An agent allowed to create records has no business deleting master data.
A log belongs with it. Every action with a timestamp, a trigger and a result, readable by someone who is not a developer. If in four weeks you cannot reconstruct why a record looks the way it does, you do not have automation. You have a black box with write access. The difference becomes obvious exactly once, and always at the wrong moment.
The human stays in the approval path
Wherever money moves or a commitment to a third party is created, the agent should prepare and not execute. It reads the invoice, matches it against the order, flags the differences and puts the record forward for approval. The person clicks. That sounds like half a step, but it is the point at which automation becomes durable in a mid-sized company: it takes away the grind and leaves the decision with someone who answers for it.
In our AI consulting we therefore walk through the process first and the technology second. Not out of principle, but because the other order keeps costing money.
Frequently asked questions
What is the difference between a chatbot and an AI agent?
A chatbot produces an answer that a person then uses. An agent carries out steps inside your systems, so it creates the record itself. That gives it responsibility for your data, which is why it needs permissions, limits and a log.
How big does a company need to be for an agent to pay off?
Size matters less than frequency. What counts is a clearly describable task that comes up often and whose result can be checked. If someone performs the same job several times a day, it can already add up in a small business.
Can we start with a single process?
That is the only way I would recommend. One bounded process, running for two to four weeks, with someone checking the output, tells you more about whether this fits you than any presentation will.
If you are wondering whether one of your recurring tasks might be a candidate, we are happy to look at it with you, with no obligation and no sales pressure.
This article is part of our knowledge hub AI and digitalisation for small and mid-sized companies.