Who maintains an AI automation after handover?

Doesn’t a working automation just keep working?

Not by default, and not because the build was bad. Three separate mechanisms can break a delivered automation without anyone touching it, and none of them show up in a demo, because a demo only proves the automation works today, under conditions the builder controlled.

What actually breaks it, mechanically?

Ownership goes stale. Microsoft’s own documentation describes a specific, common failure: a Power Automate flow tied to the login of the person who built it, and once that person leaves the organization, the connections the flow depends on stop authenticating. The flow doesn’t announce this. It just starts failing, quietly, the next time it runs. Microsoft’s fix is to assign a co-owner before the person leaves, which only works if someone remembered to do it.

Platforms auto-disable on repeated errors. Zapier turns a Zap off by itself once roughly 95% of its runs error over a rolling seven days. If you’re on a Team or Enterprise plan, you get an email warning and a grace window, 24 or 72 hours, before it happens. That’s a safety feature from Zapier’s side, protecting its infrastructure from a runaway broken workflow. From your side, it means a workflow that was working can go dark with no human decision behind it, and the first anyone hears about it might be a customer noticing the automation stopped.

The AI model underneath has a retirement date. OpenAI publishes a minimum six-month notice before it retires a generally available model, and as little as two weeks for a preview model. That’s a real, scheduled clock sitting under any fixed-price automation that leans on a specific model. A build that was correct on delivery day can require real engineering work a year later, not because anything broke, but because the ground it was built on moved on a published schedule.

None of these three is a hypothetical edge case. They’re documented, expected behavior from the vendors involved. What’s missing in most delivered automations isn’t a fix for any one of them. It’s someone whose job is to notice.

Whose account, whose keys, whose admin?

This is the part a handover conversation usually skips, and it’s worth being specific about, because “we handed it over” and “you own it” are not the same claim.

Three questions decide which one you actually got:

1. Does the automation run inside your account, or the vendor’s? If it only runs inside a workspace or API account the vendor controls, you don’t own the asset. You own a dependency on that vendor staying reachable.
2. Do you hold the credentials, or does the vendor? An API key generated under the vendor’s org, used by an automation delivered to you, means revoking their access also breaks the automation. That’s not a handover. It’s a rental with a delivery date.
3. Is there documentation that survives the person who wrote it leaving? The same orphaned-owner problem Microsoft describes for a Power Automate flow applies to any automation with exactly one person who understands it. If that person is gone and nothing is written down, the automation is already orphaned, whether or not it’s still running today.

A real handover answers all three in writing, before you sign anything, not after something breaks.

Why do retainers exist, and are they worth it?

Because someone has to own the three mechanisms above, and “nobody” is a real, common answer. Retainer pricing in the AI automation category runs from roughly $500 to $8,000 a month, sold specifically against this gap: catching the auto-disable before a customer does, reassigning ownership before someone leaves, migrating off a model before its retirement date arrives.

A retainer earns its cost when it names that work specifically. A retainer that’s vaguely “ongoing support,” with no defined scope and no way to check whether anything was actually monitored, is the same accountability gap as the original build, now billed monthly.

What should you actually check before you sign anything?

Five questions, whichever vendor you’re evaluating, including us:

1. If the person who built this leaves, does it keep running, and who notices if it doesn’t?
2. Whose account do the credentials live in, mine or yours?
3. If the underlying model gets a deprecation notice, who’s watching for it, and what’s the plan?
4. Is ongoing support optional, or does the build stop working without it?
5. What, specifically, does a retainer cover, in writing, not “ongoing support” as a category?

If the answers to 1 and 2 are vague, the aftercare risk isn’t hypothetical. It’s already priced into the deal, you just haven’t been told the number.

What does SimplyCubed do here?

At handover you get the running system, full documentation, and Loom walkthroughs, not a dependency locked inside our account. Ongoing support is optional, from $1,000/mo, and the build is designed to keep working without it, not to require it. That’s a description of our own delivery practice, not a claim about how every vendor in this category handles the months after delivery.

If you already have an automation you inherited or aren’t sure about, the $1,500 Audit reviews it against the same questions above as part of mapping your workflows, and hands you a blueprint either way, whether you maintain it yourself or with whoever built it.