Who Is Responsible for an AI Agent?

TL;DR

"Who is responsible for this agent" is usually answered with a name, and the name is usually the wrong unit to answer with. A business owner gets named accountable for an agent's outcomes and typically cannot revoke its access, roll back what it did, or shut it off. That lever sits with someone else.

The interesting failure isn't the absence of an owner. It's an owner who is real, named, and answerable, and who discovers during an actual incident that being accountable and being able to act were never the same thing.

We think that mismatch is worse than having no named owner at all. A vacancy at least prompts someone to ask who's in charge. A name with no mechanism behind it looks like the question has already been answered, so nobody keeps asking.

The fix isn't a longer roster. It's recording, next to every name, whether that person can actually stop the thing, and who they call when they can't.

Overview

When an AI agent makes a mistake, the reflex question is always the same: who is responsible? A procurement agent approves a duplicate invoice, a marketing agent publishes an unapproved discount, a data agent runs a query that exposes a column it should never have touched, and someone has to answer for it. Most organizations answer that question by writing a name in a registry next to the agent's entry, and consider the problem solved.

We don't think it is solved. A named owner is a good first step and a bad final answer, because the question "who is responsible" quietly collapses two different questions into one: who should answer for what this agent did, and who can actually change what it does next. Those are frequently different people, and an ownership model that doesn't say so out loud is hiding its own weakest point.

A companion piece on accountability frameworks covers the practical mechanics of the first ten minutes of an incident, who can revoke, who can roll back, and how fast. This one is about an earlier and narrower problem: what happens the moment you write a single name next to "owner" and call it done.

The Agent Cannot Own Itself

It's tempting to treat an autonomous agent as a self-contained actor that bears its own responsibility, and that framing fails immediately under any real pressure. When an agent updates the wrong field across hundreds of records, nobody accepts "the model decided that" as a resolution. The damage is real, the cleanup is human, and the decision to deploy the agent in the first place was a human one.

Responsibility flows backward from the action to the people who shaped the conditions for it: whoever defined the agent's purpose, whoever built and connected it, whoever scoped its permissions, whoever chose to keep it running. Autonomy distributes execution. It doesn't distribute accountability, and that part of the picture is genuinely settled. What's less settled, and what the rest of this piece is about, is what happens once you've named the accountable human and the agent is still doing damage in real time.

Naming an Owner Is Not Giving Them a Switch

Take a contracts lead named as the business owner of a contract-triage agent, accountable for what "correct" means in that workflow and for whether the agent is still fit for it. That's a reasonable assignment. The contracts lead understands indemnification language better than anyone on the platform team.

Now the agent starts passing through indemnification clauses it should be escalating. The contracts lead is, by every definition on the org chart, the responsible party. They also, structurally, almost never hold the ability to revoke the agent's access, roll back what it already sent to a counterparty, or stop the next run from doing the same thing. That mechanism sits with whoever manages the integration, usually a platform or security function that was never named accountable for the outcome and has no particular urgency to treat this as their emergency.

So the person who is supposed to act has to find the person who can, mid-incident, without a defined path for doing it. That search is where the damage compounds. Not because nobody was responsible. Because responsibility and capability were assigned to different desks and nobody wrote down the bridge between them.

Figure 1 — Naming an owner answers who gets asked. It doesn't answer who can act, and the gap between those two questions is where an incident runs while a phone call happens.

Two Questions Wearing One Job Title

"Owner" is doing two jobs on most registries, and it's worth separating them explicitly rather than trusting one title to cover both.

The first question is a business judgment: is this outcome acceptable, should the agent's scope change, should it keep existing at all. That's squarely the business owner's call, and it should stay theirs, because nobody else has the context to make it well.

The second question is operational: can this specific action be stopped right now, and by whom. That's rarely the same person, and pretending otherwise is how an ownership model ends up with a name that's accountable for everything and empowered to do almost nothing in the moment that matters.

We think the second question is the one most frameworks quietly skip, because it's uncomfortable to write down that your named owner is, in practice, a contact rather than a switch. Writing it down anyway is the entire value of doing this exercise honestly.

Why the Mismatch Is Worse Than No Owner

An agent with no named owner at all at least announces its own problem. Anyone who looks for one notices the gap and keeps asking. An agent with a named owner who has no actual lever looks solved. The registry has an entry, the entry has a name, and the search stops there, right up until the day it matters.

There's a second cost that's less obvious and, we'd argue, more corrosive over time. A person who is formally accountable for outcomes they can't influence learns, correctly, that the title carries risk without carrying power. Some respond by rubber-stamping, since their sign-off was never going to change what happens anyway. Others simply avoid the role. Neither response is a character flaw; both are the predictable result of asking someone to answer for a system they can't touch.

What Ownership Should Actually Record

An ownership record that's honest about this problem answers more than a name. For every agent it should be possible to say, in under a minute, who is accountable for the outcome, whether that person holds a mechanism to stop or change the agent directly, and if not, exactly who they escalate to and how fast that person can act.

That third field is the one almost every registry is missing, and it's the one that actually matters during an incident. A business owner who can retire an agent is a real owner. A business owner who can only ask a technical owner to consider retiring it is a name on a document, and the record should say so plainly rather than implying otherwise by listing them under the same "owner" column as everyone else.

None of this argues for fewer named roles or a flatter structure. It argues for writing next to each name the one fact that decides whether it means anything: what, specifically, can this person do about it.

In Practice

Take an IT-operations agent that provisions access for new hires by assigning roles in downstream systems. It has a named business owner, the IT-ops lead who decided the workflow should be automated, and a named technical owner who maintains the integration. Both names are correct. Neither is defined against the actual incident that eventually happens: the agent starts granting a role broader than the request specified, because a template it reads from was updated upstream and nobody flagged the change.

The IT-ops lead, accountable for the outcome, has no way to pull the agent's provisioning access themselves. They call the technical owner, who is on a different team and didn't get an alert, because nothing in the setup routed incidents to them automatically. Twenty minutes pass before the access is cut. In that window, the agent has already granted the broad role to four more new hires.

Nothing about that twenty minutes was a mystery once someone reconstructed it. The ownership model had two correct names and no defined path between them. Fixing it wasn't a bigger framework. It was writing down, in advance, that the IT-ops lead's actual power in an incident is "call the technical owner," giving that call a direct line instead of a shared inbox, and deciding that provisioning-scope changes trigger an automatic alert to both names at once rather than one.

Conclusion

The goal of naming an owner was never to have someone to blame. It was to guarantee that when an agent does something wrong, someone can actually change what happens next. A name accomplishes the first goal by itself. It accomplishes the second only if it's attached to a real mechanism, or to an honest, fast path to whoever holds one.

Ask the uncomfortable version of the question for every agent you're accountable for: if this goes wrong at 2 a.m., what can I personally do about it, right then, with nobody else awake yet? If the honest answer is "wait for someone else," write that down. It's not a failure to record. It's the thing the record was supposed to catch.