The Pilot Graveyard: Six Reasons Agentic Projects Get Cancelled

The demos are getting better every month. Anyone can stand up something that looks like an autonomous agent in an afternoon, and the boardroom enthusiasm is real. On the surface, adoption looks like it is accelerating.

However, the numbers underneath tell a harsher story. Roughly 60% of companies report no measurable value from AI (BCG), around 1% consider themselves AI-mature (McKinsey QuantumBlack), and about 40% of agentic-AI projects are projected to be cancelled by 2027 (Thoughtworks). That is a graveyard, and the striking thing about it is how little variety there is in the causes of death. Projects do not fail in a thousand creative ways. They fail in about six, and every one of them is avoidable if you design for it before you start.

Here are the six, and what to do instead.

Reason 1: They scaled a laptop automation, not an architecture

The most common cause of death is mistaking a working demo for a production system. A staff-built script clears the demo, someone declares victory, and the plan becomes "scale this."

But a laptop automation and a production agent are separated by a chasm that scaling does not cross. The automation never had to handle identity, least privilege, drift, audit, or untrusted input, because on one machine none of those were in scope. Scaling the script just scales its missing foundations.

How to avoid it. Treat the demo as evidence the idea has merit, not as the system. Before scaling, ask what the thing needs that the laptop never gave it: an identity, a boundary around what it reads, a record of what it decides. If those are missing, you are not scaling a system, you are scaling a liability.

Reason 2: The agent couldn't reach the context it needed

The second graveyard is quieter, because the agent works perfectly, it just cannot see enough to matter. Its context lives across the CRM, the core system, the document store, and the human who knows the one exception. The organization never built the layer that lets an agent reach that context safely.

So the project splits into two bad options. Either the agent stays too isolated to be useful, or it gets wired in with broad, standing credentials that the security board will not approve. Both roads lead to cancellation.

How to avoid it. Budget for the context layer as real work, not plumbing. The agent should reach your systems through typed, named capabilities, act under its own least-privilege identity, and be structurally unable to treat untrusted data as an instruction. If that layer is not in the plan, the model choice is irrelevant.

Reason 3: It couldn't pass the security board

Plenty of pilots die not in production but in the homologation review, and the finding is almost always the same: the agent runs under a developer's personal token with standing access to production. That is a skeleton key, and no serious security board signs off on it.

The project was technically impressive and structurally unapprovable. The team optimized for "does it work?" and never asked "can it pass review?", which in a regulated enterprise is the question that actually gates go-live.

How to avoid it. Design for the security board from day one, not as a final hurdle. Each agent runs under its own non-human identity, with short-lived, least-privilege credentials and an explicit egress allow-list, so there is no static secret to steal and the identity can only do the few things it was scoped to do. Map every agentic risk to a named, testable control, so the committee signs off on a control, not an assurance.

Reason 4: IT governance couldn't govern a system that drifts

Some projects clear the security board and then get cancelled a few months in, when governance discovers it has no way to hold the thing. The change board was built for deterministic software: same input, same output, change-controlled releases. It has no mechanism for a system that changed because a model updated overnight and nobody shipped anything.

The result is a project that looked governed, because it went through the normal process, and turns out to be ungovernable in practice. It passed the wrong gate.

How to avoid it. Add a governance layer built for agents alongside your IT governance, not on top of it. Agents earn autonomy on a graduated ladder gated by evals, drift monitoring can demote an agent automatically the moment it moves off its threshold, and the unit of governance becomes each decision, not each release. Deterministic governance keeps doing what it is good at. The new layer owns drift.

Reason 5: The risk committee couldn't approve a black box

The fifth graveyard is a committee that keeps saying no. The system may work, but no one can explain, after the fact, why it made a specific decision. Without that, a risk committee cannot approve it, and a project that cannot get approved cannot scale.

This is where "the model is impressive" stops mattering. The committee is not evaluating the model. It is evaluating whether it can defend the system to a regulator, and it cannot defend what it cannot inspect.

How to avoid it. Make every decision inspectable before it commits. Each one leaves an append-only, hash-chained evidence record, written before the decision takes effect, so if the evidence cannot be written, the decision does not happen. Consequential calls resolve to a human by policy, and the compliance rules are code your compliance team owns and signs. Then the committee is signing off on a documented, testable control, which is a yes it can actually give.

Reason 6: They bet big, measured nothing, and had no exit

The final cause of death is a project-shape failure, and it kills good architectures alongside bad ones. The organization commits to a broad rollout up front, never establishes an auditable baseline, never sets a go/no-go gate, and so has no honest way to tell whether the thing is working. Months of cost accrue with no way to prove return, and eventually someone pulls the plug on a project that might have been fine, because nobody could show that it was.

How to avoid it. Do not bet the enterprise to test the architecture. Commit to a Foundation instead: one high-consequence process, taken to a governed agent in production in roughly six to eight weeks, measured against an auditable baseline, with an explicit go/no-go gate before anyone commits to scale.

A rough sequence makes it concrete. In the first 30 days, prove the boundary: stand up the context layer and identities for that one process, with the agent in Shadow, proposing while humans decide. In days 30 to 60, prove the governance: turn on the evidence trail and the policy decision point, move the agent to Supervised, and let the risk committee inspect a real control instead of a slide. In days 60 to 90, prove the value at the gate: measure cost per unit, latency, quality lift, and concordance with human review against the baseline, and decide to scale on evidence.

If it clears the bar, you scale on proof. If it does not, you have spent eight weeks and learned something real with no production exposure, which is a far better outcome than discovering it after a broad rollout.

The reframe

Notice what the six reasons have in common. Not one of them is "the model was not good enough." Every death in the graveyard is architectural or procedural: a missing layer, an unapprovable identity, a governance model that cannot see drift, an unauditable decision, or a bet placed before anything was proven.

So the question is not "are we behind on AI?" It is on our single most consequential process, do we have an identity for the agent, a boundary around what it reads, a record of what it decides, a governance layer that can see it drift, and a gate we set in advance? And if not, what is the smallest Foundation that would let us find out for real, before we bet on the second process?

If you want an honest read on where one of your processes would land, book a meeting.