What the 95% failure rate of GenAI pilots actually teaches us.

Executive Summary

Most enterprise GenAI pilots fail. The number that has rattled boardrooms is 95% — published in MIT's State of AI in Business 2025report (the NANDA initiative) in mid-2025, and corroborated by Gartner's prediction that more than 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value, and inadequate risk controls.^[1][2]

The standard explanations — bad data, weak prompts, no executive sponsor, unclear ROI — are not wrong. They are also not the point.

The point is that the industry is trying to retrofit a fundamentally new computing paradigm onto a development process designed for the old one. We are bolting autopilot onto a car that was never wired for it, and then concluding that autopilot doesn't work. The MIT authors call this the "GenAI Divide" — a learning gap between tools and enterprise workflows. Gartner calls it "agent washing" — vendors rebranding chatbots and RPA as agents without any meaningful architectural change. Both diagnoses are pointing at the same underlying problem.^[1][2]

This paper argues something different about the way out. The 95% failure rate is not telling us that GenAI is overhyped. It is telling us that we are at the same inflection point Tesla reached when it stopped treating self-driving as a feature on top of a normal car and started treating the car itself as a self-driving platform with manual override.

Translated to product development: teams that win the next decade will build skills-first, no-code-first, agent-native products — and keep code-level access available for inspection, override, and integration with the existing world. Not the other way around.

The Tesla Analogy: Three Modes, Two Paths

Every Tesla has three modes of operation:

• Manual. The driver controls everything. The car is a car.
• Autopilot. The car handles lane-keeping, speed, basic traffic. The driver supervises.
• Full Self-Driving (FSD). The car drives. The human is a passenger who can override.

What's interesting is not that Tesla has three modes. What's interesting is that Tesla built the entire vehicle architecture — sensors, compute, OTA updates, the data flywheel — around the assumption that FSD is the destination. Manual is the fallback. Autopilot is the bridge.

Compare that to a legacy automaker bolting "lane-keep assist" onto an internal combustion vehicle designed in 2015. The feature might technically work. But the rest of the car — supply chain, dealer network, software update process, engineering org — is built for manual driving. It feels like a feature, not a paradigm.

This is exactly where most enterprise software development is right now with GenAI.

Path 1: The Old Path

Build the product the way you always have. Then add an "AI feature." A copilot. A chatbot. A summarization endpoint. The AI sits on top of the product like a hood ornament. The 95% failure rate lives here. MIT's research found that the failure rarely traces back to model quality; it traces back to integration into existing workflows, brittle pilots that never reach production, and the absence of any architecture designed to learn or adapt.^[1]

Path 2: The New Path

Build the product as an agent-native system from the beginning. Skills, not features. Composable capabilities, not codepaths. The agent is the product. Code exists, but it's the override — the manual mode — not the default.

Both paths are real. But teams that pretend Path 1 will get them to Path 2 by accretion are repeating the legacy automaker mistake. You don't get to FSD by adding features to a manual transmission. You rebuild the platform. Gartner reinforces this: "rethinking workflows with agentic AI from the ground up is the ideal path to successful implementation."^[2]

Why the failure rate is so high

When you look closely at why GenAI pilots fail, the failures cluster into a small number of patterns. MIT's research, drawing on 150 leader interviews, 350 employee surveys, and 300 public deployments, identified the structural ones.^[1]

The pilot is a demo, not a system. Impresses in a 20-minute showcase. Falls apart on day two of real use. No durable memory, no integration with systems of record, no error handling, no observability. A magic trick, not a product.

The agent has no real authority.It can suggest, summarize, draft. It can't actually do anything. Every action requires a human to copy the output into the real workflow. The productivity gain is marginal because the integration cost was punted.

The team measured novelty, not work completed.Success metrics looked like "users tried it" rather than "tasks completed without human intervention." MIT's data shows the highest ROI in enterprise GenAI is in back-office automation — measured by completion, not engagement — but most pilot budgets get spent on sales and marketing demos that look exciting and deliver less.^[3]

No one owns the agent's decisions.When the agent gets something wrong, there's no clear answer to who is accountable, who reviews, who corrects, who improves it. The pilot dies the moment it makes a visible mistake.

The agent has no peers.A single agent trying to do everything, with no orchestration layer, no specialized siblings, no escalation path. Gartner's research highlights persistent memory, multi-agent coordination, and autonomous goal formation as the markers separating genuine agentic systems from rebadged chatbots.^[4]

Each of these is fixable. None of them is fixable by writing more prompts. They require rebuilding the substrate.

The new substrate: skills, not features

The most important architectural shift happening right now is the move from features to skills.

A feature is a piece of functionality wired into a specific codepath, exposed through a specific UI, owned by a specific team. Features are the unit of construction in traditional product development.

A skillis a composable capability — a discrete thing the agent knows how to do, described in natural language and structured metadata, available to be invoked whenever the situation calls for it. Skills don't live in a UI. They live in a registry. The agent figures out which skill to use, when, and how to combine it with others.

This is not a thought experiment. Anthropic released Agent Skills as an open standard in late 2025 — folders of instructions, scripts, and resources that agents discover and load on demand. The format is now adopted across Claude, Cursor, Codex, and a growing list of agent platforms.^[5][6] OpenAI, Google, and the open-source community are converging on similar primitives. The skills layer is becoming the way agents are built.

This shift is more consequential than it sounds. It changes how you build, how you ship, how you measure, how you organize teams, how you sell.

The aggressive position: skills-first, no-code-first

Here is the bullish case, stated as plainly as possible.

Build skills-first. Build no-code-first. Be aggressive about it.

The conventional path is to build the product in code, then add an AI layer on top, then maybe migrate toward agent-native architecture in version 3 or 4. This path is comfortable. It is also slow, expensive, and almost always produces a product that is structurally a Path 1 product with Path 2 marketing.

The aggressive path is to flip the priority. Skills first. No-code orchestration first. Treat the agent as the product. Treat code as the manual override.

Why be aggressive:

• Velocity compounds. A team that ships skills can iterate 10x faster than a team that ships features. That gap widens every quarter.
• The bottleneck moves to the right place. Engineering capacity stops being the constraint. Domain clarity becomes the constraint.
• Customer value shows up sooner. A skills-based product can deliver real outcomes in weeks where a code-based equivalent would take quarters.
• The architecture is future-proof.Skills compose. Features don't. A skills-based product gets better as the underlying models improve, automatically.
• The economics flip. When the trunk does the work, you can charge a fraction of conventional rates and bake maintenance in. The unit economics that fall out of this approach are why we can offer Door 01 at 30% of agency cost.

MIT's data quietly supports this: the 5% of pilots that succeed share a pattern of being deeply integrated into workflows and adaptable rather than static.^[1] The architecture choice is doing more of the work than the model choice.

Teams that hedge — "we'll go skills-first eventually, after v1 in code" — almost always end up with a v1 that locks them out of Path 2. Sunk cost takes over. Commit, or don't bother.

The pragmatic position: keep code available, but don't lead with it

The aggressive position above is correct but not sufficient. Real teams operate where the new approach is unproven, the old is trusted, and people need to look under the hood when something goes wrong.

The principle is trust but verify. Skills are the default. Code is the override. Both are available, but the priority is clear.

• Code is inspectable, not central.Read the underlying code, run it locally, test, modify. The code is real. It's just not the unit of construction.
• Fallback paths are first-class. When a skill fails, the system falls back to a tested code-level path. The fallback is part of the architecture, not a hack.
• Observability is over-invested.See exactly what the agent did, why, what skills it invoked, what the outcomes were. This is what makes "trust but verify" actually work.
• Step down to manual at any time.Custom integration, deterministic behavior, regulated workflow — drop into code and ship it. The agent doesn't lock you in. Our Export add-on is the formal expression of this principle: take the code, run on your own infrastructure, leave any time.

The mistake to avoid is letting the existence of manual mode slow down the FSD investment. Training wheels are for confidence. They are not the destination.

Connecting to the existing world

The third axis — the one most engineering leaders ask about first — is integration. The real world has SaaS systems, APIs, third-party tools, legacy ERPs, mainframes nobody wants to touch. A skills-first product that can't talk to any of that is a toy.

The good news: connecting to the existing world is exactly what the new architecture is designed for.

• SaaS integration.Skills wrap SaaS APIs. From the agent's perspective, "update the CRM" is a skill. From the SaaS vendor's perspective, nothing has changed.
• API-level integration. Anything with REST or GraphQL becomes a skill. The skill is the wrapper translating intent to API call.
• Co-opting third-party tools. Sometimes the right answer is to wrap an existing tool — a search engine, an analytics platform — as a skill, rather than rebuild.
• MCP and the open standards layer. The Model Context Protocol, plus the Agent Skills standard, makes composition portable. Your investment in skill authorship is portable across model vendors.^[5][6]

The mental model: the agent is a coordinator. Skills are how it gets things done. The existing world doesn't need to be rebuilt — it needs to be wrapped, exposed, and made available. You don't rip and replace. You wrap and orchestrate.

What this means for VPs of Engineering and CTOs

Don't let training wheels slow you down. The fact that you can fall back to code is a feature, not a strategy. Build skills-first. Build no-code-first. Use code as the override path, not the default path.

Make the fallback excellent.Trust requires the option to verify. Build code-level inspectability into every skill. Build fallback paths into every agent decision. Build observability that lets the team see what's happening at every layer.

Wrap the existing world; don't fight it. Skills-first architecture is the cleanest way to integrate with everything you already have.

Reorganize for skills.If the unit of construction is a skill, the team structure that built around features doesn't fit anymore. Skill authors are different from feature engineers. Domain experts become more important.

Build conviction in the team before you bet the company. Run a skills-first build alongside a traditional build for a small project. Compare velocity, outcome quality, team experience honestly.

Pick the FSD destination on purpose. What does your product look like when the agent is doing 90% of the work? Answer that question first. Work backward from it.

The bottom line.

The 95% failure rate is not a problem with GenAI. It's a problem with how teams are trying to ship GenAI inside a product-development process that wasn't designed for it. MIT and Gartner, read together, point in the same direction: the technology works; the architecture and operating model around it usually don't.^[1][2]

Tesla didn't get to FSD by adding sensors to a Camry. They rebuilt the car. The teams that win the next decade will do the same.

The path is clear. Skills first. No-code first. Code available for inspection, testing, and fallback. Existing systems wrapped, not replaced. Training wheels acknowledged but not honored. Trust earned by verification, then converted into the conviction to run at full speed.

A note on how we got here

Everything in this paper comes from doing it, not theorizing about it.

At OnePgr, we spent the last couple of years tinkering with the new agent stack — models, MCP, skills, orchestration patterns — while continuing to build and run our product. Somewhere in the middle, we realized the tinkering had produced something more useful than another feature in our existing product. It had produced a way of building products.

We turned that into 1nceptionAI — a skills-based product development platform built around exactly the principles in this paper. Skills are the unit of construction. Code is the manual override. The agent is the product. Existing SaaS, APIs, and third-party tools get wrapped, not replaced. Trust but verify is built in.

The economic consequence — that we can charge 30% of conventional agency rates and still bake maintenance in — wasn't the goal. It was the side effect. When the trunk improves and every fork inherits, the unit economics of building software change shape. The price is just the trunk doing its job, expressed in dollars.

If you'd like to be considered, reach out. We'll start with a conversation about what you're trying to ship and whether the skills-first approach actually fits the problem. If it does, we'll show you what we've built and figure out together whether early access makes sense.

References

1. [1] Challapally, A. et al. The GenAI Divide: State of AI in Business 2025. MIT NANDA initiative, 2025. Reported by Fortune: "MIT report: 95% of generative AI pilots at companies are failing", August 2025.
2. [2] Gartner, Inc. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." Press release, June 2025.
3. [3] Trullion analysis of MIT NANDA findings: "Why 95% of GenAI projects fail — and why the 5% that survive matter." September 2025.
4. [4] XMPro analysis of Gartner's agentic AI research: "Gartner's 40% Agentic AI Failure Prediction Exposes a Core Architecture Problem." July 2025.
5. [5] Anthropic. "Equipping agents for the real world with Agent Skills." Engineering blog, 2025.
6. [6] Agent Skills open standard, agentskills.io, and Anthropic's public skills repository, github.com/anthropics/skills.

Rajiv Saxena is the founder and CEO of OnePgr. While building OnePgr's own products, his team developed 1nceptionAI — a skills-based product development platform now in early access with a select group of teams building on the same paradigm. This paper reflects what they learned along the way.