Why AI projects fail: five causes behind the 42% abandonment rate

In 2025, S&P Global surveyed companies about their AI programs and 42% said they had abandoned most of their initiatives. The average company had scrapped 46% of its pilots. That is the industry we work in, and the question of why AI projects fail has a less interesting answer than the marketing suggests. The causes are boring, and they repeat.

The two numbers worth carrying into a budget meeting

The S&P figure is the first. The second comes from the MIT NANDA report of the same year: projects built with an external partner reach deployment about 67% of the time, against 33% for internal builds. Which kind of partner, and what an agency, a freelancer and an in-house engineer each cost, is a separate question from whether to use one. The gap is mostly contractual. A paid external project has a scope, a deadline, and someone who does not get paid until it works; an internal pilot has none of those unless somebody insists.

Our own version of that pattern comes from six systems, which is too few to call a finding, so take it as a hypothesis. Every one still running answers a question somebody was already asking every week, and not one of them started life as a platform. Scope discipline appears to be doing most of the work that usually gets credited to the technology choice.

Put the survey numbers next to that and the projects that live share a shape: small, short, and owned by somebody who does not get paid until it works.

A demo proves less than it appears to

Almost every failed project we have been called into had a working demo behind it. Somebody sat in a room, watched the thing do the job, and signed off. The demo was real. It was also running under conditions that never occur again after the meeting ends.

A demo runs on ten records chosen because they are clean. One path through the logic gets exercised, the happy one. A person watches every run, and if something looks wrong they rerun it before anyone else notices. No one is counting the tokens.

Production runs on everything else. Here is what changes on the first Monday:

• Records arrive with fields missing. The prompt that read the customer's industry from a CRM field now reads an empty string 30% of the time, and the model, being helpful, invents an industry.
• The same company appears three times, spelled slightly differently. Deduplication was never in scope because the demo data had no duplicates in it.
• People use the system in ways the builder did not picture: pasting a whole email thread into a field sized for a sentence, replying to the automated message expecting a human, answering a yes or no question with three paragraphs, uploading a photograph of a printed form.
• A vendor changes a schema. A field renamed on their side breaks a mapping on yours, and nothing announces it.
• Nobody is watching. The run that would have been caught and rerun in the demo now goes to a customer.

Each of those is a specific, nameable failure with a specific fix, and none of them is a risk in the abstract sense that risk registers use. They are the ordinary weather of production, and a project that has not been designed against them is going to meet them anyway, in front of a customer, in month two.

Five causes of death

1. No owner

The most common cause and the least technical. A workflow gets built, works in the demo, and belongs to nobody. The person who championed it goes back to their real job. Six weeks later an API changes, the automation stops silently, and nobody notices until the pain that justified it comes back. A system without a named owner is already dead. It just has not stopped moving.

The extreme version arrives on our desk regularly. Three of the six rescues we have scoped began the same way: the original builder was gone, and every account the system ran on was in his name. The OpenAI key, the automation platform login, the Google Cloud project, the domain. In one case the client could see the automation failing in a dashboard and had no credential that would let anyone open it. That project did not die of a technical fault. It died because it had become nobody's job, and the person whose job it had been was no longer answering email. If you are in that position now, what to do when the freelancer disappears is the practical version of this section.

2. Failure is invisible by default

Automations fail quietly. A token expires, a form field is renamed, a model update shifts behavior, and the platform's own dashboard is the only place that knows. It is the failure we find most often when an automation has died quietly in production.

We were called into a lead-routing flow that ran about 200 times a day and failed roughly once a day. Its error alert was wired to a Slack channel that had been archived months earlier. Nobody had seen one. The client's first evidence that anything was wrong came from a salesperson asking why a form submission from a named prospect had never reached anyone, and by then the flow had been dropping leads for most of a quarter.

Loud failures are the good case. The dangerous shape is the run that succeeds while doing nothing: a filter returns zero rows, every node downstream of it is skipped because there is nothing to act on, and the platform writes a green tick in the execution log. Your monitoring, if you have any, reports 100% success. That pattern has its own page, the workflow that runs but nothing happens, because it accounts for more silent damage than outright errors do. The related question of why an automation stopped working is usually easier, since at least something is complaining.

Ask any vendor how you will find out when it breaks. Silence is an answer.

3. The wrong thing was automated

Companies skip the invoice follow-up automation worth $2,000 a month and fund the "AI platform" worth a press release. The moonshot has ten integration points, no agreed success criteria and a nine-month timeline, which is to say ten ways to die.

There is a subtler version that catches careful companies too. If three people in a department do the same process three different ways and have never had to reconcile that, automating it encodes the disagreement in software. The automation then produces outputs that one person considers correct and another considers wrong, and the argument that should have happened in a meeting happens instead as a bug report against a system nobody wants to defend. Automation makes a process faster and more consistent. It has no opinion about whether the process was right.

This is the strongest argument for paying for a diagnostic before paying for a build. Somebody outside the department has to sit with the people doing the work, write down what actually happens rather than what the process document claims, and get the disagreements on paper while changing them is still cheap. That is the job of an AI Opportunity Audit, and what a paid audit contains spells out the deliverables.

The least glamorous system we run is a document generator for a hydrogeology firm. It produces technical paperwork for boreholes. As of August 2026 it has generated 168 documents and holds 349 boreholes on file, one person at the client checks its output, and the client came back for a second build at EUR 3,300. Nobody will write a conference talk about it, which is roughly why it works.

4. A tool pushed past its limits

Language models are pattern machines. Projects fail when a model is placed somewhere that demands 100% accuracy with no human checkpoint: unattended pricing decisions, or anything where one bad output costs more than a month of good ones. The fix is in the workflow design. The model drafts, a person approves, and that stays in place until the error rate has been measured on real data, which is what evals for business automations are for.

The model is rarely the problem. In six systems we run in production, including our own voice receptionist handling live calls, the incidents that woke somebody up came from expired credentials, rate limits, malformed input and a third-party outage. The nearest thing to a model failure was an agent that stopped calling a tool after a prompt edit, which is a configuration problem with a known shape.

5. Nobody counts value monthly

Pilots get judged on whether they work, and production systems on whether they pay. If no one can report something like "this handled 640 items and saved about 53 hours in July," the system's value is a feeling, and feelings lose budget fights. Half-dead projects survive for quarters this way. The subscriptions get paid and nothing gets counted.

Some failures cannot be diagnosed from a description

Questions that describe a visible error can sometimes be answered from the description alone, because a stack trace or an HTTP status narrows the field. Questions that describe an absence cannot. "It runs, it says success, nothing arrives" is a symptom whose cause lives in the execution history: the payload at each step, and the run where the filter first returned nothing.

We once put a forum statistic here to make that point and got it wrong twice, so it is gone. The argument stands on its own without one. Nobody reading a description has your execution history, which is why the thread fills with guesses and why a support arrangement that includes access to your runs beats one that includes an email address.

The quiet failures are the ones that kill projects.

They are also the reason a support arrangement that includes access to your execution history beats one that includes an email address.

Running costs arrive after the invoice

A system can work perfectly and still get switched off in month four, because the build price was a single number everyone agreed to and the running cost was a series of small charges nobody assigned to anyone. Token spend that scales with volume rather than with the quote. Telephony minutes on a voice agent, where the difference between a 40-second call and a four-minute call is the whole margin, which is why voice agent costs deserve their own arithmetic. Platform operation charges on n8n or Make, counted per run, and a run happens whether or not the run does anything. Hosting, monitoring, error tracking, a database, a domain.

None of that is expensive on its own. Together it is a monthly number that somebody has to have budgeted for before launch, and the full accounting is in the running costs nobody mentions. A project that produces real value and costs $340 a month nobody planned for will lose the argument in a cost review to a project that produces nothing and costs zero.

What a surviving project looks like

The systems that make it past their first year look boringly similar from the outside. Every one of them has a named person who would be embarrassed if it broke, an alert that reaches a human being in a channel that is still open, and a number reported monthly that somebody outside the technical team understands.

Before launch, the questions on the production-ready checklist have real answers rather than intentions: whose accounts the credentials live in, what happens when the vendor API returns a 500, where the logs go, who gets the message at 2am and what they are supposed to do with it. After launch, someone is paid to watch. That is the actual content of a care arrangement, and what a care retainer should include is worth reading before you agree to one, because a retainer that covers only bug fixes leaves the silent failures exactly where they were.

When an existing system is already past saving, the honest first step is deciding whether to repair or start again, which we cover in fixing against rebuilding a broken AI system.

Staying out of the 42%

1. Buy small proof first. One painful workflow with a measurable cost, delivered for a fixed price, since fixed price rather than hourly forces the scope conversation to happen before the spending does. If a $5,000 build cannot prove value, a bigger program will not either; it will only take longer to admit it.
2. Time-box to 90 days and attach a kill decision. If it is not producing measured value by then, stop it or halve its scope. A caveat from our own work: one of our current builds is waiting on a third party to open its API, and a strict 90-day clock would fail it for reasons that have nothing to do with scope. Pause the clock for external blockers, and note that you did.
3. Decide the monthly number before you build. Items processed, hours saved, response time, revenue touched. Put the monthly report in the contract, where it is also what a care retainer should produce once the build is live. A vendor who resists is telling you what they expect the number to show.
4. Name the owner on day one. If you cannot, you are not ready, and a decent vendor will say so.
5. Ask, before you sign, how the vendor will find out that something has broken, and how you will find out that they found out. The questions worth asking before hiring an AI agency cover the rest of that conversation.

Our opinion, for what it is worth: the abandonment figures are an argument against how automation is usually bought, big and vague and unmeasured, and say little about the technology. If you would rather start with a small measured proof, the AI Opportunity Audit exists to find the boring workflow with a number attached, and to put that number on paper when there is none.