A pattern emerges in conversations with teams that have been running AI agents for a while. They describe an agent they built — a support responder, a ticket prioritizer, something that drafts weekly summaries — and at some point in the description they trail off and say something like “I think it’s still running.” Not “it is running.” I think it is.
That vagueness turned out to be a symptom of something worth paying attention to.
From tool to work
The shift happened quietly. When a team member first spins up an agent to help draft emails or sort incoming requests, it feels like a power tool: you pick it up, you put it down, it has no opinions about your absence. But once an agent is reading real files, touching real data, and producing output that other people act on, it has crossed a line. It is no longer a convenience — it is work. And work needs someone responsible for it.
The problem is that the tool framing tends to stick even after the agent has clearly moved on. Nobody made a formal decision to stop owning it. It just quietly became ownerless.
What ownerless actually looks like
Ownerless agents do not fail dramatically. That would be easier to catch. They fail silently, while continuing to look productive. Three failure modes recur:
Stale context. The agent keeps running on information that was accurate six months ago. A support agent answering questions based on a policy that changed last quarter. It still generates clean, confident replies. The replies are just wrong.
Rotted instructions. The original prompt was written for a process that no longer exists. The agent dutifully follows instructions nobody would write today, producing output that fits into nobody’s actual workflow.
Dead review loops. The agent was built with a human checkpoint: someone was supposed to review its output before it went anywhere. That person moved to a different team. Now the output goes straight through. The checkpoint exists on paper; in practice, the loop is open.
What makes these dangerous is that from the outside — especially to leadership — everything looks fine. Tickets are being processed. Summaries are being generated. The dashboard is green. The value drained out quietly, and nobody noticed because nobody was close enough to the work to notice.
The haunted house problem
One image from a recent piece captures this well: the “haunted house” organization. Rooms full of automated systems still moving long after the reason for them disappeared, leaving drafts, tickets, and recommendations that look like progress but change nothing.
That image stuck because it captures something precise: the systems are not broken in any technical sense. They are doing exactly what they were set up to do. The problem is that what they were set up to do no longer matters, and nobody is around to update them — or even to notice.
One owner, close to the work
The fix is not a governance committee. A committee can govern infrastructure — set standards, audit usage, enforce security policies. That matters. But governance is not ownership. Ownership means one person who is close enough to the actual work to know whether the agent is helping, drifting, or generating polished noise.
The test for whether an agent needs an owner is simple: once it reads real files, drafts real messages, or changes things other people rely on, it has crossed into consequential territory. At that point, someone should be able to answer these questions: What is this agent actually doing today? When was the context last checked for accuracy? Who reviews its output?
If nobody can answer those questions, the agent is ownerless — regardless of who built it or which team’s budget it sits under.
A practical artifact: the Owner’s Card
One concrete approach worth adopting is the idea of a single-page artifact — call it an Owner’s Card — that makes an agent visible as a piece of owned work rather than a background process. Think of it as analogous to the machine-readable cards that AI agents pass between themselves in multi-step pipelines, but written for human accountability.
The card does not need to be elaborate. The essentials: what the agent does, what data it touches, who owns it, when the context was last reviewed, and what the review loop looks like. The act of writing it forces the questions that tend to go unasked.
One approach that seems to work: point a prompt at an existing agent and ask it to draft the fields it can see — its instructions, its data sources, its outputs. Then hand the accountability questions (who owns this? when was it last reviewed?) back to a human to fill in. The agent can describe itself; it cannot own itself.
Where we are heading
The teams doing this well have stopped treating agent deployment as a technical event and started treating it as an organizational one. Spinning up an agent is not just a question of whether it works — it is a question of whether someone is responsible for it continuing to work, and for noticing when the world has moved on.
That shift in framing is where the practice is going. Not fewer agents — but clearer ownership of each one.
Text summarized and optimized using Anthropic’s models and reviewed by a human.