The term is used loosely enough to have lost precision, which is unhelpful when you are trying to decide whether to spend money on one. Here is a definition that holds up.
A chatbot produces text. An agent takes actions.
Ask a chatbot to process an invoice and you get a description of how one might do that. Give an agent the same task and it reads the invoice from the mailbox, extracts the supplier, amount and reference, checks them against your purchase orders, and drafts an entry in your finance system.
To do that, it needs three things a chatbot does not have: a goal, a set of tools it is permitted to use, and the latitude to decide the order of steps.
Why the distinction matters commercially
Because a system that only produces text is limited in the harm it can do. A system that can act inside your finance system, your mailbox or your CRM is functionally a new member of staff with system access.
That framing is the most useful one we know for making decisions about agents. You would not give a new starter unrestricted access to every system on their first morning, let them commit payments without review, or fail to keep a record of what they did. The same reasoning applies here, and for the same reasons.
What agents are genuinely good at
The pattern is consistent: high volume, recognisable structure, tolerable cost of occasional error, and a human reviewing exceptions.
- Reading incoming documents and extracting structured information
- Moving information between systems that have no integration
- Classifying and routing incoming work in a shared mailbox
- Drafting routine correspondence for approval
- Retrieving and summarising information from internal sources
- Watching for a condition and escalating it to a person
- First-pass checks that a person then confirms
The common thread is that a person is still accountable for the outcome, but they are reviewing rather than transcribing.
What agents are not good at
Being clear about this is what keeps the first list credible.
Low-volume tasks. Building and maintaining an agent has a real cost. A task performed twice a week rarely justifies it, however tedious.
Decisions where being wrong is expensive or irreversible. Approving payments, signing contracts, making employment decisions. An agent can prepare these; it should not commit them.
Work requiring accountability that cannot be delegated. If a regulator, a court or a client will hold a named person responsible, that person needs to have made the decision — not reviewed a summary of one.
Processes that are already broken. Automation executes an unreliable process faster and more consistently. It does not repair it. This is the most common mistake we are asked to correct.
Work depending on context nobody wrote down. If the process only functions because a particular person knows which exceptions matter, that knowledge has to be captured before it can be automated. Frequently, capturing it is the valuable part and the automation is secondary.
Situations where a customer needs a person. A faster reply is not always a better one.
The controls that make an agent deployable
Whatever the use case, the same design questions apply. We settle all of them in writing before anything touches a live system.
Whose identity does it act under? Its own, always. A dedicated service identity means every action is attributable to the agent, and its access can be revoked without disrupting a person. Agents running under a staff member’s account are indistinguishable from that person in your logs, which is a problem you discover during an investigation.
What can it reach? An explicit list of tools and endpoints, and nothing else. Read access separated from write access, scoped to the specific mailbox, folder or record set the task requires.
What requires human approval? Anything with financial, legal, contractual or reputational consequence. The agent prepares; a person commits. In a well-designed workflow this takes seconds and is the thing that makes the system defensible to an auditor.
What happens when it is uncertain? It escalates. An agent that guesses when confidence is low produces a plausible-looking error rate that nobody notices for months. An agent that escalates produces a manageable exception queue, which is a far better failure mode.
What is recorded? Every input, tool call, output and approval, retained long enough that an individual case can be reconstructed when a customer queries it next year.
Who is watching? Volume, exception rate, latency and failures. A silent agent that stopped working three weeks ago is common and expensive.
How do you stop it? A named person, immediately, with the manual process it replaced still documented and workable.
On autonomy
There is considerable enthusiasm at present for agents that operate with little supervision. It makes for a compelling demonstration and a poor operating model for a business with auditors, insurers and customers.
The value of these systems is not that they remove people. It is that they remove the transcription, the copying between systems and the checking of routine cases, leaving people to do the part that requires judgement. A finance team reviewing forty exceptions instead of keying nine hundred invoices is a substantial gain — and it does not require anyone to pretend the system is infallible.
So should your business use one?
Ask three questions.
Is there a specific, high-volume process that consumes real time? Not “could AI help us” but “this task takes one person three days a month”. If you cannot name it, the answer is not yet.
Is the process well understood and reasonably stable? If the people doing it disagree about how it works, fix that first. You will get value from the exercise regardless.
Can you tolerate occasional error, given a human review step? If every case must be right first time with no checking, the economics rarely work.
Three yeses means it is worth costing properly. Fewer than three means the honest answer is not yet — and there is usually something more valuable to do with the same budget.