Why Most AI Agent Pilots Die Before Production

The number floating around industry analyses this year is brutal: roughly 88% of AI agent pilots never make it to production. Having watched several of these pilots up close, I believe it — and I want to push back on the most common explanation for it.

The agents aren't the problem. The demos are real. An agent that triages issues, drafts fixes, runs the tests, and opens a PR genuinely works in a sandbox, and it works impressively. What kills the pilot is the meeting three weeks later, when someone from security asks a short list of questions nobody prepared for: Which repositories can this thing write to? What secrets can it read? Who approves its output? What's the budget cap? What happens when it does something wrong, and how would we even know?

Silence, followed by a six-month pause, is how 88% of pilots end.

Agents are a permissions problem wearing a technology costume

Coding assistants were easy to govern because a human sat between every suggestion and every consequence. The engineer was the control layer. Agents remove that comfort. A long-running agent operating on your codebase is functionally a new kind of engineer on your team — one that works at machine speed, never gets tired, and has no judgment beyond what you've explicitly given it.

Nobody would onboard a human engineer without deciding what repos they can touch, what environments they can reach, and who reviews their work. Yet teams routinely pilot agents without answering any of those questions, because the pilot started as a tooling experiment rather than an organizational decision. The pilot then can't graduate, because graduation requires exactly the answers nobody produced.

What the surviving 12% do differently

The pilots that reach production share a pattern, and it isn't better agents.

They scope before they pilot. Access boundaries — which repos, which secrets, which environments, what spend — are written down before the first run, not negotiated after security gets nervous. Boring, and decisive.

They pick reversible work first. Test generation, documentation, dependency upgrades, draft PRs that humans merge. Nothing customer-facing, nothing that writes to production. This builds the trust and the audit trail that expansion requires.

They make output reviewable by default. Every agent action lands as a PR, a diff, or a logged artifact a human can inspect. If you can't reconstruct what the agent did and why, you don't have an audit problem waiting to happen — you already have one.

And they treat the security team as a design partner, not a gate at the end. The teams that bring security in at week zero ship agents. The teams that bring them in at week six write postmortems about promising pilots.

The mid-size advantage

If you're a 200-person company, this is one of the few areas where you have a structural edge over the enterprises. You can get engineering, security, and finance in one room this month and produce an actual agent policy — access tiers, approved task types, spend limits, review requirements — in a week. A 20,000-person company needs three quarters and a steering committee to do the same.

Agentic development is coming regardless; the delegation patterns are already standard practice at the frontier. The question is whether your organization meets it with a framework or with an incident. The 88% number isn't a verdict on the technology. It's a measurement of how many teams skipped the unglamorous work.

If you're trying to get leadership aligned on what that framework should look like, that's the conversation our executive AI brief is designed to start.