The demo works. Everyone in the room can see it: the assistant drafts the quote, sorts the inbox, pulls the numbers out of the spreadsheet nobody likes. The team tries it for a week. Three weeks later, quietly, everyone is back to the old way, and nobody can quite say when it happened. This is how most AI projects fail, and it rarely looks like failure. It looks like a stall at about 80%.
The first 80% is the easy part
Getting an AI tool to handle the typical case is now fast. A capable model, a sensible set of instructions and a few good examples will cover most of what a process does on a normal day. That's why demos are so convincing. They're built from normal days.
The last 20% is everything a normal day hides. In the builds we've done, it comes back to the same three things, and none of them are about the model.
The messy data
The demo ran on clean examples. Real work runs on the price sheet that exists in two versions, the customer list where half the records have the company name in the contact field, the folder of scanned documents nobody has opened in years. The tool handles the tidy cases well and makes confident mistakes on the rest, and it only takes two or three of those before people stop trusting it.
The fix is unglamorous: decide which source is the real one, clean it enough to be usable, and give it an owner. That's most of what we mean when we talk about how to build a knowledge base AI can actually use. It's also the step most likely to be skipped, because it doesn't feel like AI work.
The exception the process forgot
Every process has a written version and a real version. The written version says quotes go out within a day. The real version says quotes for one long-standing customer go past the owner first, rush jobs are priced differently, and anything involving a particular supplier waits until they confirm stock. Nobody wrote those down because everybody knew them.
An AI tool only knows the written version. So it does exactly what it was told, on exactly the cases where what it was told was wrong, and the person who knew the exception now has to catch it every time. At that point the tool is extra work, and extra work gets dropped.
We've run into this in our own work, too. When we started publishing this blog with AI help, the writing came quickly. The slow, stubborn part was everything around it: illustrations that took several tries, and checks we hadn't thought to write until something slipped past. We wrote that up in what we learned publishing a blog with AI in the open. Same pattern, smaller scale.
Nobody owns it when it breaks
The third one is the quietest. The project had a champion while it was being built. Once it's live, who fixes it when a supplier changes their invoice layout, or when the assistant starts giving a slightly wrong answer about the return policy? If the answer is whoever happens to notice, the answer is nobody.
A stalled AI project is rarely a technology problem. It's a process nobody finished describing and a tool nobody was given to own.
Ownership doesn't need to be a full-time job. It needs a name, a short list of what that person checks, and a regular time to check it. It's the same principle we argued for when everyone on a team sets up their own AI: one shared source, a few named owners, and a way for fixes to get in.
What to plan for before you start
Most of this can be seen coming. Before building anything, spend an hour on three questions. Which data will this run on, and is that data actually in shape? What are the exceptions? Ask the person who does the job today, not the person who manages it. And who owns it after launch, with what time set aside each week?
Decide up front what working means, too. If the measure is vague, a stall looks exactly like a slow start, and nobody calls it until the tool has been forgotten. We wrote about choosing a measure that tells you the truth in how to tell whether AI is actually paying off in your business.
A stall or a failure?
Not every abandoned project deserves rescuing. The test we use is simple. If people stopped because the tool got specific, nameable cases wrong, it's a stall: the last 20% is unfinished, and finishing it is usually far less work than starting over. If people stopped because the tool solved a problem nobody really had, it's a failure, and the honest move is to let it go and put the effort somewhere it will count.
In a stall, the demo was right. The work around it never got finished.
If you have one of those sitting half-used, or you're about to start one and want to avoid it, our THINQ Diagnostic is where we map how the work really runs, exceptions included, before anything gets built.
