Section 1
Failure here is a design outcome, not bad luck
When an automation gets retired quietly after four months, the explanation usually lands on something technical. The tool was immature. An API changed. The team ran out of time. Look further back and you normally find a decision made in week one. Someone picked a workflow because it was easy to get access to, not because the delay in it cost anything. Or no success criterion was written, so nobody could say whether it worked, which means nobody could defend the budget. Or the output landed in a place no downstream system was obliged to accept, so it became an optional extra people stopped opening. None of that is bad luck. Those are choices with predictable consequences, made before anyone opened a vendor comparison.
Section 2
The five ways it usually breaks
The wrong problem. The team automates the visible task rather than the expensive wait, and the business feels no difference. No baseline. Nothing was measured beforehand, so no improvement can be argued afterwards and the project dies at the first budget review. Data that is not ready. Fields are free text, documents are inconsistent, historical records contradict each other, and the system faithfully reproduces the confusion at speed. No exception path. The normal case gets handled and everything odd falls into a queue nobody owns, so the exceptions quietly become a second job. No accountable human. When an output is wrong there is no name attached to fixing it, and trust drains in about a fortnight. Inside larger companies a sixth appears: the workflow gets automated but the incentives around it are left intact, so the people still measured on the old process route around the new one.
Section 3
A pre-mortem you can run in an hour
Before building, assume the project has already failed and write the reason down. The model below turns that into something you can run with the team in an hour: name the wait, name the baseline, name the exception owner, name the date you will kill it. Teams that do this well usually learned it from other operators rather than from vendors, which is what [AI Automation Communities and Learning Resources](/blog/ai-automation-communities-and-learning-resources) is for.
Section 4
How to fail cheaply, on purpose
The goal is not zero failures. It is failures that cost a fortnight instead of a year. Cap the first build in scope and in time: one workflow, a small sample of real inputs, a human reviewing every output, and a date on which you either extend it or stop. Test against examples where you already know the right answer, and load the awkward ones in deliberately. A system that handles the clean cases and collapses on the messy quarter of the volume has not passed, it has been flattered. Write the kill criteria before you start. A project with no stopping rule does not get stopped. It gets abandoned slowly, which costs more and teaches nobody anything.
Section 5
The failures that reach a customer
Internal failures cost time. External failures cost trust, and trust does not recover on the same schedule. Treat anything touching money, employment, legal exposure, safety, or a customer's own record as a separate class of system. Know what it can read and what it can change. Log the decisions and the escalations so a bad outcome can be reconstructed instead of argued about. Keep a named human on the final call. Disclose that AI is involved, because a customer discovering it later is what turns an error into a grievance. The customer-facing half of this is covered in [Startup Success: How AI Automation Transformed Our Business](/blog/startup-success-how-ai-automation-transformed-our-business).
Section 6
What the research says
The failure literature is now large enough to treat as a curriculum. RAND interviewed 65 experienced data scientists and engineers and estimated that more than 80% of AI projects fail, roughly double the rate of non-AI IT projects, ranking misunderstanding of the problem ahead of any technical limitation as the leading root cause (RAND, 2024). The pattern sharpened with generative AI: S&P Global found the share of companies abandoning most of their AI initiatives rose from 17% to 42% in a single year, with the average organization scrapping 46% of proof-of-concepts before production (S&P Global, 2025). An MIT-affiliated study arrived at the same place from the pilot side. Roughly 95% of generative AI pilots delivered no measurable P&L impact, attributed to a learning gap in integration rather than model quality, and externally sourced tools succeeded about twice as often as internal builds (MIT NANDA via Fortune, 2025). Looking forward, Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027 on cost, value and risk-control grounds, and 60% of AI projects without AI-ready data to be abandoned through 2026 (Gartner, 2025). Read across all four, the finding is consistent and slightly humbling. Failures concentrate in problem definition, data readiness and integration. Almost never in the model.
Section 7
Signals the project is already dead
You rarely get an announcement. You get symptoms. Usage drops off after launch week. The exception queue grows faster than the automated volume. Someone maintains a private spreadsheet that shadows the system. Approvals get clicked without being read. Nobody can name the metric it was supposed to move. Two or more of those and the honest move is to stop, write down what you learned about the workflow itself, and spend the money on a wait that actually costs the business something. A retired automation with a written lesson is a cheaper outcome than a maintained one that nobody opens.