Try this now. Name the person at your company who owns your AI tool. Not who bought it, not who uses it most. Who is responsible for it still being good in six months.
If that took more than three seconds, you've found the thing that will break it.
Everyone's tool is nobody's job.
What unowned looks like
It doesn't look like failure, which is what makes it hard to catch. The agent still runs. Nobody complains loudly. Usage drifts down maybe 10% a month as people quietly go back to doing things themselves, because twice it gave an answer that was subtly out of date and they stopped trusting it. Nobody mentions this, because it's not worth mentioning.
Nine months later somebody asks whether the tool is worth renewing, and nobody in the room can answer.
Ownership is four hours a month, not a headcount
This goes unassigned because people imagine it's a job. For a typical SMB deployment it's about four hours a month, and it's four specific things.
1. Read the escalations
Every time the agent handed something to a human, it told you where its edge is. Half an hour a week skimming those is the highest-value thing an owner does, and the patterns show up fast. The same question escalating twelve times is a gap you can close in an afternoon.
2. Approve changes
Prompt edits, new capabilities, changes to what it's allowed to say. Not write them, approve them. Somebody has to hold the line on what this thing is for, or it slowly accumulates features nobody asked for and gets worse at the one job that mattered.
3. Watch two numbers
Two. Not a dashboard with fourteen tiles that gets opened once in March. For most agents the two are the share of work it handles without a human, and the quality of what it produces when it does. If both hold steady, nothing needs your attention this month.
4. Decide when to expand
Every working agent generates requests to do more. Somebody has to say yes to two of them and no to the other six, depending on whether the core job is solid yet. That's a business judgment rather than a technical one, which is why it can't sit with whoever configured it.
Who it shouldn't be
Not IT, if you have one. They'll keep it running, which isn't the same as keeping it good. The failures that matter here are judgment failures: a stale answer, a tone that's wrong for your customers, a policy that changed in March. Uptime monitoring catches none of that.
Usually not the founder, though it almost always is at first. You'll do it attentively for six weeks and then a quarter will get away from you. Not a discipline problem. It's what being the founder means.
Usually the person whose work it changed most. The office manager whose inbox it handles. The CSR whose calls it takes. They already notice when it's wrong, because they're the ones cleaning up afterwards. Giving them ownership mostly means giving them somewhere to put that, plus the authority to get it fixed.
Make it real in one sentence
Write this down somewhere other people can see it: [Name] owns [agent]. They review escalations weekly, approve changes, and report on [two metrics] monthly.
Put it in the deployment doc. Say it out loud in the meeting where you announce the thing. It takes a minute, and it's most of the difference between a system that's better in a year and one that's quietly worse.
If the honest answer is nobody
Some businesses genuinely don't have a person for this, and pretending otherwise just moves the failure somewhere less visible. That's what a retainer is for: we hold the four hours, run the monthly review, and bring you the two decisions that actually need you.
Just be clear that what you're buying is ownership rather than maintenance. If a vendor's support plan is uptime and a ticket queue, nobody owns your agent and the org chart still has a hole in it. There's more on why that distinction decides everything in products, not projects, and on what "still working" should mean concretely in our definition of done.