Almost every business we talk to has an AI story that went nowhere. A pilot that produced a good demo and no measurable change. A tool that got bought, rolled out, and quietly abandoned by month three. An agent that works when the person who built it is watching and drifts when they are not.
When we go back and look at why, the answer is almost never the model, the vendor, or the build quality. The project was decided before anyone wrote a line of code, by the condition of the thing the tool was pointed at.
The first killer: data that disagrees with itself
Here is the situation in most businesses between $3M and $25M. The customer record lives in the CRM. It also lives in the accounting system, with a slightly different company name. It lives a third time in a spreadsheet the operations lead maintains because neither of the first two has the field they actually need. All three are a bit out of date in different directions.
Nobody planned this. It accumulated one reasonable decision at a time. And for humans it mostly works, because a human knows that the spreadsheet is the real one for delivery dates and the CRM is the real one for contacts, and they reconcile it silently a hundred times a week without thinking about it.
An AI layer does not have that knowledge. Point it at all three and it will produce an answer. It will sound confident. It will not mention that the sources disagreed, because it does not experience that as a problem. This is the part that makes messy data genuinely dangerous rather than merely annoying. A broken integration throws an error and someone fixes it. A model working from contradictory inputs produces plausible output that nobody questions until a decision has been made on it.
We wrote about the cost of this in the real cost of running your business off spreadsheets. AI raises the stakes on that, because it turns a slow, visible inefficiency into a fast, invisible one.
The second killer: processes nobody wrote down
Ask most businesses to describe how a quote gets produced and you will get a clean four-step answer. Watch it happen and you will find eleven steps, two of which involve someone checking with a specific colleague, and one of which is a judgment call that has never been articulated because the person making it has been making it correctly for nine years.
You cannot automate that. Not because the technology is not capable, but because nobody can tell the technology what the process is. And critically, nobody can tell whether the automation got it right, because there is no written standard to check it against.
This is why so many AI implementations stall at the pilot stage. The demo works on the clean version of the process that exists in the kickoff deck. Production hits the real version, and the gap between them is where the project dies.
The third killer: nobody owns it after handover
Even a well-built system needs a review cycle. Someone has to look at what it is doing, notice when it starts drifting, and adjust. We have written about this for voice specifically in AI voice agents, what actually works, but it applies to everything.
If no named person owns the system after handover, it degrades. Not dramatically, which is the problem. It degrades slowly enough that nobody notices for two months, by which point the team has quietly stopped trusting it and routed around it.
What actually has to happen first
None of the fixes are exciting, which is exactly why they get skipped.
Decide where the truth lives. For each kind of information that matters, one system is authoritative and the others defer to it. This is a decision, not a technology project. It takes an afternoon to decide and a few weeks to enforce.
Write down the process you are about to automate. Not the idealised version. The real one, including the judgment calls and the exceptions. If a step cannot be written down, that is the step that will break, and you have just found it before it cost you anything.
Scope it to what you are actually building. This is the part people get wrong in the other direction. You do not need a company-wide data transformation before you can automate anything. You need the one workflow you are touching to be clean. That is a few weeks, not a few quarters.
Name an owner. One person, internal, who is responsible for looking at the output on a regular cadence. If you cannot name them, you are not ready to deploy.
Why we start with an audit
This is the whole reason our engagements open with an operations audit rather than a build. Two to four weeks inside the business, interviewing the people doing the work and watching how it actually happens, tells us which processes are documented enough to automate and which ones are going to fall apart the moment we try.
Sometimes the audit says build. Sometimes it says fix the data first and build in six weeks. Occasionally it says the thing you asked for is not the thing that is costing you money, here is what is. All three are better outcomes than a build that fails for reasons anyone could have seen in week one.
If you have had an AI project stall and you are not sure why, that is a conversation worth having. Book a 30-minute call and we will tell you what we think went wrong.