What Are AI Agents? A Practical Guide for UK Businesses

AI agents are software systems that take in information, decide what to do with it, act, and then adjust based on what happened. That decision step separates them from the automation most businesses already run. A scheduled email goes out because the calendar says so, while an agent sends it because it has read the data, weighed it against an objective, and concluded that now is the moment.

That distinction matters commercially. It changes what you are buying. Automation buys you repetition, and an agent buys you judgement inside a boundary you set, which needs governing in a way repetition never does because the output varies with the input and the same instruction can produce a different action on a Tuesday than it did on a Monday.

The numbers are worth sitting with. Office for National Statistics figures published on 20 July 2026 show how far UK businesses have come, and how far they have not. Among businesses with ten or more employees, AI use rose from around 12 per cent in late 2023 to around 35 per cent by June 2026. Adoption among the smallest firms, those with nought to nine employees, stands at 28 per cent, against 49 per cent for firms with 250 or more. The depth of that adoption tells the more interesting story, and it is the figure most commentary skips. The average adopting business uses around 1.6 AI technologies, up from around 1.4 in late 2023, and only 10 per cent of adopting businesses with ten or more employees describe themselves as using AI extensively.

So most of the market has tried something and almost none of it has gone deep. The gap between those two states has little to do with access to better models, and almost everything to do with implementation discipline. That is the subject of most of this guide.

What an AI agent actually is, and what it is built from

An agent has four things a simpler tool does not. It has an objective where a simpler tool has only a trigger, and it has a view of its environment built from whatever data you connect to it. It has permission to act on that environment through tools you grant, and it has a loop, so the result of one action informs the next.

Strip any of those four away, and you have something else. Remove the objective, and you have a workflow; remove the tools, and you have an analyst writing recommendations nobody actions, and remove the loop, and you have a one-shot generator. The loop is the part people underestimate, largely because it is also the part that drifts once the agent has been running long enough for the inputs to shift under it.

Underneath those four properties sit six components. Vendors name them differently and some bundle two together. Any agent you are shown will have all six, and knowing the names is how you ask a supplier a question they cannot deflect.

Perception inputs and the knowledge base. Perception inputs are the channels through which the agent receives information. A form submission, an inbound email, a webhook from your CRM, a scheduled database query, a document you upload. These are the agent’s senses, and they are also its attack surface, since anything able to send the agent an input can attempt to instruct it as well. The knowledge base is the reference material it reasons against, meaning your price list, your service descriptions, your tone-of-voice document and your past tickets. Most business agents retrieve from that store at the moment of answering instead of having it trained in. The commercial consequence is worth understanding, because it means you correct the agent by editing a document and not by retraining anything.

Memory. Two kinds exist. Suppliers conflate them. Short-term memory is the context of the task in hand. It dies with the task. Long-term memory persists across tasks, so the agent can recall that this customer complained in March. The second kind is where most data protection questions live, and the question to ask a supplier is what is retained, where, and for how long.

The reasoning or planning component. The part that decides what to do. In current systems this is usually a large language model, prompted with the objective, the constraints, the retrieved knowledge and the list of available tools, and asked to choose the next step. It is the least predictable component. Your constraints exist to govern it.

The tool layer, sometimes called actuators. The defined set of actions the agent can take in the outside world. Send an email, write a CRM field, create a draft, run a query, call another system’s API. Every tool is a permission. The set of tools is the hard ceiling on what the agent can do, however it is instructed. This is the single most important thing to see written down before you sign anything.

The orchestrator. The loop itself. It calls the reasoning component, executes the chosen tool, feeds the result back, decides whether the objective is met, and stops or continues. It also enforces the limits, such as the maximum number of steps before the agent gives up and escalates. An agent with no step limit and a vague objective is how a runaway loop and a large bill arrive on the same afternoon. Ask about the step limit.

How AI agents differ from chatbots, AI assistants, automation and machine learning models

These five terms get used as though they were interchangeable. They are not, and the differences decide which one your problem needs. The quickest way to see it is by what each one is allowed to touch.

	Works from	Decides what to do	Acts on your systems	Learns from outcomes
Traditional automation	a rule you wrote	no	yes, within the rule	no
Machine learning model	training data	no, it scores or labels	no	at retraining only
Chatbot	a script or knowledge base	within the conversation	rarely	usually not
AI assistant	your prompt	suggests, you approve	only when you tell it to	not across sessions
AI agent	an objective you set	yes	yes, through granted tools	yes, through its loop

The assistant row is the one most often mislabelled in the market. An assistant waits to be asked. It hands the output back to you, and there it stops. An agent is given an outcome and goes after it across several steps without being prompted at each one. A tool that drafts an email when you ask it to is an assistant. A tool that reads the inbox, decides which enquiries need a reply today, drafts them and queues them for approval is an agent, and it needs the governance in the second half of this guide where the assistant does not.

Chatbots respond, and most follow a script or a decision tree, and the good ones now use a language model to interpret what was said before picking a reply. The scope is a conversation, so a chatbot does not go away, query your stock system, place an order and come back, whereas an agent can do exactly that when you have granted it the tools and the permission to act on them.

AI assistants suggest. They sit beside a person, take an instruction, produce a draft or an answer, and stop. The work stays on your desk and nothing reaches a customer or a record unless you move it there. Most of what businesses have bought since 2023 and called AI is an assistant. That is also why so much of it has produced a time saving and no change to any business outcome.

Traditional automation executes. A rule fires and a step runs, the same way every time. This is the right tool for anything where the correct action is fully knowable in advance, and for those tasks it is cheaper to run, faster to execute and more predictable in its behaviour than any agent you could put in its place. Replacing automation that already works with an agent is a common and expensive mistake, and it usually happens because somebody wanted to be able to say the business was using AI.

Machine learning models predict. A churn model scores a customer and a classifier sorts an enquiry. The output is a number or a label, and something else has to decide what to do with it. Agents frequently contain models and call them the way you would call a colleague for an opinion, taking the answer as one input to a decision that still has to be made.

Agents decide and act. They sit above the other three, using models to interpret, tools to execute, and a loop to improve. The cost of that capability is that the output is not fully predictable, so the controls have to come from the boundary you draw and not from the code path.

A practical test runs as follows. If you can write down every correct action in advance, use automation; if you need a number predicted, use a model; and if you need a conversation handled, use a chatbot. Where the task needs someone to weigh several imperfect inputs and then choose between them, that is agent territory, and taking it on means accepting accountability for how the choice gets made on every occasion the agent makes it.

How AI agents work

Most agent architectures, whatever the vendor calls them, do five things in sequence.

Perception. The agent gathers input. For a marketing agent that typically means CRM records, website analytics, ad platform data, inbound messages, and whatever documents you give it as reference. Everything downstream is capped at this layer, and no amount of sophistication further along will lift it above what the input data can support. An agent reading stale, duplicated or incomplete data will make confident decisions on a false picture. Nothing downstream catches it.

Two questions settle whether this layer is sound. Is every source the agent reads the system of record for that information, or is one of them a copy somebody exports monthly? And does the agent know when a source is missing, so that an empty result reads as empty instead of as nothing to worry about? A surprising share of agent errors trace to a query that returned no rows and an agent that treated that as a clean bill of health.

Interpretation. Raw input becomes something the agent can reason over. Text is parsed, records are matched, a question is classified, a customer is placed in context. This is where most language model work happens. It is also where most silent errors begin, because an agent that misreads intent proceeds as though it had read intent correctly.

The failure here is specific and worth recognising. An enquiry that says “I still have not had the part you promised” can be read as a status request or as a complaint, and those two readings route to different people, carry different urgency and need a different tone. Nothing in the agent’s output will tell you which reading it took. You find out by sampling, and the grading described later is the only control that catches this class of error.

Decision. Here the agent weighs its options against its objective and its constraints. A well-built agent has explicit constraints at this point, covering budget, tone, what it may not say, and when it must stop and ask. A poorly built one has an objective and little else. It will pursue that objective through actions you would never have authorised.

Constraints have to be written as concretely as the objective, and the test of a good constraint is that two people reading it would block the same action. “Stay on brand” fails that test. “Do not mention a competitor by name, do not quote a price that is not in the price list, and do not promise a date” passes it. Where the platform exposes a confidence score, the threshold below which the agent stops belongs here too, written down with the number in it.

Action. Now the agent uses a tool to send, draft, tag, update, query or schedule. Each tool is a permission you granted, and the set of tools defines the outer limit of what can go wrong. Safety is won or lost at this layer, long before anybody writes the instructions, so it deserves more design attention than the instructions get.

Design the tools narrowly and the instructions matter less. A send-email tool restricted to one sender address and to recipients already in the CRM cannot email a journalist, whatever a clever input persuades the agent to attempt. A publish tool that can only create drafts cannot put anything on your website. Narrow tools turn a problem that would otherwise need careful instruction into one that cannot arise at all. Build the cage before you write the instructions.

Learning. Finally the agent, or more often the team around it, compares what happened to what was intended and adjusts. Some platforms do this automatically within a single session, and a smaller number do it across weeks in a way you can actually audit after the fact. In practice the durable learning loop is a human one, run on a schedule, and the section on monitoring below sets out how.

Be sceptical of any supplier describing a system that improves itself without anybody looking. Within one task, an agent can retry a failed step and do better, and that is real. Across months, improvement comes from somebody reading the corrections, working out the cause and changing the instructions, the data or the boundary. That is a management activity with a cost attached, and a proposal that leaves it out has left out the running cost of the thing being proposed.

Types of AI agents

Two classifications are in common use. The academic one sorts agents by how much they remember and how far ahead they reason, while the commercial one sorts them by the job they do, and the second is usually the more useful lens when you are deciding what to buy.

By capability

Five established categories, in order of how much the agent holds in its head.

Simple reflex agents map an input straight to an action with no memory of anything before it. A rule that tags every enquiry containing the word “boiler” as a heating lead is a reflex agent. They are fast, cheap and wholly predictable. They fail whenever the right action depends on context they cannot see.

Model-based agents hold a picture of their environment, so they can act on things they cannot currently observe. An agent that knows this customer has an open complaint, even though the current message does not mention it, is working from a model. Memory and the knowledge base begin to matter at this point, and so does the cost of keeping them current.

Goal-based agents plan towards an outcome and will take several steps to get there, choosing between routes. Given “get this enquiry to the right person with a summary”, a goal-based agent decides the order of operations itself.

Utility-based agents go further and weigh competing goals against each other. Speed against accuracy, cost against thoroughness, a fast reply against a complete one. These need you to have said what matters more. An agent asked to maximise two things at once will quietly pick one.

Learning agents sit across all four, adjusting from the results of what they did. The caution from the previous section applies, since durable learning in a business deployment is mostly a human review loop and not something the software does on its own.

That taxonomy predates the current wave of tools by decades and is still the clearest way to ask what one actually does.

Two patterns above the categories

Hierarchical agents. One agent supervises others. A coordinator takes the overall objective, breaks it into parts, hands each to a specialist agent and assembles the result. For a content workflow that might be a coordinator, a research agent, a drafting agent and a compliance checker. The pattern buys specialisation and clearer diagnosis, since you can see which layer produced the wrong output. It costs you a new failure mode, because a coordinator working from a sub-agent’s wrong answer compounds the error instead of catching it.

Multi-agent systems. Several agents operating as peers, passing work between them, sometimes across organisational boundaries. This is where the market is heading and where the governance questions get genuinely hard, because an agent that calls another company’s agent has taken an action on your behalf through a system you cannot inspect, log or stop. If a supplier proposes this, the questions are what their agents are permitted to call, whose logs record it, and who carries liability when one of those calls goes wrong.

The two categories that are not products

You will also see “theory of mind” and “self-aware” agents described in vendor material and in academic roadmaps. Theory-of-mind agents would model the beliefs and intentions of the people they deal with, and self-aware agents would hold a model of themselves. Both sit on a long-term research roadmap. Sentiment analysis, which does exist and works reasonably, is not theory of mind, and any supplier presenting either category as shipping capability is overselling. Gartner has a term for the wider version of this, “agent washing”, and estimates that only about 130 of the thousands of vendors marketing agentic AI are genuine.

By function, the agents a marketing team will meet fall into a handful of groups. Research agents gather and summarise, content agents draft, and analytics agents query data and report. Triage agents sort and route inbound work, customer-facing agents answer enquiries directly, and operations agents move records between systems. That functional split matters more than the academic one, because commercial risk is distributed very unevenly across it and the pricing rarely reflects that. A research agent that gets something wrong wastes an hour of somebody’s time and the error is caught by the person reading it. A customer-facing agent that gets something wrong does it in front of your customer, in writing, at scale.

What AI agents are used for, by sector

Marketing is where this guide concentrates, because it is the work we do. The pattern holds across sectors though, and seeing it elsewhere makes the selection rule clearer, so the sectors where agents are furthest along come first.

Customer service. The largest deployment area and the one with the clearest economics. Agents classify incoming contacts, retrieve the relevant account and policy information, answer the routine questions and hand the rest to a person with the context already assembled. The work is high in volume and repetitive, a correct answer is usually knowable in advance, and the hand-off to a human sits at a natural boundary. It also carries the most public failures of any sector, because a wrong answer goes straight to the customer in writing.

Financial services. Agents handle application intake, gather the supporting documents, run the checks and prepare a file for a human decision. Volume is high and the rules are written down. The compliance requirement forces exactly the logging and approval discipline this guide recommends. Note that a decision about a person’s credit is exactly the case where the UK GDPR rules on automated decisions apply, so the human route is a legal requirement and not a design preference.

Retail and e-commerce. Agents reconcile stock across channels, answer order and delivery questions, flag pricing errors and assemble merchandising reports. Product data is structured and the questions repeat. Most of the work happens behind the customer and not in front of them.

Healthcare administration. Appointment coordination, referral routing, records retrieval and correspondence drafting. The administrative layer only, and deliberately so. The constraint is severe and appropriate. Anything touching a clinical decision carries a different risk profile and a different regulatory regime.

Software development. Agents write first-pass code, run tests, triage incoming bug reports and raise pull requests for review. This is the sector where agent use has moved fastest, partly because the output is testable automatically. No other sector has that luxury.

Business process and back office. Invoice matching, data reconciliation between systems, report assembly, supplier onboarding. Dull, high in volume, and frequently the best first candidate in any business, because an error there is both visible and cheap to put right. If you are choosing between an impressive customer-facing pilot and a boring back-office one, the boring one will teach you more and cost you less when it goes wrong, and it will still be running in a year.

Where agents earn their place in marketing

This is the part we can speak to from the work.

Honest answer, the list is short. The tasks agents reliably do well share a profile, and most vendor pages pad well past it. They are repetitive, they have a clear correct answer, and a mistake is cheap and visible.

Inbound triage sits at the top, because reading enquiries, classifying them, tagging them in the CRM and routing them to the right person is high volume, rule-bound and easy to check. Reporting comes next, and an agent that pulls the weekly numbers from four platforms into one summary saves a real half-day while doing little damage when it errs.

First-draft content works when a reviewer is attached to it, because agents are competent at structure and poor at judgement about what is true, so the pattern that holds over time is that the agent drafts and a named person signs off before anything is published. Search and competitor research works on the same basis, with the agent gathering and a person judging. Campaign monitoring works well too, because spotting that a cost per enquiry has moved is a detection job, and the decision about what to do next can stay with a person.

Further out, the uses that need more care include anything priced, anything promised, and anything that reaches a customer without a person having read it first. None of those is impossible, and each needs the approval rules set out below before it goes anywhere near a customer. Most businesses are better off earning their way to that point over two or three deployments than beginning there on the strength of a supplier’s demonstration.

What businesses actually gain

Four gains show up consistently. Two commonly claimed gains do not.

Time on bounded work. The clearest return is hours moved off the tasks nobody in the team wanted to do. You can measure it before and after with a stopwatch and a spreadsheet, and it is the only benefit you should be asked to pay for in a first deployment.

Speed of response. Often larger in value than the time saved. Agents do not queue, so for inbound enquiry handling, where the speed of a first reply correlates with conversion in most sales processes, the gain is worth more to the business than the labour.

Consistency. An agent applies the same standard at 7am and 7pm. For triage, tagging and reporting that removes a class of error busy teams make under pressure at the end of a month, and which training alone rarely fixes.

Capacity without headcount, at the margin. The honest version of the scaling claim. An agent absorbs a volume spike in triage or reporting without anybody working a weekend. It does not absorb a spike in the work that needed judgement. That work still arrives at the reviewer, and the reviewer is now the constraint. Businesses that plan for the first and forget the second end up with a faster queue into the same bottleneck.

The gain that does not reliably appear is quality. Agents produce competent work at volume. Competent and better are different things. The ONS depth figures cited above are consistent with this, since businesses are adding one or two tools, taking the efficiency and stopping. Anyone promising transformation from a first deployment is selling the exception as the rule, so ask them for the median result across their last ten clients.

The second absent gain is cost reduction, at least early. A first deployment usually costs more in the first year than the work it replaced, once you count the platform fee, the build, the data clean-up and the reviewer’s time. Gartner’s forecast of 25 June 2025 puts “escalating costs” first among its three reasons for expecting over 40 per cent of agentic AI projects to be cancelled by the end of 2027, ahead of unclear business value and inadequate risk controls. The saving, where it comes at all, arrives in year two from a process that has been simplified. A business case promising it in month three was written by somebody who has not done this.

What this looks like in practice

Three patterns recur across the deployments that work, described here as patterns because the figures from individual client engagements are commercially confidential and would need the client’s agreement before publication.

An inbound enquiry agent reads every form submission and email, classifies it by service and urgency, writes a summary into the CRM, and either drafts a reply for approval or flags it for a person. The business gets faster first replies. It also gets a clean record of every enquiry, which it did not have before. The risk stays low throughout, because nothing reaches the customer unread during the first phase of the deployment and the reviewer sees every item.

A reporting agent pulls the weekly numbers from the ad platforms, Search Console and analytics, writes a one-page summary against the targets, and names what moved and by how much. It saves a recurring half-day every week. The failure mode is a wrong number sitting in a report that nobody checks, so the data sources are validated against the platforms they came from before the agent is trusted to assemble them unsupervised.

A content research agent gathers sources on a topic, extracts the claims with citations, and hands a researcher a sourced brief. Its value sits entirely in the hours before writing. Most of the unbilled time in content production goes there. The control is that every claim keeps its source, so the person writing can verify every line instead of trusting it.

An implementation roadmap for AI agents

Most agent deployments fail before any code is written. The failure happens when someone picks a task because it sounds impressive instead of because it is bounded, repetitive and measurable. Below is the order we use with clients. It runs from choosing the use case to the first post-launch review, and each stage has an exit condition. If the condition is not met, the project waits.

Stage one, use-case selection. List the tasks your team does weekly that are rule-bound, high-volume and low-consequence when they go wrong. Answering routine enquiries, drafting first-pass social copy, tagging inbound leads, pulling a weekly performance summary. Score each against three questions, namely how often it happens, how clear a correct result is, and what the worst outcome of a wrong result would be. Pick the task that scores highest on the first two and lowest on the third, and resist the pull of the more glamorous candidate further down the list. Exit condition is a one-page brief naming the task, the inputs, the output, the owner and the measure of success.

Stage two, pilot design. Decide what the agent may do on its own, what it must hand to a person, and what it must never touch. Write the instructions the agent will run on, in plain English, and have the task owner read them back. Set the pilot boundary small, which for most agencies means one channel, one client, one workflow and two to four weeks. Agree the numbers you will compare before and after, such as response time, hours saved, error rate and the number of items a person had to correct. Exit condition is a signed-off pilot brief with those numbers and a named person who will review the agent’s output every day of the pilot.

Stage three, integration. Connect the agent to the systems it needs and nothing else. If it drafts emails it needs a mailbox with send disabled, a template library and read access to the CRM. It needs none of the rest. No admin rights, no payment access, no ability to delete records. Use separate credentials for the agent so its actions can be told apart from a person’s in every log, which matters the first time something goes wrong and somebody asks who did it. Exit condition is a written list of every system the agent can reach, what it can do in each, and who approved that access.

Stage four, testing. The section on testing below sets this out in detail. In short, the agent runs against real historical cases in a sandbox, a person checks a sample of its outputs, the edge cases are deliberately fed in, and nothing goes live until the failure rate is known and accepted. Exit condition is a test record showing what was tested, what failed, and what was changed.

Stage five, launch. Go live on the pilot boundary only, with the daily review in place and a kill switch that any team member can use. Tell the people affected, inside the business and outside it, that an automated system is now involved in the process and exactly how they reach a person instead. Exit condition is the end of the pilot period with the before-and-after numbers in hand.

Stage six, post-launch iteration. Compare the numbers to the pilot brief, then review every correction a person made and ask whether the instructions, the data or the boundary caused it. Fix what can be fixed, then decide whether to widen the boundary, hold it, or stop, using the method set out under iterative improvement. Then the loop runs again on the next use case, and that one moves faster because the access list, the test method and the review habit already exist from the first.

Testing and validating agents before production

Nothing goes live on a demo.

Demos use clean inputs and happy paths, while production uses whatever the world sends, and validation is the stage where you find out what the agent does with the rest.

Sandbox first. Run the agent in an environment where its actions have no effect. Outbound email goes to a test inbox, CRM writes go to a copy of the database, published content lands in a draft folder. Feed it real historical cases, ideally a few hundred drawn from the last six months, so that it meets the actual spread of inputs the task produces.

Grade a sample by hand. Take at least fifty outputs, more if the task is customer-facing, and have the task owner mark each one as acceptable, needs a small edit, or wrong. Record the reason for every mark that is not acceptable. This gives you a baseline error rate and, more usefully, a catalogue of the specific ways this agent gets things wrong. Most of those ways turn out to be instruction problems and can be fixed in an afternoon by somebody who understands the task properly.

Feed it the edge cases deliberately. Build a short set of inputs designed to trip it. An angry customer, a message in a second language, a request that is outside its remit, a prompt that tries to make it reveal its instructions, an empty input, a duplicate, a request that would commit money. The agent should pause, refuse or escalate on every one of them. No exceptions apply. If it ploughs on through any of them, the boundary rules are not working and the launch waits until they do.

Check the behaviour under load and failure. What happens when the CRM is unreachable, the model times out, or two hundred requests arrive at once? The acceptable answer is that the agent fails safely, logs the failure, and tells a person, and the only way to know is to switch things off and watch.

Stage the rollout. Even after the sandbox, go live on a slice. Ten per cent of inbound enquiries, one client, one campaign, with a person reading everything the agent produces for the first fortnight. Widen the slice only when the correction rate in production matches what the sandbox predicted. Not a week before. If production is worse than the sandbox, the test cases were not representative, and the fix is better test data ahead of a bigger rollout.

Write it down. Keep the test set, the graded sample and the results. You will reuse the test set every time the instructions change or the vendor updates the model, so the same cases are run again and any regression shows immediately.

Operational set-up for safe deployment

Most of what keeps an agent safe is decided in the set-up, before any instruction is written. An agent cannot leak what it cannot read. It cannot delete what it cannot write, and it cannot spend what it cannot reach.

Access permissions. Give the agent its own identity in every system it touches, with the narrowest permissions that let it do the task, and read-only access wherever that is enough. No shared logins with staff, no reuse of a director’s credentials, no standing admin rights. Review the access list quarterly and whenever the task changes, and remove anything the agent has not used.

Tool restrictions. Give the agent a fixed list of tools it may call, each with its own limits. A send-email tool that can only send from one address to addresses already in the CRM. A publish tool that can only create drafts. A data tool that can query but not export. Where the platform allows it, set hard caps on volume per hour and per day. A runaway loop then stops itself.

Action boundaries. Separate what the agent may do on its own from what it must propose. For a new deployment, the safe default is that the agent prepares and a person releases. Autonomy is extended one action type at a time, after monitoring shows the correction rate for that action type is acceptable. Write the current boundary down and date it. A reviewer will ask for it first.

Record keeping. Three records matter, the first being the instruction history, so you know what the agent was told on any given day. Then the action log, so you know what it did, and the approval log, so you know who signed off what. Keep them for as long as your data retention policy keeps the underlying records, and make sure they are included in your UK GDPR processing records, because an agent handling personal data is processing it on your behalf.

Disclosure and the off switch. Tell people when they are dealing with an automated system and how to reach a person, putting it in the agent’s first message, on the page where the agent runs, and in your privacy notice. For customer-facing agents this is good practice now and increasingly a legal expectation. Separately, every agent needs a documented way to stop it in under a minute that does not depend on the person who built it being available. Test that during the pilot, because an agent you cannot stop is not under control, whatever the instructions say.

Governance, approval and escalation rules

“Human oversight” is a phrase, not a control. It means nothing until it is written down as rules the agent follows and a person can audit. Three questions settle most of it, namely when the agent must stop and ask, what it may never do without a named person’s sign-off, and what happens when it is unsure.

When the agent pauses for approval. Set pause triggers before launch and keep them in the agent’s instructions where a reviewer can read them. Sensible defaults for a marketing agent are any action that commits money, any message to a customer about a complaint, refund, legal matter or safety issue, any change to published pricing, and any content that names a real person or a competitor. Add any task where the agent’s own confidence score, where the platform exposes one, falls below the threshold you set. A paused task goes into a queue with the agent’s proposed action and its reasoning. A person then approves, edits or rejects it.

What always needs sign-off. Some actions are never delegated. Confidence does not come into it. That list includes sending anything to a regulator, the press or a client’s customers on the client’s behalf, deleting or exporting personal data, changing the agent’s own instructions or permissions, and making any claim about results, prices, qualifications or guarantees. UK law backs this up, because since 5 February 2026 the Data (Use and Access) Act 2025 has replaced Article 22 of the UK GDPR with Articles 22A to 22D. Where a significant decision about a person is made solely by automated processing, Article 22C requires the controller to give the person information about the decision, let them make representations, let them obtain human intervention, and let them contest it. If your agent makes decisions of that kind about individuals, the human route is a legal duty, not only a policy choice.

How escalation works. Escalation has to be a route somebody owns. Name the first reviewer and a deputy, and set a response time for the queue, such as within two working hours for customer-facing items. Give the agent a fixed fallback for when nobody answers in time, which for most tasks means hold and notify, and for anything customer-facing means send a holding reply that says a person will respond. Log every escalation with the trigger, the time, who reviewed it and what they decided. That log is the evidence you will need on the day a client, an auditor or an insurer asks how the system is controlled, and it cannot be assembled retrospectively.

Who owns the rules. One person owns the agent’s instructions and permissions and is the only one who changes them. Changes are dated and kept, so you can see what the agent was told on the day a given output was produced. The NIST AI Risk Management Framework (version 1.0, January 2023) and ISO/IEC 42001:2023 both treat this kind of documented accountability as a core control. You need not adopt either standard in full to borrow the discipline that sits behind them.

Monitoring and performance review after deployment

An agent that worked in the pilot will drift. The inputs change, the business changes, and the model behind it is updated by its vendor. Instructions that were right in March are wrong by September. Monitoring is how you notice before a customer does.

Log everything the agent does. Every input it received, every action it took, every output it produced, every tool it called, every time it paused and why, with a timestamp and the version of its instructions in force at the time. Logs go to a store the agent cannot edit, because a record the system under review can rewrite is not a record. Without that record you cannot investigate a complaint, prove a decision was reviewed, or tell whether a bad outcome came from the agent or from the data. The log is the evidence.

Review on a fixed cadence. Daily during the pilot, weekly for the first quarter, then monthly is a cadence that suits most agency deployments. The review has three parts, and the first is to sample the outputs and grade them against the brief; twenty items a week is enough for most marketing tasks. Read every item a person corrected or rejected and sort the causes into instruction gaps, data problems and boundary problems. Then check the headline numbers from the pilot brief, which for a marketing agent are typically volume handled, time to completion, correction rate, escalation rate and the business outcome the task was meant to move, such as reply rate or lead quality.

Watch for failure patterns. One wrong output is noise, while the same wrong output three weeks running is a pattern, and patterns have causes you can fix. Keep a short running list of known failure types with the fix applied and the date. If the correction rate rises for two reviews in a row, pause expansion until the cause is found.

Test whether it still meets the objective. Every quarter, ask the original question again. Is the task still worth automating, is the agent still the right way to do it, and would a person starting today design it the same way? Agents accumulate exceptions and patches over time, and when the instructions have doubled in length since launch, it is time to rewrite them from the brief instead of adding another clause.

Report upward in plain numbers. The monthly agent report fits on one page. What it handled, what it got wrong, what was changed, what it cost, what it saved, and what you recommend. If the agent is not paying its way, say so and stop it.

Iterative improvement after launch

Launch is the midpoint of the work and not the end of it. The agent that goes live is the worst version of itself you will ever run, because it has only ever seen test data. What happens after launch is what turns it into something the business relies on.

Run the feedback loop on a schedule. Every monitoring review produces a list of corrections and their causes. Each cause becomes a change to the instructions, the data, the tools or the boundary. Batch the changes, test them against the saved test set built during validation, record the version number and what changed, and only then release. Weekly in the first quarter and monthly after that is enough for most deployments, and ad hoc changes made in the moment are how instructions become unreadable.

Read the logs for what people are asking. Inputs the agent sees are a live record of what customers and staff actually want. Requests the agent keeps escalating because they are outside its remit are candidates for the next use case. Requests it handles well that nobody expected it to handle are evidence for widening the boundary, and they are the cheapest expansion you will find.

Update the instructions as well as the examples. When a correction keeps recurring, the fix is a clearer rule in the brief instead of another worked example bolted on. Rewrite the instructions from scratch whenever they have grown past the point where a new team member could read them in ten minutes and explain what the agent does.

Refresh the data. Agents that draw on a knowledge base, a product catalogue or a set of templates go stale as fast as those sources do. Put the refresh on the same calendar as the content it depends on, so that nobody has to remember it separately. If prices change quarterly, the agent’s price data is checked quarterly. If the vendor behind the model releases a new version, re-run the test set before switching, because behaviour changes between versions and not always for the better.

Refine the workflow around the agent. Biggest gains after launch often come from changing what happens before and after the agent, outside the agent itself. Cleaner inbound data, a better hand-off to the person who reviews the queue, a template the agent can fill instead of free text. Treat the agent as one step in a process and improve the process.

Decide, every quarter, whether to keep it. The three options are expand, hold or retire. Expansion means a wider boundary or a second use case, and it earns its place with numbers from the monthly report. Retirement is a legitimate outcome. Some tasks turn out to be cheaper to do by hand, and an agent that established that has paid for itself.

Where AI agents fail

The failure modes are under-reported, because most published material on agents is written by people selling them.

These are the ones that actually cause damage, in rough order of how often they appear.

Confident wrong answers. An agent that has misread a situation does not hesitate. It proceeds in the same tone as an agent that has read it correctly, and the output looks finished. This is why sampling and grading matter more than any other control. You cannot spot these by watching the agent work, only by checking what it produced.

Objective drift in practice. Give an agent a target and it will pursue the target, including through routes you would have ruled out had anyone asked you. An agent told to raise reply rates may start writing subject lines that overpromise. The objective was met and the brand paid for it. Write the constraints as explicitly as you wrote the objective.

Silent degradation. Your vendor updates the model behind your agent without telling you. Your data changes shape and a template gets edited. Performance falls gradually and, because nobody is grading samples against the brief, the first signal that anything has moved is a complaint from a customer or a client. Monitoring on a fixed cadence is the only defence that works here.

Permission creep. Agents accumulate access over time, because a credential granted for one task stays in place long after the task has changed, and the blast radius grows quietly while nobody is looking at it. Quarterly access reviews exist for this reason and take about an hour.

Automation of a broken process. An agent applied to a process that did not work will do the broken thing faster and more consistently. This is the most common waste in the market. It is a process problem wearing a technology costume.

Gartner’s account of why agentic AI projects get cancelled names three causes, escalating costs, unclear business value and inadequate risk controls, and all three are versions of one mistake. Nobody established what the agent was for in terms anybody could measure, so the cost had nothing to be weighed against.

Data protection exposure. An agent reading customer records is processing personal data, and the obligations that attach to that do not soften because software is doing the reading. Access scope, retention, disclosure and the human route under Articles 22A to 22D all apply.

Team resistance earned honestly. Staff resist agents for good reasons. They were introduced without explanation, they made the work harder, or they arrived as a prelude to redundancy. Where that is the actual plan, saying otherwise is a short-lived strategy. Where it is not, saying so clearly, early, and with the reasoning, prevents most of the problem.

The future of AI agents

Forecasting is cheap, so here is the narrow version.

So the useful version of this section stays narrow, and five things look reasonably well evidenced at the time of writing.

Agents are about to arrive inside software you already pay for. Gartner’s forecast of June 2025 puts 33 per cent of enterprise software applications including agentic AI by 2028, against under 1 per cent in 2024. The same release expects at least 15 per cent of day-to-day work decisions to be made autonomously by 2028, from a baseline of nought in 2024. Treat the precise figures as a vendor-facing forecast. They are not a measurement. The direction is the useful part, and the practical consequence is that most businesses will acquire their first agent by renewing a subscription instead of by running a procurement. So the governance in this guide needs to exist before anybody decides to buy anything, because the decision may already have been taken upstream of whoever would normally make it.

Multi-agent work is arriving ahead of the governance for it. Agents that call other agents, including ones outside your organisation, raise accountability questions no standard contract currently answers. Anybody buying agent capability over the next two years should ask, in writing, what their supplier’s agents are permitted to call, whose logs record those calls, and who carries liability when one of them goes wrong.

A shake-out looks more likely than a smooth adoption curve. Gartner expects over 40 per cent of agentic AI projects to be cancelled by the end of 2027, and estimates that only about 130 of the thousands of vendors marketing agentic AI are genuine. If that proves roughly right, many of the tools being sold today will not exist in three years. The defence is portability. Keep your data and your process movable, and treat any single supplier’s platform as replaceable.

Regulation is tightening ahead of capability in the UK. The replacement of Article 22 with Articles 22A to 22D took effect on 5 February 2026, and the Secretary of State holds reserve powers under Article 22D to add further safeguards by regulation. Businesses building agents that make decisions about individuals are building into a moving compliance picture, and the sensible response is to over-document now.

The durable advantage is unlikely to be the agent. Everyone can buy the same models at much the same price. What differs between businesses is the quality of the data an agent reads, the clarity of the process it sits inside, and whether anyone has the discipline to measure it honestly and switch it off when it stops paying. Those are management capabilities, and they were in short supply long before anybody deployed an agent.

Three things the forecasts probably have wrong

Worth saying, because the optimistic version of this section is available on every other page covering this subject.

Full autonomy is not the destination for most business tasks. The pitch is usually that human review is a transitional cost on the way to agents that run unattended. For work where a mistake reaches a customer, carries a price or touches personal data, review is the control that makes the work permissible in the first place, and the UK rules on automated decisions about individuals now say so in law. Expect the review step to get cheaper and faster. Do not plan for it to disappear.

The bottleneck will move to the reviewer, and nobody is budgeting for that. Every forecast counts the work agents will absorb. None of them counts the volume of approvals, escalations and sampled outputs that lands on one named person once several agents are running. That person becomes the constraint on the whole system, and the business that plans for it will get further than the business that buys three more agents.

Most of the gain will go to businesses with tidy data, and that is not the same group as the early adopters. Nothing in this technology fixes a messy CRM, a price list that lives in four places or a process nobody has written down. The ONS finding that adoption nearly trebled while depth barely moved is consistent with a lot of businesses hitting that wall and stopping.

The ONS depth figures are the signal worth watching locally. When the average adopting business moves meaningfully above 1.6 technologies and the share using AI extensively rises above 10 per cent, the market will have started to do this properly. The next ONS release is the place to check.

Getting started

Three steps, in order. None of them involves buying anything yet.

Write down the five tasks your team repeats most often this week, with how long each takes and what happens when one goes wrong. Pick the one that is highest volume and lowest consequence. Then run it as a two-to-four-week pilot against the roadmap above, with one named reviewer and the before-and-after numbers agreed in advance.

If the pilot pays for itself, widen the boundary. If it does not, you have spent a month and learned where the real constraint sits. In most businesses that constraint is the data or the process, and not the technology.

Constellation Marketing Solutions runs this process with clients across the Northwest. If you want a view on whether a specific task in your business is a sensible first candidate, book a call and we will tell you, including when the answer is that it is not.

Frequently asked questions

What is an AI agent in plain terms? An AI agent is software that is given an objective, reads data about its situation, decides what to do, acts using tools you have granted it, and adjusts based on the result. The decision step is what separates it from automation, which executes the same steps every time.

How are AI agents different from chatbots? A chatbot handles a conversation and usually follows a script or answers from a knowledge base. An agent can take actions outside the conversation, such as updating a record, querying a system or drafting an email, and it chooses which action to take against an objective.

Do AI agents replace marketing staff? In the deployments that work, agents take bounded, repetitive tasks and the people move to work that needs judgement. The agents that produce finished customer-facing work unsupervised are rare, because the correction rate is still too high to leave unchecked.

How long does an AI agent take to set up, and what does it cost? A first pilot on a well-chosen task runs in two to four weeks including testing. Choosing the task and cleaning its data takes longer than building the agent. Costs fall into platform fees, the build, and the review time of whoever checks the output. The third is usually left out of the business case and is frequently the largest.

Are AI agents safe to use with customer data? They can be, when access is scoped to the task, actions are logged where the agent cannot edit them, and the processing is recorded in your UK GDPR records. Where an agent makes a significant decision about an individual solely by automated means, Article 22C requires you to inform the person, let them make representations, give them human intervention, and let them contest it.

What is the most common reason AI agent projects fail? Choosing the wrong first task. Projects that pick an impressive use case over a bounded one fail in testing or soon after launch, because nobody defined the correct answer clearly enough to check against. Gartner expects over 40 per cent of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.

What are the main types of AI agent? Five by capability. Simple reflex, model-based, goal-based, utility-based, and learning agents sitting across all four. Two patterns sit above them, hierarchical agents where one supervises others, and multi-agent systems where several work as peers. Theory-of-mind and self-aware agents are research categories, not products.

How do I know whether my AI agent is still working? Grade a sample against the brief on a fixed cadence. Track the share of items a person had to correct, and compare the headline numbers to the ones agreed before launch. A rising correction rate across two consecutive reviews is the signal to pause and investigate.

About the author

Christopher Welford is a Chartered Marketer and the founder of Constellation Marketing Solutions, a Liverpool marketing agency working with owner-managed businesses across the Northwest. He is a Fellow of the Chartered Institute of Marketing and a Professional Member of BCS, the Chartered Institute for IT, and has worked in marketing for more than twenty years.

He is a founding director of Launchpad Futures CIC and co-founded Launchpad Magazine. In 2026 he completed the Google AI Professional Certificate and Adobe’s Generative AI Content Creation certification. He is separately developing Aratus.ai, a voice AI venture.

Constellation Marketing Solutions is registered in England and Wales, company number 14407922.