What is pilot purgatory?

The state where an AI pilot neither dies nor ships: impressive enough to keep funding, incomplete enough never to reach production, renewed quarter after quarter. The demo becomes the deliverable, and the organization mistakes motion for progress.

How do you know a pilot is in purgatory?

Three tells: the pilot has survived more than two review cycles without gaining real users, its blockers are the same ones from the last review, and nobody can name the date and criteria under which it either ships or stops. If success is undefined and the funding renews anyway, that is purgatory.

How does a pilot escape purgatory?

By replacing the extension decision with a binary one: define production (users, integrations, eval thresholds, an owner), scope the crossing as fixed work in weeks, and set a kill date. Ship it or stop it; both outcomes beat a third renewal.

Why do organizations tolerate pilot purgatory?

Because purgatory is politically cheap: nobody has to admit failure and nobody has to own production risk. The costs are real but diffuse, which is why the escape requires an explicit forcing decision rather than better intentions.

Pilot purgatory, and how to leave it

The short answer

Pilot purgatory is the state where an AI pilot neither dies nor ships: funded enough to continue, incomplete enough never to reach users, renewed by default because renewal is politically cheaper than either outcome. The tells are repeated review cycles, recycled blockers, and undefined success. The exit is a forcing decision: define production, scope the crossing in weeks, set a kill date, and accept that "stop" is a success.

Every operations leader has seen one: the pilot that has been "three weeks from ready" for three quarters. The industry eventually named the state, because it turned out to be not a mishap but an equilibrium, and equilibria need mechanics, not encouragement, to escape.

The state that earned a name

The numbers behind the name are documented across six reconciled studies: IDC counted roughly 4 proofs of concept in 33 reaching deployment, and Gartner predicted at least 30 percent of GenAI projects abandoned after proof of concept. But abandonment is purgatory's ending, not its texture. The texture is the in-between: a demo that works, a steering meeting that nods, a renewal that follows, and a production date that stays exactly one quarter away, forever.

The three tells

–Review-cycle survival without users. Two review cycles is a project finding its feet. Three or more without a single real user doing real work is a resident of purgatory.
–Recycled blockers. If this quarter's blockers (data access, security review, integration) are last quarter's verbatim, nobody owns the crossing; the crossing is its own project and it has not been staffed.
–Undefined success. Ask what would have to be true, by when, for the pilot to ship or stop. Purgatory's signature is that no one can answer, and the renewal happens anyway.

Purgatory is an equilibrium: renewal is politically cheaper than shipping and safer than stopping.

Why purgatory is stable

Purgatory persists because every actor is behaving rationally. Stopping means someone admits the initiative failed. Shipping means someone owns production risk: the integrations, the exceptions, the pager. Renewing means neither, at a cost diffuse enough to hide in a budget line. Vendors on hourly models have no incentive to break the loop, and internal champions have careers attached to the pilot's optimism. The result is the deployment gap's waiting room: capability proven, value indefinitely deferred. Even the model providers reached this diagnosis, which is why the labs now embed engineers rather than shipping more documentation at the problem.

The exit

The exit is never more enthusiasm; it is a forcing decision with three parts. Define production in writing: named users, the integrations, the eval thresholds, the owner who carries the pager. Scope the crossing as fixed work with a date measured in weeks, staffed by people whose payday is finishing. And set the kill date: if the system is not serving real users by then, it stops, with honors, and the budget moves to a workflow that deserves it. Both outcomes beat a fourth renewal, because the failure modes all compound with time while the escape only needs one binary afternoon. Organizations too close to their own pilot to force the decision can borrow the forcing function: that is precisely what a fixed-scope crossing engagement is for.