← All articles
Bigger Questions · 8 June 2026 · 6 min read

Who Answers for an AI Agent's Mistake?

An agent sends a refund to the wrong customer. Or it books a job for the wrong Tuesday and nobody notices until the van turns up. Or it answers a complaint with a confident, friend…

Human hand signing for a machine-produced decision card at a clearly defined responsibility desk

An agent sends a refund to the wrong customer. Or it books a job for the wrong Tuesday and nobody notices until the van turns up. Or it answers a complaint with a confident, friendly, completely made-up promise. Whatever the detail, there is a moment afterwards where someone has to explain what happened, and the most tempting sentence in the world is "the system decided".

It is tempting because it is half true. The software did choose. But "the system decided" is not a sentence you can say to a customer who is out of pocket, and it does not hold up anywhere that counts. Someone in the business is still answerable. The real question is not whether that is true. It is who, exactly, and whether you decided that on purpose or are about to find out under pressure.

The business remains accountable for AI decisions

For all the noise about AI being a legal grey area, the part that matters to a small business is not grey at all.

Under English law an AI system has no legal personality. It cannot hold responsibility, it cannot be sued, and it cannot be the thing that is at fault. That is not a loophole waiting to be closed; it is the starting point. When an agent acts, responsibility does not land on the software. It lands on the people and the business that set it running.

The Competition and Markets Authority put the consumer-facing version of this plainly earlier this year: a business is responsible for how it treats its customers whether it does so through people or through AI. The same rules about being fair, not misleading, and putting things right apply either way. Switching a task to an agent does not move the duty. If anything it concentrates it, because now one decision you made, to let the software act, sits behind a great many actions.

The finer points are still being worked through. The UK Jurisdiction Taskforce ran a consultation at the start of 2026 on exactly how existing negligence and contract law should apply to AI harms, which tells you the courts will mostly be extending principles they already have rather than inventing new ones. But the headline for an owner is steady: you cannot buy a tool that takes the responsibility off your hands, because no such tool can exist.

Permission is not the same as authorisation

There is one genuinely unsettled wrinkle, and it is worth understanding because it shows how slippery "who said yes" can get.

This year Amazon won a court order blocking Perplexity's AI browser from shopping inside customers' Amazon accounts. The customer had told the agent to go ahead. The point the court found persuasive was that the customer's permission is not the same as Amazon's authorisation: letting an agent act on your behalf does not automatically mean the place it acts is happy to be acted in. The order has since been paused while the case is appealed, so this is live, not decided.

You may never run an agent that touches someone else's platform. But the underlying lesson travels. When an agent acts, more than one party can have a stake in whether it was allowed to: the person who asked, the business running the agent, and whoever owns the system it reaches into. "Someone approved this" can quietly mean three different people. If you have not decided which approval counts, you have not decided who is accountable either.

Ownership often fails inside the business

So if the law is reasonably clear, why does accountability still go fuzzy in practice?

Because the fuzziness is not in the law. It is in who does what. Accountability goes vague when nobody was named before the agent was switched on. The work was quietly handed to software, the person who used to do it moved on to other things, and the question of who answers for the output was never actually asked. Then something goes wrong, and the business discovers it has automated the task but not the responsibility for the task, and those are not the same thing.

This is the bit a demo will never show you. A demo shows the agent doing the work well. It does not show the Tuesday it does the work wrong, and it certainly does not show who has to ring the customer afterwards. The distance between "the agent can do this" and "someone is answerable for it" is exactly the distance that decides whether an agent is a business system or a liability with good manners.

A named owner sets limits and reviews incidents

Naming an owner is not a paperwork exercise. In practice it means three concrete things, and they map neatly onto how much you should trust the agent to act alone.

A named person. Not "the team", not "the tool", a person who answers for each kind of action the agent can take. The owner of "drafts a reply" can be different from the owner of "sends the reply" or "issues the refund". Sorting actions by who answers for them is most of the work.

Informed. The owner can see what the agent did, when, and on whose say-so, after the fact and without a forensic dig. This is the part most setups skip. An agent that acts invisibly has not been delegated to; it has been let loose.

Able to step in before it lands. For anything you cannot easily undo, sending money, publishing, deleting, promising something to a customer, the owner gets to confirm before the action goes out, not read about it afterwards. The more permanent the action, the earlier the person belongs in it.

A useful way to size any agent task, then, is to ask: if this goes wrong on a bad day, who is answerable, can they see it happened, and could they have stopped it in time? If you cannot name the person for all three, the agent is not ready to act on its own there yet. Let it draft and surface, not send and spend.

Name the owner before switching AI on

Two caveats, because this is not magic.

Naming an owner does not stop the agent making mistakes. It makes the mistakes traceable and recoverable, which is a different and more achievable goal. And a record is only worth keeping if someone reads it: a log nobody opens is not accountability, it is exhaust. The point of knowing what the agent did is that a person can act on it, not that you can wave it at a regulator later.

This is the line we hold on our own tools. We run agents that sort incoming work, draft replies and reports, and catch and group live software errors, but anything that leaves the building has a name on it before it goes, because "the system decided" is never an answer we would accept from ourselves on behalf of a client.

As agents get better, the temptation will be to let them act more freely and think about responsibility less. The opposite is the right move. The more an agent can do without asking, the more explicit, and the more obviously human, its accountable owner has to be. Decide who answers for it before you switch it on. If you want a clear read on where an agent could help and where it needs a name on it first, that is the sort of thing we work through on a short call.

Occasional updates

One email,
when we publish.

One plain email when a new article is up, nothing else. We'll send one email first to check the address is yours. Every email includes an unsubscribe link.

Free 20-minute call

Recognise your own problem in a piece? Talk it through with us.

Analytics

Can we measure your visit?

Google Analytics helps us understand which pages are useful. It stays off unless you allow it. See our cookie policy for details.