Why AI pilots die at handoff

I have now been called in to revive enough abandoned AI systems to say this with confidence: they almost never died of technical causes. The model was fine. The workflow was fine. The pilot demo went well and everyone applauded.

Then Monday came and nobody's job description included it.

The four gaps

One: no owner

The most common single cause. The system was built by a vendor, or by one enthusiastic person, or by a cross-functional group. After launch, the vendor contract ended, the enthusiast changed roles, and the group stopped meeting.

Ownership means one named person with access, budget, time, and it appearing in their objectives. Everything short of that is a hobby with a stakeholder list.

Two: no quality signal

The system fails silently, which is the specific danger of AI systems and the reason they need different operational treatment than ordinary software. It does not throw errors. It gets subtly worse, and everyone assumes it is still fine because nothing is red.

Without a human correction rate, an escalation rate, and an eval suite you can rerun, there is no way to answer "is it still working". The specifics are in LLM evals that actually catch regressions and AI agent observability.

Three: no runbook

The knowledge lived in the builder's head. When the first integration credential expired, nobody knew where it was configured, what the alert meant, or how to pause the system safely. So they turned it off, and off is a stable state.

Four: no operating budget

Pilots get funded from an innovation line. Production needs an operating line, covering model spend, hosting, and maintenance hours. When nobody approved the second one, the first invoice becomes a question, and questions without owners become cancellations. Realistic figures are in what AI workflow automation really costs.

The pilot proved it worked. Nothing in the pilot proved anyone would run it.

Design the handoff before the build

The fix is unglamorous and it happens at the start, not the end. Before the first line of code, four things get written down.

1. The owner, by name, with their manager's agreement that this is part of the job.
2. The success metric and its baseline, measured before the build so improvement is provable rather than asserted.
3. The operating budget, approved as a recurring line with a spend ceiling and an alert.
4. The maintenance rhythm. A monthly thirty-minute review of quality metrics and spend, on someone's calendar.

Every project I have shipped with those four in place was still running a year later. Most of the ones without them were not.

What the handoff itself contains

• Everything in your accounts, with your credentials, under your billing.
• A two-page runbook: what it does, cost per run, what alerts mean, how to pause it, how to change the three things you will want to change, who to call.
• A runnable eval suite with a documented command.
• Monitoring and alerts routed to a channel the team already reads. Not a new dashboard nobody opens.
• A spend ceiling and a kill switch.
• One recorded walkthrough, under thirty minutes.

The first ninety days

Handoff is a period, not an event. What I schedule:

1. Week one: daily check of the outcomes chart. Early input surprises show up fast.
2. Week two to four: weekly review of corrections, with every correction becoming an eval case.
3. Month two: first model version change drill. Run the suite, confirm the process works while it is still low stakes.
4. Month three: measure against the baseline and write down the actual result, good or bad. This is what earns the operating budget its second year.

If you are staring at a stalled pilot

Do not rebuild it first. Name an owner, get a quality signal in place, write the two pages, and get the operating line approved. Then look at the code. In most of the revivals I have done, the software needed less work than the organization around it.

If you want that assessed quickly and honestly, that is what the AI production readiness audit produces in 48 hours, and how I scope engagements is on the services page. For the version of this that shows up in front-desk projects, see AI receptionist vs AI intake agent.

Frequently asked