Supervising AgentsJuly 20, 2026·6 min read

Who's Accountable When an Agent Gets It Wrong

Courts and regulators have settled this faster than most workplaces have: the organisation that deployed the tool owns what it did. Here's what that means for the person who pressed go.

By Patin Team · Examples are illustrative composites

There's an assumption sitting underneath a lot of AI adoption that nobody says out loud: that if the tool produced it, the responsibility is somehow shared.

It isn't, and this has been settled faster outside workplaces than inside them. The direction of every ruling, regulator statement and professional-body guidance so far is the same — the party that deployed the system owns what it did. "The AI said so" has been tested as a defence and has not worked.

That's the legal answer. The more useful question is the internal one: within your organisation, which specific person owns an agent's output? Most places have not answered it, and the ambiguity is doing quiet damage.

The three roles that get conflated

The deployer decided the agent would do this task, with these permissions, at this level of supervision. Most of the accountability lives here, and it's the role least likely to be occupied by an identifiable person — configuration tends to happen collectively or by inheritance from whoever set it up first.

The operator ran it on this occasion, on this input, and passed the output on. In practice this is who gets blamed, which is only fair if they had time to check and a standard for what checking means.

The reviewer signed off. Sometimes the same person as the operator; sometimes nobody, structurally, because "someone will spot it" is not a role.

A useful test: for one agent running in your organisation right now, can you name a person for each? If two of the three come back as "the team", that's the gap.

The rule that makes it workable

You own what goes out under your name; the time to check it is part of the task, not overhead.

Both halves matter. The first half alone is a threat, and the rational response to a threat is to avoid the tool for anything consequential — which is exactly the work where it helps most, so you get the risk of shadow use without any of the benefit.

The second half is what makes the first fair. If checking takes twenty minutes and the task is budgeted at ten, you haven't assigned accountability. You've assigned blame.

Where the reasoning gets slippery

Three arguments come up, and all three are weaker than they sound.

"It was a tool error." Tools have failure modes; deploying one means accepting them. Nobody accepts "the spreadsheet miscalculated" as a defence, and spreadsheets do miscalculate — when the formula was wrong, which is a deployment decision.

"Nobody could have caught it." Occasionally true, and much less often than claimed. The honest version is usually that nobody was looking, which is a supervision-level decision made earlier by someone identifiable.

"The vendor's terms say otherwise." Vendor terms allocate risk between you and the vendor. They have no effect on your obligations to a client, a regulator, or a person affected by the output.

What actually reduces exposure

Not more approval steps — those decay into rubber-stamping and produce a record of sign-off with no judgement in it, which is arguably worse evidentially than having none.

Four things do:

A named owner per agent. One person, not a team. They own the configuration and the permissions, and they're who you go to when it does something odd.

A written standard for what checking means on each output type. Without one, "I checked it" is unfalsifiable in both directions.

A trace you could reconstruct. For anything consequential, what it saw and what it did. This is a bad month with the records, or a very bad year without them.

Irreversible actions with a human on them, permanently. Send, spend, delete, grant. Not because the agent is unreliable, but because those are the ones where being wrong can't be walked back.

Fabienne — the sign-off nobody had

Fabienne is head of compliance at an insurance intermediary. An agent producing customer correspondence had been running for four months when a letter went out with an incorrect policy term.

Her review found the interesting part wasn't the error — it was that no one owned it. It had been configured by someone who'd since changed roles, was run by three people on rotation, and reviewed by whoever happened to be on. Three groups each reasonably assumed one of the others was checking.

She assigned a single named owner, and the volume of things that needed fixing dropped in the first fortnight — mostly because someone was now looking at all of it rather than each person seeing a third.

Gerald — the twenty minutes he'd not been given

Gerald is a senior associate at a law firm. His firm's AI policy said the sending lawyer was responsible for verifying AI-assisted work — reasonable, and identical to what the courts have said.

What it didn't do was change any time expectation. The work was still billed and scheduled as though verification were free, so verification happened in whatever time remained, which was frequently none.

He raised it as a resourcing question rather than a policy one, and got the verification step written into the matter budget as a line. His view: the policy had been assigning blame and calling it accountability, and the difference was about twenty minutes per document.

The one thing

The party that deployed the system owns what it did — that part is settled. What isn't settled, in most organisations, is which individual that means.

Name an owner per agent, write down what checking means, keep a reconstructable trace, and keep a human on anything irreversible. And budget the checking time, because accountability without it is just blame with a policy attached.

Reading about it only gets you so far

Patin turns this into five-minute drills that score what you write and tell you why. It's in closed beta — join the waitlist and we'll email you when your cohort opens.

Just want the writing? .