Everyone has read the AI failure story by now. MIT’s NANDA initiative found that 95% of enterprise generative AI pilots deliver no measurable P&L impact, with only about 5% reaching production at scale. RAND put a number on the pattern behind that: interviewing 65 data scientists and engineers, it found that more than 80% of AI projects fail, roughly double the failure rate of non-AI IT projects. Gartner has gone a step further and predicted that more than 40% of agentic AI projects will be scrapped by the end of 2027, citing cost, unclear ROI, and “agent washing” as the drivers.
That is the story everyone is telling. It is also, at this point, an old one.
There is a second failure mode nobody is tracking with the same rigor, because it does not show up in pilot-stage statistics at all. It is the AI feature that got past every one of those failure points. It shipped. Users touched it. In some cases it worked well enough that a product manager put it in a release announcement. And eighteen months later, quietly, someone disables it, or lets it drift into a broken state nobody bothers to fix.
I lead engineering delivery at TechnBrains, a custom software development and IT staff augmentation company, and I have watched this pattern repeat across healthcare, fintech, logistics, and real estate clients over the past two years. The stalled-pilot story and the retired-feature story are not the same failure. The first is a project that never earned its budget. The second is a project that did, and lost it anyway.
Shipping Is Not the Finish Line Anymore
The industry has spent three years optimizing for one metric: whether the AI feature shipped. Almost none of the internal scorecards I have seen track what happens twelve or eighteen months after that. There is no equivalent of a pilot-failure report for the feature that launched successfully and died in production, because “died in production” does not generate a press release. It generates a backlog ticket, then a deprecation flag, then silence.
S&P Global Market Intelligence’s 2025 survey of more than 1,000 enterprises found that the share of companies abandoning most of their AI initiatives jumped to 42%, up from 17% the year before, and that the average organization scrapped 46% of AI proof-of-concepts before they ever reached production. Read that carefully: it is a pre-production number. It says nothing about the smaller, easier-to-miss group of features that made it past that gate and got pulled back later. Across four verticals of delivery work, that second group is where I keep finding the more interesting story, because the cause of death is almost never “the model was wrong.”
Four Ways a Shipped AI Feature Actually Dies
Set the pilot-failure literature aside for a moment. Here is what actually kills a feature that already made it to production, based on patterns that repeat across unrelated codebases and unrelated industries.
- Lost ownership. The team that built the feature moves on to the next roadmap item, gets reorganized, or loses the one engineer who understood the prompt chain or the fine-tuning pipeline. Nobody is assigned to watch it. A feature with no named owner degrades in silence, because nobody is positioned to notice, let alone fix, a slow decline.
- Model drift with no monitoring behind it. An AI feature built against a snapshot of the world ends up answering questions about a world that has since changed underneath it. Without a drift-detection process, the first sign of trouble is a support ticket, then a pattern of support tickets, then a decision to quietly disable the feature rather than investigate it. Nobody diagnosed drift. Somebody just stopped trusting the output.
Case study: Zillow Offers, a $304 million quarter from unmonitored drift. When drift kills an internal forecasting feature, ticket volume goes up and the feature gets disabled. When it kills a consumer product built on top of one, the numbers become public. Zillow Offers, which entered iBuying in late 2019, used the company’s pricing model to buy and flip homes. Then the world changed underneath the model: a pandemic, and a housing market that skyrocketed and flattened in ways the training data had never seen. By Q3 2021, Zillow was booking a $304 million write-down, attributed in its own earnings statement to unintentionally purchasing homes at higher prices than its current estimates of future selling prices, after buying 9,680 homes while selling only 3,032. CEO Rich Barton’s post-mortem was a direct admission of drift: the company had been “unable to accurately forecast future home prices” by a much wider margin, in both directions, than any model had been built to handle. The program was shut down that November, along with 25% of the company’s workforce. The model did not fail loudly. It failed on a distribution shift nobody had instrumented for.
- Inference costs that were fine at demo scale and are not fine at production scale. A feature that costs a few cents per call in a pilot with fifty users can turn into a five- or six-figure monthly line item once it is rolled out to the full user base. When that bill lands on a CFO’s desk with no matching revenue or retention story attached to it, the feature gets cut on financial grounds, not technical ones. This is the failure mode that has the least to do with AI quality and the most to do with basic unit economics that nobody modeled before launch.
Case study: Amazon Just Walk Out, technology that worked and still got pulled. Amazon’s Just Walk Out is the purest example of a feature killed by economics rather than capability. The cashierless checkout system ran in Amazon Fresh stores for years and, at its peak, powered 27 of the company’s 44 Fresh locations. In 2024, Amazon removed it from every U.S. Fresh store and replaced it with smart carts. A Javelin Strategy & Research analyst later framed it as a distribution and scale problem rather than a technology one: these were commercial failures because the systems couldn’t be produced and distributed efficiently enough, at a scale that made them profitable, not because the technology didn’t work. The feature ran on a cost structure that could not survive contact with full-scale rollout, and it was swapped for a cheaper architecture rather than fixed. Notably, Amazon kept selling the technology to third parties, expanding to more than 360 locations across five countries, which suggests the model itself was fine. The math in Amazon’s own stores was not.
- Built for the demo, not for the workflow. This is the quietest killer. A feature designed to look impressive in a stakeholder review handles the happy path convincingly and falls apart on the edge cases that make up the bulk of real usage. It ships because the demo landed. It gets abandoned six months later because real users kept hitting the 20% of cases nobody stress-tested and routing around the feature entirely rather than filing complaints about it.
Case study: Apple’s notification summaries, a trust collapse three months after launch. Not every quiet disable is drift. Some are trust thresholds. Apple Intelligence launched in October 2024 with notification summaries as its signature feature, and the summaries worked well enough on the demo use case, condensing group chats into a single line. Then they were applied to news. In December 2024, the feature merged three separate BBC headline notifications into one false alert claiming Luigi Mangione had shot himself; other fabricated summaries in the weeks that followed included a false claim that Netanyahu had been arrested and a darts result that had not happened. After a formal BBC complaint, Apple disabled summaries for the entire News & Entertainment category in the iOS 18.3 beta in January 2025, roughly three months after launch. The response pattern is the same one that plays out after drift: the first sign of trouble was a complaint, the second was a pattern of complaints, and the response was to disable the feature for the category rather than fix it. Nobody diagnosed a failure mode. Somebody just stopped trusting the output.
The Same Sequence Shows Up in Every Vertical
The specifics vary by industry, but the sequence does not.
Healthcare: compliance surfaces the problem first. In healthcare delivery work, an AI intake or triage assistant is often the first casualty when a compliance review surfaces a data-handling question nobody resolved before launch. The feature does not fail technically — it fails procedurally — and gets switched off rather than fixed.
Fintech: the cost curve stops matching the value curve. In fintech, the more common trigger is inference cost: a document-processing or fraud-flagging feature scales from a controlled pilot to full transaction volume, and the cost curve stops matching the value curve well before anyone is watching for it.
Logistics: drift erodes trust before anyone notices. In logistics, model drift is the recurring cause; a route- or demand-forecasting feature trained on one season of data quietly loses accuracy as conditions shift, and by the time anyone notices, trust in the output is already gone. This is where a lot of our logistics software development work starts once a client calls us in to fix it: not a broken model, but a model nobody had been watching.
Line chart showing forecast accuracy assumed at launch (flat, ~95%) versus actual forecast accuracy declining across a 12-week peak season, crossing an 85% detection threshold around week 10 with no alert fired.
Chart: illustrative example built for this piece — swap in the client’s own predicted-vs-actual numbers before publication if real data is available.
Real estate and PropTech: ownership disappears with the team. In real estate and PropTech, lost ownership is the most common story: AI-assisted listing or valuation tools get built during a fast product push, handed off as the original team rotates onto a new initiative, and left with no one accountable for their upkeep.
The Klarna case: a public version of the same failure. The fintech version of this sequence recently played out in public. In February 2024, Klarna announced that its OpenAI-powered assistant was handling two-thirds of customer service chats — the equivalent work of 700 agents — in its first month, and the company subsequently went more than a year without hiring for customer support.
By May 2025, the cost curve and the value curve had diverged enough to force a public reversal: CEO Sebastian Siemiatkowski told Bloomberg that Klarna was hiring human agents again, explaining that the automation-first approach had leaned too heavily on cost as the deciding factor, which had produced “lower quality” support, and that customers needed a visible option to reach a human.
This is the same unit-economics failure wearing a different outfit. The feature did not stop working. The calculation of what it was worth, at full quality, at full scale, changed after launch, and the configuration that had been celebrated in a press release was rebalanced within fifteen months.
None of these are exotic failures. They are ordinary software maintenance problems that happen to be wearing an AI label, which is exactly why they are so easy to miss in a portfolio review built around launch counts rather than retention counts.
Why This Trend Gets Worse Before It Gets Better
The pressure that produced this wave of shipped-then-retired features has not eased. Enterprises are still moving fast on AI investment, and Gartner’s own polling found that only 19% of organizations describe their agentic AI investment as significant, with 42% calling it conservative and the rest still deciding. That hesitation does not stop features from shipping; it mostly stops anyone from budgeting for what happens after launch. Feature sprawl is the natural output of an industry that has built strong incentives to launch and almost none to maintain.
Combine that with RAND’s finding that the leading cause of AI project failure is not technical, but a mismatch between what stakeholders think they are asking for and what the technology can sustain, and the pattern makes sense: teams get the launch decision right often enough, and get the multi-year ownership decision wrong far more often, because nobody built a process for it.
What Engineering Leaders Can Do Differently
Three practices consistently separate teams whose AI features survive their second year from teams quietly retiring them.
Name an owner at launch, not after the first incident. Every AI feature needs a named, accountable engineer or team before it ships, with maintenance time budgeted the same way on-call time is budgeted — not treated as a volunteer effort layered onto someone’s existing roadmap.
Instrument for drift and cost from day one. A dashboard that tracks output quality trends and per-call inference cost against a defined threshold turns a silent failure into a visible one, months before it becomes a support-ticket pattern or a line item someone questions in a budget review.
Set a kill criterion before you build, not after users notice. Decide up front what “this feature is no longer earning its keep” looks like in measurable terms. Teams that skip this step end up making the retirement decision emotionally, months after the evidence was already there, instead of on a schedule they controlled.
The next wave of AI post-mortems will not be about pilots that never launched. It will be about the features that did everything right at launch and were never built to survive what came after them.