What is an AI agent, and when do you need one?
The word “agent” is now stuck to almost every product. The useful distinction is one verb: a chatbot answers, an agent acts. Everything that gets interesting after that is not about what it can do, but about what you allow it to do.
What is an AI agent?
An AI agent is a system that pairs a language model with access to real systems, so it can work through a sequence of steps by itself: look up what it needs, decide what has to happen, take the action, and report back.
The difference from a chatbot is one verb. A chatbot answers. An agent does — it creates a record, drafts a document, submits a request.
That makes agents more useful and riskier at the same time. Which is why the interesting question about an agent is not how much it can do, but what it is allowed to do.
Chatbot or agent: which do you need?
A chatbot that tells you how to file a leave request is a chatbot. A system that files it, notifies the approver, and reports the outcome is an agent.
In practice they blend. Most applications start as a chatbot and gain permissions one step at a time as confidence builds. That is the sensible order, because permissions are far easier to widen than to claw back.
So start small. An agent that can do everything on day one is an agent nobody switches on.
What must an agent do before you switch it on?
Autonomy is only useful with brakes. Building an agent that can do a lot is not the hard part; building one you dare point at real work is.
- Fetch what it needsA record in your CRM, an earlier email thread, a rate in a table. You should not have to know in advance which data it will want — that is rather the point.
- Stop when unsureToo little grounding means asking, not guessing.
- Act within its permissionsNever more than the user it acts for. That is a design requirement, not a setting you enable later.
- Report what it didWhat happened, on what basis, and what is still open. Without that trail it is not auditable, and therefore useless on work that matters.
- Fail cleanlyAn API that is down, a document it cannot read: report and stop.
- Wait for approval where it countsOn steps touching money, customers, or liability — including visibility into why it is proposing this.
- Be measurableA test set from your own edge cases, so every change is demonstrably better or worse.
Where do agents pay for themselves?
On work with many steps and little judgement. Moving data between systems, assembling case files, triaging alerts, preparing standard replies. Work people are good at but get nothing out of.
And above all, where the work already happens. Wally runs inside the accountant's inbox. IPRHQ puts actions in Word and in Chrome, exactly where an infringement gets spotted. An agent living in a separate tab stops being opened after two weeks, however good it is.
Where they do not pay off: processes that fit into a handful of if-then rules. Classic automation is cheaper there, faster, and far easier to explain.
How do you stop an agent making mistakes?
You do not, entirely. So you design for them.
Three things do most of the work: make it cite the source of every answer, make it stop and ask when unsure, and put an approval step before anything irreversible. That last one is thin on its own — approving without seeing why something is proposed is signing with your eyes shut.
On IPRHQ the gain came precisely from that ranking: not forwarding every alert, but sorting threats by relevance so a team looks at what matters first. Decisions that took weeks moved to hours.
Start with one process
Name the work made of many steps and little judgement. That is almost always where the first agent that pays for itself sits.