Let's start with a scene that's very common, and not pretty.
The automation that went live three months ago is still running. Every morning it produces the report, sorts the orders, sends the notifications. Nobody complains, because nobody looks. The real problem only surfaces the day a customer calls: it started getting things wrong six weeks ago. It just did it quietly.
The conversation that follows is worth writing down. You ask who's responsible for this. Admin says they hired a vendor to build it. The vendor says IT was the contact who signed off on it. IT says the requirements came from sales. All three are right, and nobody's name is on it.
It isn't broken. Nobody is looking after it.
Our last few pieces were about proving something works once it's built: write down your acceptance criteria first, and don't rush to ask about ROI in the first month. This one asks an earlier question, and one fewer people ask. Once this thing goes live, whose is it?
01The question least asked in adoption meetings
In the meetings before adoption, the questions are actually pretty good: how much time will this save, how soon can it go live, what will it cost, is the data safe.
Then there's one question almost nobody asks: three months from now, when it breaks, who's responsible?
This is an illusion created by sequence. Adoption is a project, and a project has a start and an end; launch day feels like the end. But automation is closer to equipment. It depreciates, it drifts, it needs maintenance, and maintenance never happens on its own.
One post-mortem roundup of enterprise agent projects sorted the failures into four patterns, and one of them is put especially bluntly: the system goes live and immediately "falls out of contact," problems pile up, and the value never shows. The same roundup concludes that "technology is the foundation; collaboration and feedback are what make it land." It puts the hardest part of making it land squarely on the organization's side, not the model's.
"Falls out of contact" is exactly the right phrase. It's still alive. Nobody keeps in touch with it anymore.
02It doesn't break loudly
If automation smoked, tripped breakers, and made a bang like a machine, there'd be no need for this piece. The trouble is that it decays respectably: the output keeps coming, the format stays correct, and part of the content just stops being true.
Three kinds of change are all but guaranteed to happen, and none of them is a technical accident.
Workflows change. The quote form gains a discount field, returns get an extra manager sign-off, the criteria for grading customers change. People adapt on their own, because people are in the room for the meeting. The automation isn't. It keeps working from the workflow as it was three months ago.
Data sources move. You switch inventory systems, someone reorders the columns in an Excel file, the client list moves from sheet A to sheet B. Sometimes even the person moving it doesn't know something is hooked up to it.
Models get new versions. The model you use gets upgraded today, tweaked tomorrow, has some behavior changed the day after. It's usually better, but "better" doesn't mean "still in sync with the instructions you wrote last year."
None of the three makes a sound. They just turn an accurate workflow, slowly, into a mostly-fine workflow, and then into one nobody fully trusts but nobody dares to shut off either.
Not daring to shut it off is the final shape this takes. China's wave of OpenClaw abandonment played this stage out in full: there were people selling installation as a service, and people selling removal too. On Xianyu (a secondhand marketplace) and on social media, they charged RMB 299 a time to clean it off for you. One user did the math: 599 to install, another 299 to remove. That's paying the sucker tax twice.
The vast majority of what got abandoned wasn't broken. People just couldn't keep it fed anymore, and that started with never saying clearly who was supposed to feed it.
We talked earlier about not keeping a lobster you can't tame. That piece was about "don't keep one." This one picks up the second half: now that you've got one, who feeds it?
03A maintainer isn't a technical job
The easiest place to slip here is translating all of the above into "so we need to find an engineer to keep an eye on it."
That's the wrong direction, and an expensive mistake.
One piece on why enterprise AI shouldn't be treated as an IT project lays this out clearly: hand ownership of AI down to the IT department and the project drifts away from the business and stays stuck in the pilot stage for a long time. The model that works is a three-way governance triangle: the CEO leads on strategy, the head of the business unit owns value creation, and IT provides platform support. It cites McKinsey's 10-20-70 rule as support: 10% algorithms, 20% data and technology, 70% people, process, and culture.
Seventy percent sits on the organization's side. So, naturally, does the maintainer role.
Because judging "is it still getting things right" takes business judgment. Whether a quote is reasonable, whether a category is right, whether this email should be answered this way: the person who writes code may not be able to tell you, but the person who's on the floor every day knows at a glance.
So what a maintainer is really responsible for comes down to three things, and none of them requires opening the code:
Knowing whether it's still accurate. A fixed review cycle, and a standard that shows right from wrong. This is the sequel, after launch, to the sheet of acceptance criteria we wrote about earlier.
Having the authority to stop it. When something's wrong, they don't need a meeting or a reply from the vendor. They can just shut it off. Without that authority, you don't have a maintainer. You have someone who reports problems.
Getting notified when the workflow changes. When the company changes a process, switches systems, or adjusts fields, they're on the list. This is the one most often missed, and most often where every later error starts.
As for who actually makes the changes, that can be a vendor, a colleague in IT, or an outside consultant. That part can be outsourced. The box where someone signs can't.
04The industry named this role a while ago
Boris Cherny, who leads Claude Code at Anthropic, has proposed a set of role archetypes he argues should replace traditional job titles for organizing teams: Prototyper (generating ideas), Builder (shipping fast), Sweeper (cleaning up and simplifying), Grower (iterating and growing), and Maintainer (keeping mature systems stable and efficient). He added something especially useful for small and mid-sized companies: most people span two or three of these roles, and the roles don't map to job titles. People with the same title may belong to different archetypes.
More worth remembering is his read on stages. Something brand new needs Prototypers, Builders, and Sweepers. Something that's already established shifts its weight to Sweepers, Growers, and Maintainers. Another article on the same framework put it more directly: the two kinds of people teams are most short of in the AI era are the ones who clean up and the ones who maintain.
That article closed with three questions for managers: does your team only reward adding features, who has the authority to stop a wrong direction, and who is explicitly responsible for cleanup and maintenance. None of the three requires touching the org chart.
In terms a business owner would use: during adoption, what you're paying for is building. After launch, what you need is upkeep, plus the nerve to delete. Most companies only budget for the first.
The good news is this usually doesn't take a new hire. Since the roles have nothing to do with job titles, the maintainer is often whoever already knows that workflow best. The only difference is that it's now a line in their job description, rather than something they do on the side.
Doing it on the side is the most fragile arrangement there is. When they take two weeks off, nobody covers. The day they leave, the whole thing walks out with them.
There's one way of assigning this to avoid in particular. One management piece on misjudged task assignment lists four common mistakes. The first is "give it to whoever looks free." The third is "hand off the work without spelling out the standard": you say "you do it" without saying how far to take it or when it counts as done. The maintainer seat is exactly where these two mistakes love to land: it goes to whoever has the lightest load, and then nobody tells them what to watch.
05Three lines to write on launch day
Solving this doesn't take a policy, a committee, or a set of procedures. It takes three lines, written into the handover document on launch day.
Line one · Who's responsible when it breaks. Write a name, not a department. A department doesn't notice in the middle of the night that the report is wrong.
Line two · How often it gets checked, and against what standard. Spot-check ten records a month, look at the rejection rate once a week, have someone rerun last year's cases once a quarter. The frequency doesn't matter. Writing it down does.
Line three · When it gets shut off, and who has the authority to do it. This line feels most like stating the obvious, and it's the one fewest people write. Its job is to make "shutting it off" a normal option, not an incident that sets off alarms across the company.
Before A system went live, and the deliverables were logins, passwords, and a training session
Now One more sheet of paper: a name, a cycle, an exit condition
Writing these three lines won't make the automation any smarter. It just turns something with no owner back into an asset.
If you can shut it off, it's yours
This run of pieces started by asking "how do you know AI is actually helping?" and it closes in the same place: whether something can be signed off and whether it can be switched off decides whether a tool is an asset or a liability.
When we wrote about the layer outside the model, we said something that pairs neatly with this: anything you can't take apart, nobody dares touch, and only one person knows how to run is not an asset. This piece fills in the first half of that thought. Whether you end up there is decided on launch day, and what decides it isn't the technology you picked. It's whether someone signed the document.
It's also the first question we ask about any existing system when we run an AI workflow diagnostic: whose is it? The ones nobody can put a name to are usually the same few systems nobody dares touch, yet the company keeps paying for every month.
Let AI move fast. Let people hold the anchor. Systems can be automated. Responsibility can't.
Rooted in craft. Built for the new wild.