Who maintains your AI agents after delivery? Four options

Someone with a name has to maintain your AI agents after delivery, and the contract should say who before the build starts. There are four real options: an owner inside your company, the team that built the agents on a retainer, a third party you hire later, or nobody. Nobody is the default, and it is the most expensive of the four.

Maintenance sounds like a support ticket queue. In practice it is a small, steady amount of work that arrives on someone else’s schedule: a model provider retires a version, a supplier changes a file format, a person stops trusting an output and quietly goes back to the spreadsheet. This post covers who does that work, what the work is, and how to pick.

Key Takeaways

• Model providers set the maintenance calendar: OpenAI promises at least 6 months notice before retiring a generally available model, and some shutdowns land on 23 October 2026
• Upgrading a model can break the prompts and checks built around the old one
• Four options exist: in-house owner, builder retainer, third party, nobody
• The right choice depends on whether someone on your side has spare hours, not on how technical they are

What does maintaining an AI agent actually involve?

Maintaining an agent means four recurring jobs: replacing models the provider retires, fixing what upstream systems change, reviewing the cases the agent hands back to a person, and watching access and cost. None of it is glamorous. All of it has to happen on a calendar that you do not control.

Model changes. OpenAI’s deprecations page says generally available models get at least 6 months of notice before retirement, and its schedule (checked 4 October 2026) lists models such as gpt-4-turbo and gpt-4.1-nano for shutdown on 23 October 2026 (OpenAI API deprecations, October 2026). Six months is generous. It is also a deadline that arrives whether or not anyone is watching.

Swapping the model name is rarely the whole job. A 2025 study of production agents, covering 20 case studies and 86 survey responses, reports that agent scaffolds, prompts and evaluations lock onto specific model behaviours, and that deploying a newer model can break workflows (Measuring Agents in Production, arXiv 2512.04123, revised June 2026). Some teams run the old model beside the new one while they check the difference. Someone has to do that checking.

Upstream changes. The agent reads from other systems: a mailbox, an accounting package, a supplier portal, a spreadsheet someone keeps renaming columns in. When one of them changes, the agent either stops loudly or, worse, keeps going on bad input. Maintenance is partly the work of making sure it stops loudly, and partly the work of fixing it when it does.

Handed-back cases. The same arXiv study found 68% of deployed agents run fewer than 10 steps before a human steps in, and 74% rely mainly on human evaluation (arXiv 2512.04123, 2026). Humans stay in the loop in most production agents. Their feedback is the signal that tells you the agent is drifting, and it only helps if someone reads it.

Access and cost. Keys expire, people leave, a usage bill creeps. A named person should know which accounts the agent runs on and who can rotate a credential.

Who can maintain AI agents after the builder leaves?

You can put the work with an in-house owner, with the builder on a retainer, with a third party, or with nobody. Each option answers the same question differently: who notices first, and who has the access and the context to fix it? The table compares them on the points that decide the outcome.

Option	Who notices first	Context on day one	Main risk	Fits when
In-house owner	Your own team, close to the work	Whatever the handover gave them	One person becomes the single point of failure	You have someone with real spare hours
Builder on a retainer	The builder’s monitoring	Full, they wrote it	Dependence on one party	You want it kept running without adding headcount
Third party, hired later	Nobody until it breaks	Starts from the documents	Slow first fix, a learning bill	The original builder is gone
Nobody	The person who stops trusting it	None	Silent decay, then a rewrite	The agent is a short experiment you plan to discard

When does an in-house owner work?

An in-house owner works when one named person has a standing slice of their week for the agents and the access to change them. A title does not do it. Hours do. Ownership that lives in a job description but not in a calendar turns into the third option, nobody, within a quarter.

What the owner needs is narrower than people expect. They do not need to write the code. They need to read the weekly output, tell an acceptable exception from a bad one, hold the credentials, and know when to call for help. A good operations lead can do that with a short runbook.

We run it this way on our own group. Every agent ships with an owner, a scope and a kill switch, and two humans architect and approve while the agents do the production work, as our agent fleet case study sets out.

The case reports 41 registered agents, 9 live and 5,450 runs with zero failures over 13 days, as of July 2026. Those numbers are a snapshot from that measurement, not a promise about your setup. The part that transfers is the rule that every agent has a named human attached to it.

The weak point is concentration. If the owner leaves, the knowledge leaves with them, unless the runbook is written down and the credentials sit in an account the company controls.

When should the builder keep maintaining it?

The builder should keep maintaining it when you want the agents kept running but not another hire, because the builder already holds the context. That is the logic of a retainer: a fixed monthly fee for watching what shipped, fixing what changed, and reporting in writing.

Our version is the fractional AI officer retainer. It costs $2,900 a month, cancels monthly, and covers monitoring of everything previously shipped, one new automation per month, and a weekly written brief. Everything runs on your accounts with your keys, so cancelling leaves nothing to unwind. That structure is deliberate: a retainer you cannot leave is just lock-in with a different invoice, a risk we cover in the handover test for AI agencies.

A builder retainer does not suit everyone. If you already employ someone who can run the agents, paying for monitoring twice is waste. If you only have a single small agent, a monthly retainer may cost more than the agent saves. Do the arithmetic from hiring an agency versus building in-house before deciding.

What does a third party add, and what does nobody cost?

A third party suits the case where the original builder is gone or you want a second opinion on what you were handed. Expect a slow first fix, because the newcomer starts from the documents and the repository. The quality of the handover decides how large that learning bill is.

Nobody is worth taking seriously, because it is a choice many buyers make without noticing. A fixed-scope build usually ends with a support window. Our workforce sprint, for example, includes a recorded walkthrough and two weeks of written post-handover support, and then the system is yours entirely. Two weeks is a stabilisation period. It is not an ongoing maintenance plan, and it is not meant to be mistaken for one.

After that window, nothing is scheduled to check the agent. The cost does not show up as an invoice. It shows up when a retired model name starts returning errors on a Monday morning, or when the people who rely on the agent decide it is wrong twice and stop opening its output. At that point you pay for a diagnosis and a partial rebuild at once.

There is one honest case for nobody: an agent you built as a short experiment and plan to switch off. Say that in writing, with a date.

How do you choose between them?

Choose by asking two questions in order. First: does someone on your team have standing hours for this? If yes, make them the owner and pay the builder for a handover, not a retainer. If no, the real choice is between a retainer and nobody, and the date-driven nature of model retirements makes nobody a poor bet for anything that matters to revenue.

Second: how many agents are there? One agent with an engaged owner is easy to keep alive. Past a handful, the owner is managing a small fleet, and the work shifts from fixing individual agents to keeping a register of what exists, who owns each one, and when each model dependency expires.

Whatever you pick, write the answer in the scope before delivery: the name of the owner, what they can change, and who they call. A scope that says “support after launch” without a name has not answered the question.

Start async

If you have agents running now and cannot say who would fix them next month, describe them at /start. You get a written reply within one business day, no meetings, naming what we would check first and whether a retainer fits at all. Each agent we build is a tomte, our word for one production agent with one defined job, and every tomte leaves with a named owner. That owner can be you.