what the stopped projects know

the most useful ai project to study is one that got killed halfway through. the next couple of years will produce plenty of those cases.

gartner predicted¹ in june 2025 that more than 40% of agentic-ai projects would be canceled by the end of 2027, pointing to escalating costs, unclear business value, and inadequate risk controls. mit nanda² found that roughly 95% of enterprise generative-ai pilots showed no measurable p&l impact. put together, most of this work stops, or fails to matter. cancellations rarely get a press release.

the ready-made explanation for those deaths is usually wrong. people reach for "the tools weren't ready." what we have watched is closer to the reverse: the tools worked. they did the one thing tools do, take what they are handed and make more of it, faster. the trouble was in what they were handed.

the old, slow way of working did two jobs at once, and only one of them was ever visible. it produced the deliverable, and under that process it also caught weak spots. a vague brief got firmed up over a couple of review cycles. a shaky grasp of process got corrected by the people downstream who had to build on it. work passed through enough hands that most of the weak parts were intercepted long before anything shipped. the friction people complained about was acting as the organization's immune system.

ai took the friction out, and everyone was glad to see it go. the interception went with it. there is now much less standing between a person's real fluency and the thing that ships. so when the output is bad, calling it ai slop misses what happened. the model amplified an input that was already weak, and the middle layer that used to catch that weakness was gone.

most of the cancellations sit on that mechanism. a pilot gets scoped by someone who cannot yet tell a working demo from a working system. it gets promised on a timeline by someone whose sense of what is feasible was never earned by shipping. and it gets evaluated by nobody with the craft the org decided it could automate away: process, standards, a real feel for what good looks like. 2 quarters in, the gap reaches someone with budget authority. pulling the plug is often the first well-informed decision anyone has made on the project.

elizabeth stone, who runs product and engineering at netflix, sees this from the other direction. on lenny's podcast in july 2026, she said some of the code these agents write is genuinely hard for her to follow. she can see that it performs better. she cannot always see why. that sounds like the same problem the failed pilots have, but it is the opposite. stone knows what good work looks like, so she knows exactly where her own understanding stops. that is the safe way to not understand something. the dangerous way is trusting the output with no way to check it.

a reversal teaches more than a win for that reason. a win worked inside one company's data, constraints, and tolerance for being wrong. you can admire it. you cannot lift it into your own situation, though nearly everyone tries. a stopped project carries over. it shows what the team believed at kickoff, what they found once the thing was real, and the belief they had to let go of. that belief is often the one you are holding right now.

some reversals are public enough to study from your desk. klarna spent early 2024³ telling everyone its support assistant was doing the work of 700 agents. by may 2025 its ceo was saying the cost focus had produced lower quality, and the company started hiring humans back for support. mcdonald's⁴ ran ai voice ordering with ibm at more than a hundred drive-thrus and ended the test in 2024. zillow⁵ shut down its home-buying business in 2021 after the pricing model kept overpaying for houses. none of these companies were careless. they believed something reasonable, tested it at scale, and stopped when the evidence came in.

most teams save this material for the postmortem, which is the one moment it cannot help anyone. it belongs at kickoff, as a premortem: sit the team down before the work starts and list the ways it could go wrong, while there is still time to do something about it. before the budget is committed and everyone is sold on their own optimism, put 2 or 3 halted projects from your own sector on the table. write down, in advance and in plain language, what would make you stop this one. name the person allowed to make that call. it can read as pessimism in the room. it is also the cheapest chance you will get to agree on a stop condition, before anyone is invested in not stopping.

how a project dies also tells you something useful. not every cancellation is a competence problem. gartner's own list includes cost escalation and unclear business value, and those kill capable teams too. the two failures still die differently. a team that knew what it was doing tends to stop early, on a condition it set for itself in advance. a team that was in over its head tends to drift, quarter after quarter, until finance stops it from the outside.

there is a regulatory reason to formalize the stop condition, too. the eu ai act's post-market monitoring⁶ duties for high-risk systems assume you have a defined way to notice that a deployment has gone wrong and act on it. a written stop condition, agreed at kickoff, used to be good practice. it is starting to look like a document a regulator will expect you to already have.