The word “agentic” arrived in business conversation recently and has been doing heavy lifting ever since, mostly in sales decks. Strip the marketing away and there is a real technical distinction underneath it, and it does matter.
What follows sets out what the term means, where the technology works, where it falls over, and what agentic AI means for UK businesses deciding whether to spend money on it. It is a description rather than an argument, aimed at whoever has to decide whether this is worth a budget line.
What is the actual difference between a chatbot and an agent?
A chatbot responds. You ask, it answers, the exchange ends. An agent is given a goal rather than a question, then plans the steps, calls the tools it needs, checks its own progress and keeps going until the goal is met or it gets stuck. Nobody prompts each step.
That sounds like a modest difference. It is not. Once software acts across several steps without a person approving each one, the failure modes change and so does the oversight problem.
The components are not exotic. A language model does the reasoning. Tools give it hands: read an inbox, query a database, call an API, send an email. A loop feeds each result back in so it can choose the next action.
What gets sold as autonomous AI systems is that loop plus permissions. The intelligence is not the new part. Permission to act without asking first is.
What does an AI agent look like in an ordinary business?
Considerably less impressive than the demonstrations. The genuinely useful cases are back-office: matching supplier invoices against purchase orders and flagging only the mismatches, sorting inbound email into queues and drafting the routine replies, watching stock levels and raising a purchase order, chasing late payments on a schedule.
- Invoice reconciliation. The agent reads the invoice, finds the matching purchase order, checks quantities and prices, posts the clean matches and sends only the exceptions to a Most of the volume is clean, and the value is in nobody reading it.
- Email Everything arriving in a shared mailbox is read, categorised and routed, and where the reply is standard, drafted for a person to send. Drafted, not sent.
- Stock and Given reliable stock data and agreed reorder points, an agent can watch levels, allow for lead times and raise a purchase order for approval.
- Credit Overdue invoices chased on an agreed schedule, with disputes read and routed to a person rather than chased again.
What those share is that the process is already written down somewhere and somebody can say what correct looks like. That is not a coincidence.
Why are the interesting cZses so boring?
Because agents need a definition of done, and back-office work has one. Customer-facing novelty is where the demonstrations live and where the risk sits. An agent improvising with your customers is a brand problem waiting to happen. An agent reconciling a ledger is arithmetic nobody wanted to do.
The hype runs the other way, towards the visible: the AI that handles your customers, the AI that writes your marketing. Those are exactly the areas where quality is subjective, mistakes are public, and nobody can write down the rule the agent should follow.
Back-office work is the reverse. High volume, low judgement, rule-governed and invisible when it goes well. If you want to see where AI agents in business earn their keep, look at the work nobody writes case studies about. A mistake in invoice matching is found at month end by someone who was going to check anyway. A mistake in a customer conversation is found by the customer.
What goes wrong, and how fast?
The defining failure is scale. A person working from a wrong assumption makes a handful of mistakes before somebody notices. An agent working from the same wrong assumption makes that mistake across every record it touches, at machine speed, overnight, and then reports that it finished successfully.
Picture an agent chasing overdue invoices. It reads the ledger, finds everything past terms and emails the contact on file. Suppose a date field was imported wrongly during a migration two years ago, so settled invoices still show as open. By morning, several hundred customers have a demand for money they already paid.
This is not an AI problem in the usual sense. It is an automation problem that AI makes cheap to create. The model did not hallucinate. It reasoned correctly from bad data at a volume no person could match.
Agents are also poor judges of when they are out of their depth, and will produce a plausible next step rather than stopping to ask. Processes drift too: a supplier changes an invoice layout, someone adds a field, nobody tells the agent. Treat a confident report of success as unverified.
Where should the human in the loop sit?
At the point of irreversible action, not at every step. A human in the loop approving hundreds of routine items a day stops reading them within a fortnight, which is worse than no checkpoint at all because it looks like control. Review the exceptions and the consequential actions instead.
The question to ask of any proposed agent is which of its actions cannot be undone cheaply. Preparing a draft is reversible. Sending an email to a customer is not. Paying an invoice is not. Those are your checkpoints.
Everything else can be logged and sampled. A weekly review of a random sample, plus every case the agent flagged as uncertain, gives more real oversight than an approval queue cleared with a keyboard shortcut. Two practical rules:
- Give it the narrowest permissions that let it do the An agent that can draft but not send has a very different risk profile.
- Rate-limit The invoice failure above is contained entirely by a cap of fifty emails an hour.
What are the data protection implications under UK GDPR?
If an agent reads, writes or makes decisions about customer records, you are processing personal data and the usual obligations apply: lawful basis, purpose limitation, minimisation, security and the records you keep about all of it. Take proper advice. What follows is a list of questions, not a legal opinion.
Worth putting to your adviser:
- What personal data does the agent actually see, and is all of it necessary? Agents tend to be handed broad database access because scoping it is more work.
- Where does the processing happen? If the model sits with a provider outside the UK, you have a transfer and a processor relationship to document.
- Is it making decisions with legal or similarly significant effects on an individual, without meaningful human involvement? That is a specific area of the UK GDPR with its own rules.
- Can you explain what it did? Agent logs are usually built for debugging, not for answering a subject access request.
- Does this warrant a data protection impact assessment? New processing of personal data at scale is the standard trigger.
The ICO’s guidance on AI and data protection is free and a better starting point than any vendor’s compliance page. None of this makes agents unusable; it moves the scoping decisions earlier.
What does it cost, and what should you automate first?
Budget for the integration, not the model. Token costs are rarely the problem. The expense is connecting systems, cleaning up the data the agent depends on, and the months of supervision before anyone trusts it. Most businesses should automate a known, repetitive, well-documented process first.
That last point saves the most money. If a process is not written down, an agent cannot follow it, and writing it down often shows the process can be simplified or dropped. Plenty of firms set out to build an agent and ended up with a clearer process and a conventional script instead, rightly.
Three questions settle readiness. Is this done the same way every time? Could a competent new starter follow written instructions and get it right? Is the data it depends on accurate and in one place? Three noes means you are not ready, and no amount of model capability changes that.
Budget for the running cost too. An agent has an owner, a monitoring burden, a change process when upstream systems move, and a bill that scales with usage rather than sitting flat like a licence.
How do you run a trial without committing to anything?
Pick one narrow process, run the agent in shadow mode against real work for a few weeks without letting it act, and compare its output with what your people actually did. If it is not clearly better or clearly faster by the end, you have learned something cheaply.
A sequence that works:
- Choose a process with volume, clear rules and a small blast Invoice matching and email triage are the usual candidates.
- Write the current process down properly first, exceptions included, because the exceptions are where the work is.
- Run it in shadow The agent processes live inputs and records what it would have done. Nothing is sent, posted or paid.
- Measure against the baseline you already have: how long it takes now, how often it is wrong Without that you can only tell whether the agent is impressive, not whether it is good.
- Then give it real permissions, narrowly, with a rate limit and a named owner, on part of the
- Agree in advance what would make you A trial with no failure condition is a procurement decision wearing a lab coat.
Keep it to a few weeks and one process. The firms getting value out of this got there by being boring and specific. The ones that wasted money began with a platform decision rather than a problem.
Key takeaways
- A chatbot answers a An agent takes a goal and acts on it across several steps without being prompted.
- The best early candidates are dull, documented, high-volume back-office processes, not customer-facing experiments.
- The characteristic failure is correct reasoning from a wrong assumption, executed across every record before anyone notices.
- Put the checkpoint at irreversible actions and Approval queues for routine items become rubber stamps within weeks.
- If an agent touches personal data, scope its access narrowly and take advice on your UK GDPR position before go-live rather than after.
Frequently asked questions
Is this the same thing as robotic process automation?
No, though they overlap. RPA follows a fixed script and breaks when a screen or file format changes. An agent can reason about an unfamiliar case and decide what to do, which makes it more flexible and less predictable. For a stable process, conventional automation is often cheaper and easier to defend.
Do we need our own model or our own data?
Not your own model, usually. Most implementations call a commercial model through an API and spend the effort on integration and permissions instead. You do need your own data to be accessible and reasonably accurate, which is where delays come from. Poor data quality is the most common reason these projects stall.
What do we need in-house to run one?
Someone who owns the process and can say definitively what correct looks like, and someone technical who can maintain the integrations and read the logs. The second can be a supplier. The first cannot be outsourced. These projects fail more often from an absent process owner than from a shortage of engineering.
Should a smaller business simply wait?
Waiting costs little in capability terms, since the tooling keeps improving and anything built now will be rebuilt anyway. The preparation is not wasted, though. Documenting processes, cleaning data and tidying up system access all pay for themselves independently. Do that work now and start with one small conventional automation.
None of this is a reason to ignore the category. The underlying shift, software that acts rather than responds, is real, and it will change where administrative work sits. It is a reason to be unimpressed by demonstrations and interested in processes. Start with something you understand well enough to describe on paper, keep a person at the points that matter, and judge the result against what you already do.
About the author
TheGenieLab is a UK-based ecommerce development team that has been building and supporting online retail systems since 2011, with clients across the UK, the US and Australia. The team works on integrations, custom development and the unglamorous operational plumbing that automation projects depend on. More at TheGenieLab.