The accountability deficit

The most expensive AI failures I have seen were not the dramatic ones. A support agent kept drafting refund replies from a policy that had changed a quarter earlier — fluent, fast, and wrong — and the replies went out for weeks before a customer escalation made someone look. The agent had not broken. It had kept doing exactly what it was told, long after what it was told stopped being true, and no one caught it because catching it was not anyone's job.

This is the third time I have written about a constraint quietly moving. Production capability became cheap, and judgment became the bottleneck. Then context — what a system understands about where it operates — became the limit on whether agents could do real jobs rather than well-specified tasks. The constraint now is accountability. As agents move from answering questions to doing work, the scarce thing is no longer a better model but a person willing to answer for what the work becomes.

I should say, as before, that I work adjacent to this technology and benefit from its success, so discount my optimism accordingly. And I want to be careful with the word scarce, because the fix I am going to describe sounds almost free: a named person, a single page. The scarcity is not in the paperwork. It is in the supply of people who carry enough situated judgment to notice when an agent's output has quietly gone wrong — the same judgment I argued in the first of these essays is being thinned out, exactly as we come to depend on it most.

I. The failure mode is silence

When we imagine an AI agent going wrong, we imagine something loud: a confident falsehood, a destructive action, a visible breach. Those happen, and they earn the attention they get. But the failure that drains the most value is quiet, and it is quiet by construction.

An agent absorbed into a real workflow does not announce when it stops being useful. A support agent keeps drafting from a refund policy that changed last quarter. A planning agent keeps compressing noisy tickets into clean-looking priorities. A research agent keeps producing polished memos from sources that went stale months ago. The output arrives on schedule, formatted correctly, indistinguishable on the surface from work that is still good. Everyone stays busy. The value drains out underneath, and the reason no one catches it is that catching it belonged to no one.

This is the difference between a system that breaks and a system that drifts. A broken system tells you it is broken. A drifting system tells you nothing; it grows less aligned with reality while continuing to produce artifacts that look like progress. A team can accumulate a surprising number of these before anyone asks whether the work got better. The dashboards refresh, the tickets get filed, the summaries arrive — motion everywhere, and no way to tell whether the work underneath is still true.

I made the empirical case for this in the essay on context, so I will not repeat it in full. The short version: handed well-specified tasks — real deliverables an expert would recognize — frontier models now produce work that other experts rate as good as or better than a professional's close to half the time; handed an actual job, a brief and the expectation that they will work out the rest, success falls to a few percent. That gap is a gap in situated understanding. What matters here is what happens to it after deployment. It does not hold steady. It widens, because the brief and the policy and the codebase keep moving while the agent's picture of them does not. An unowned agent is a maintenance problem no one has agreed to maintain.

II. The test for when an agent becomes work

I want a rule simple enough to apply without convening a meeting, because rules that require meetings do not get applied.

Here is the one I have settled on. If a system can read context that matters, produce work that someone acts on, or touch a process that other people depend on, it has become work that needs an owner. Most of the rule's value is in how early it triggers. A draft-only assistant that prepares the document a team walks into a meeting believing has already crossed the line, because the team now acts on its output. The threshold is consequence, not independence.

The definitional debates — is this really an agent, or only an assistant, or just a workflow — are mostly a way to postpone the operating question. The boundary is blurry and getting blurrier, and waiting for it to resolve is itself a decision, usually the wrong one. The useful move is to stop asking what the system is and start asking what you handed it. The moment you delegated a job rather than asked a question, you took on a responsibility, whether or not you have named it.

III. What ownership is, and what it is not

Ownership, in the sense I mean, is narrower and more practical than the word suggests.

It does not mean the owner built the agent, or is the only person who can change it, or understands the model's internals. It means one identifiable person is responsible for the quality of the delegated work: someone who knows what the agent reads, what it can touch, what good output looks like, where it tends to fail, and when it should be paused or retired. The test is whether someone would notice, and act, when the work begins to degrade.

We already practice this everywhere else, which is what convinces me it is the right frame rather than a borrowed metaphor. A dashboard acquires an owner the moment people make decisions from it. So does the deployment script that ships the product, and the policy a support team quotes to customers. We would find it absurd to let a stale dashboard brief an executive, or to run production on a script nobody maintains. Agents earn that same status the instant their output becomes an input to real work. A conversational interface does not exempt an agent from the maintenance we extend to everything else load-bearing. If anything it makes the maintenance more urgent, for a reason I will come back to.

What the owner actually does is ordinary: define the job narrowly enough that its quality can be judged, curate what the agent reads so it is not running on stale material, keep its permissions matched to the stakes, and review enough of its output to catch a recurring failure as a defect in the system rather than a one-off to fix and forget. The concrete form of all of this is a single page, and I will come to it. The point for now is that none of it is exotic. It is the discipline of being responsible for something, applied to a kind of thing we have not yet built the habit of being responsible for.

IV. How the problem scales

The shape of the problem changes as the systems grow, and it changes in an unfortunate direction: it gets easier to lose track of, not harder.

A personal agent is the manageable case. If you run a coding agent on your own repository, you own that workflow whether you have said so or not, and the cost of neglect lands mostly on you. The subtler version is a personal assistant that drifts as you change and its instructions do not — a research routine, a planning helper, a writing aide still optimizing for the person you were six months ago. It is worth naming because it shows the problem is not only institutional. It happens to one distracted person, and the remedy is the same at every scale: maintain what the system reads.

The team case is where the first structural error appears. A team builds a shared agent because the pain is shared: everyone is drowning in the same tickets, the same refinement prep, the same review queue. Because the pain is shared, the tool becomes shared, and because it is shared, it can end up owned by no one. What results is rarely one alarming system. It is a quiet layer of competent ones, each doing a little real work, none anchored to anyone's responsibility. The correction is to let ownership follow the work: the team that lives with the consequences of an output is the team placed to notice when it degrades, whoever built the tooling. Usage spreads easily across a group. Responsibility does not — split among everyone, it usually lands on no one.

The pipeline case worries me most, because the more sophisticated the system, the easier it is for everyone to assume someone else is responsible. When a chain of agents passes work among a researcher, a writer, a reviewer, and a publisher, calling tools across systems along the way, it is tempting to treat the framework as the responsible party. But a framework is plumbing. It moves work; it does not answer for it. Someone still has to own the pipeline's purpose, its boundaries, its failure modes, and the standard a run has to meet — which source of truth wins when two conflict, and what evidence the output must carry before anyone trusts it. The likeliest failure of a sophisticated agent system is not a dramatic one. It is a chain that still technically runs and no longer clearly helps: the researcher surfacing things no one uses, the reviewer checking for risks no one defined, the whole chain still running because nobody decided to stop it.

V. Why governance is necessary and not sufficient

The security and governance world is, to its credit, moving in the right direction. OWASP now runs an agentic security initiative and publishes a 2026 Top 10 for agentic applications. OpenAI's Agents SDK treats guardrails, tool checks, tracing, and human review as first-class parts of an agent workflow. Google's Agent2Agent protocol is built around agent cards, task lifecycles, and authentication between systems. This infrastructure matters, and an organization that lets every employee wire arbitrary agents into sensitive systems is asking for the kind of trouble these efforts exist to prevent.

But there is a difference between an owned tool and owned work, and the gap between them is exactly where agents fail. A governance function can determine that a support agent is permitted to read a particular system and draft replies. It is not placed to know whether the refund policy in that agent's source folder reflects the exception a support lead approved last week. It can approve a coding tool; it cannot tell you whether a given patch matches the product's intent. Agents fail in domain-specific ways, so the person able to detect the failure has to sit close to the domain.

This does not make committees useless; it makes them the wrong owner for the wrong layer. A committee can and should own standards, platforms, and incident review — the shared infrastructure. What it cannot supply is the continuous, situated attention that catches the moment this agent's output drifts from this domain's moving reality. That has to sit with a person, and the cleanest way I know to make that person exist is to write them down.

That is the artifact I would actually put in front of a team. Google's A2A protocol already gives every agent a card so it can introduce itself to other agents — a name, a purpose, a list of capabilities. That handles recognition between machines and says nothing about the human behind the work. The owner's card is the missing counterpart. For the refund agent that opened this piece, it fits on a page:

Agent:            Refund-reply drafter (support)
Owner:            Support team lead
Backup owner:     Senior support agent
Job:              Draft first-pass refund replies for human review. Never send.
Reads:            Current refund policy (source of truth); this quarter's approved exceptions.
Must not read:    Superseded policy docs; ad-hoc rulings in chat.
Allowed:          Draft into the review queue.
Forbidden:        Send to customers; issue refunds; edit policy.
Evidence:         Cite the policy clause each reply relies on.
Review:           Lead samples ten drafts a week; every escalation gets read.
Pause if:         Two weeks of drafts cite a clause that no longer exists.
Retire if:        Policy moves to a system the agent cannot read reliably.

The page is unglamorous on purpose. Its whole function is to make an agent visible before it disappears into the background, and to force the conversation most teams skip: this system is doing real work, so who answers for the quality of it?

VI. Ownership is the third migrated constraint

The three constraints are not the same mechanism wearing three hats, and it is worth being precise about that. Production became cheap, and the bottleneck moved to judgment. Context became the limit because judgment needs situated knowledge to act on. Accountability binds for a different reason again: not because something adjacent got cheap, but because we have begun handing agents work that someone has to answer for. What the three share is a direction. Each moves the constraint closer to the part of the work that cannot be automated away — a person's responsibility for the outcome.

This is also why accountability is genuinely scarce, and not merely neglected. Owning an agent well takes the same situated judgment that lets a person see, before anyone else, that the output has drifted — the judgment I argued in the first of these essays is being thinned out exactly as organizations stop hiring and training for it. The card is cheap. The person who can fill it in honestly, and notice when its answers stop being true, is not.

The obvious objection is that no one can own hundreds of agents. True, but the test was never the count. It was consequence, and the agents that genuinely move money, ship code, or speak to customers are far fewer than the total. Most of what a team runs can stay informal. The few that cross into real consequence are the ones that need a name attached. The instinct in a fast-moving field is to accumulate — another assistant, another workflow, another demonstration to point at — so as not to feel behind. But past a point, accumulation produces the opposite of mastery, because each new system is one more thing no one fully understands. The version of progress I believe in is not the largest collection of agents but the small set a team owns: systems whose sources, limits, failure modes, and review cadence are known, and which can therefore be trusted with real work and improved over time. One maintained agent doing a real job is worth more than ten demonstrations no one relies on.

The reason this is the harder skill is the same reason the failure is silent. An abandoned dashboard looks abandoned, and an abandoned script throws an error, but an abandoned agent keeps answering — fluently, with complete confidence — long after anyone should trust it. So my conclusion is not that we should slow down, or be afraid of what we are building. It is that we should build with the discipline these systems have earned. Use agents; delegate to them; let them read and draft and inspect and prepare. And for each one that has crossed into work that matters, make sure a particular person can answer for it. If no one is willing to, that is the most useful thing the exercise will tell you: the agent is not ready to do the job.