Almost every AI project I’ve been near in the last three years has had the same shape, and almost every one of them has died, or nearly died, between month six and month seven. The shape is so predictable I now bet money on it. The team has a strong launch in week four, a polished demo in week eight, a sluggish quarter, and then a meeting in the second week of month seven where someone asks “wait, is anyone actually using this?” and the meeting goes quiet.
I’ve come to call this the Six-Month Rule. The name is shorthand. The pattern is older than language models. McKinsey’s analytics group reported some version of it in 2019; before that, internal-tools teams at every Fortune 500 saw it. AI just makes the failure faster and the demo prettier, which makes the eventual reckoning louder.
What I want to do in this essay is two things. First, name the four causes I’ve actually observed, in roughly the order they hit. Second, give you the one-question test I now ask in every assessment to predict, before any code is written, which projects are going to make it past month seven.
What goes wrong, in order
The classic story is “adoption.” That word is a bag of four different things, and treating them as one is why the cure rarely matches the disease. Here is the actual sequence I’ve watched, six or seven projects in a row.
1. Trust collapses before utility appears.
The agent is wrong about something visible in the first week. Usually a small thing, often a thing a human would have been wrong about too. But the human gets context and the agent gets a screenshot in a Slack channel. By month two, two out of three frontline users have decided the system is unreliable, and they tell each other so. Trust is faster to lose than utility is to prove.
2. The original sponsor moves on.
At month four, the VP who championed the project has a new priority. Reorgs happen, board meetings happen, a competitor releases something shiny. The project loses the air cover it had. Nobody kills it. Nobody defends it either. This is the silent part.
3. The system is correct but invisible.
By month five, the agent is actually doing useful work. Throughput is up, errors are down. But nobody on the floor sees the wins, because the wins are negative space: tickets that didn’t come in, calls that didn’t get logged, escalations that didn’t happen. The leadership dashboard shows green. The line staff don’t see green. They see the one weird thing the system did on Tuesday.
4. The reckoning.
Month seven: someone asks the “is anyone using this” question in a meeting. There’s a flurry of activity. A consultant gets called. A retraining program gets proposed. The honest answer is that the system died at month two and has been twitching ever since.
The framing
The Six-Month Rule isn’t that AI projects fail. It’s that they fail predictably, in a sequence, for reasons that are not about model quality. Treating it like a technology problem is what makes it unfixable.
The one-question test
I now ask every prospective client a single question in the assessment week. The answer is the strongest predictor I have found of whether the project will be in production and in use eighteen months later. The question is:
Who, by name, will lose something if this project succeeds?
Not who benefits. Who pays a cost. Whose job description shifts, whose KPI gets harder to hit, whose team gets smaller, whose Excel sheet stops being the source of truth. If the answer is “nobody, really, it’s additive,” the project will fail. I’ve seen it nineteen times in a row.
It will fail not because anybody is bad-faith but because nothing in an organization that costs nobody anything is ever real enough to defend. AI projects that float free of the political economy of the company are the ones that quietly evaporate at month seven. Everyone’s for them. Nobody’s for them enough to fight for them.
The corollary: the projects that succeed are the ones where the cost is named, and the person paying it has been part of the design. The cleanest example we have is a structured-extraction agent we built for an operations team: the system meant two roles were going to do meaningfully different work. We named that on day one. We brought those two people into the eval-writing process. They are now the two strongest internal champions of the system.
What to do about it
Three concrete things, in order. None of them are technical.
Name the cost on day one.
In every assessment, write the “who loses something” answer into the project brief. If you can’t answer it, you’re not ready to start.
Instrument adoption, not just accuracy.
Build an adoption dashboard from day one. Daily actives, override rates, abandon rates, time-to-first-success. Accuracy is necessary; it’s not what dies first.
Find the second champion.
The original sponsor will move on. You need a backup. Ideally not someone in the same chain of command. Ideally someone whose calendar overlaps with the line staff. The project survives the first sponsor’s reorg only if there’s a second name on it.
None of this is about the model. The model is fine. The model has been fine for two years. The Six-Month Rule is a rule about organizations, and it can be broken, but only by people who’ve seen it break things before.
That, mostly, is what you’re paying us for.