Skip to content
Data McFly.
Back to writing

writing

Who's Accountable When the Agent Is Wrong?

Jul 23, 2026 · 4 min read · Roger Stringer

Every leader seriously considering AI eventually arrives at the same question, usually late in the conversation and usually quietly. When the agent gets something badly wrong, sends the wrong number to a customer, approves something it shouldn't have, makes a call that costs real money, who is actually accountable?

It's the right question. And the honest, uncomfortable answer for a lot of teams is: no one has decided. That's not an AI problem. That's a governance problem, and it's the thing standing between a clever demo and a system you can responsibly run.

"The AI did it" is not an answer

Picture a support agent that, trying to be helpful, confidently promises a customer a feature your product doesn't have and isn't building. The email is already sent. The customer is already excited. Now what, and more to the point, who handles it?

When an agent makes a mistake like that, there's a strong pull to treat the system itself as the responsible party. The AI got it wrong, the model hallucinated, the tool failed. It feels true. It's also useless, because a tool can't be accountable. It can't be coached, it can't be held to a standard, and it can't answer to a customer.

Accountability has to land on a person, the same way it does for any other tool your business uses. When an employee sends a bad email using your email system, you don't blame the email client. Someone owns the outcome. An agent is no different, no matter how autonomous it feels.

Accountability is a design decision, not an afterthought

The mistake teams make is treating the accountability question as something to sort out after something goes wrong. By then it's a blame exercise. The time to answer it is while you're designing the system, before anything ships.

For every agent doing real work, you should be able to answer, in advance: who owns this agent's output, what decisions is it allowed to make on its own, which decisions require a human to sign off, and what happens, specifically, when it fails. Take that support agent. Had someone decided up front that it could answer questions about existing features but had to route anything about the roadmap to a human, that bad promise never gets sent. The guardrail was a design decision nobody made.

This is why the boundaries matter so much. An agent with a tightly scoped job and a clear human owner is accountable by design. An agent with broad access and no named owner is an incident waiting for a date, and when that date arrives the first hour will be spent figuring out whose problem it is.

Match the gate to the stakes

Not every decision needs a human signature, and pretending otherwise just recreates the bottleneck you were trying to remove. The trick is matching the level of human oversight to the cost of being wrong.

Low-stakes, reversible, high-volume work can run with the human reviewing samples after the fact, not every case. Categorizing tickets, drafting internal notes, enriching records. High-stakes, hard-to-reverse, or customer-facing decisions get a human in the loop before the action happens. Issuing a refund above a threshold, sending the message to the major account, anything with legal or financial weight. The agent can still do all the preparation. A person owns the final call.

That mapping, which decisions are pre-approved and which need a gate, is itself an accountability decision. And someone senior owns making it.

This is what the 30% is for

If you've read about the 70/30 Method, accountability is the heart of the 30%. The 70 is the work the agent does. The 30 is the judgment wrapped around it, and "who owns it when it's wrong" is the most important question that judgment answers. An agent you've onboarded like a new hire still reports to someone. The accountability didn't transfer to the machine. It never can.

Getting this right is most of what separates AI you can responsibly run from AI you're quietly gambling with. It's the governance layer of an Agentic OS, and it's the work I do with clients who want aggressive automation without taking on risk they can't see. If you can't yet say who owns it when your agent is wrong, that's where to start. Let's talk.