The reported failure rates for AI projects are grim and remarkably consistent. RAND puts the share delivering no measurable business value at around 80 percent. Gartner has found at least half of generative AI projects abandoned after proof of concept. One survey reports the share of companies abandoning most of their AI initiatives rising from 17 percent in 2024 to 42 percent.
Take those as directional rather than precise, since the definitions vary and several come from firms selling the fix. The pattern across them is what matters, and it is the same every time: the failures are not technical.
The most useful single figure we found is that 73 percent of failed projects had no agreed success criteria before they started. That is not a model problem. That is a project that could never have succeeded, because there was no definition of success to reach.
This note is about the decisions that sit before the model, which in our experience is where implementations are won or lost. They come down to three things, and only one of them appears on a price list.
1. Write down the number first
The order matters more than any individual choice in it.
Almost every disappointing deployment we have seen started with a tool and looked for a use for it. The order that survives contact is the reverse: one real task, one number that should move, recorded before anything is built.
Concretely, before you evaluate anything:
- Name one task. Not a department, not a workflow, one task that happens repeatedly.
- Name the number. Share of calls answered. Hours a week on an admin job. Time from enquiry to first reply. Error rate on a routine document.
- Measure it for a fortnight. This is the step that gets skipped and it is the one that cannot be recovered, because once you have deployed, the thing you replaced is gone and you can no longer measure it.
If you cannot state the number, you are not ready to buy anything. That is an uncomfortable answer and it is cheaper than the alternative.
2. Cost is per completed task, not per token
The three axes. This one is the most misread.
Every vendor quotes cost per token or per seat. Neither is what you pay. What you pay is cost to a finished, acceptable result, which includes the attempts that failed, the work that had to be redone, and the human minutes spent checking.
A model that is half the price and needs two attempts is not cheaper. A model that is five times the price and gets it right first time on work worth a few hundred pounds is trivially cheap. We have run this arithmetic repeatedly on the research side of this site, most recently on GPT-6.1 Sol, where a model arrived at a fifth of the price of its predecessor and the interesting question was immediately whether a fifth of the token price means a fifth of the bill. It usually does not.
The same argument, in more detail, in what tokens actually cost and small language models. The short version: a model that can do far more than your task needs is not a free upgrade when you pay for the headroom on every single request.
3. Speed is what the business feels
Speed here means wall-clock time to a finished outcome.
This is the axis that determines whether a process changes shape. A report that took two days and now takes two hours is a different report: you can run it weekly instead of quarterly, and that changes decisions. A reply that took a day and now takes ten minutes changes the customer's experience of you.
Speed is also where the honest gains usually are for a small business. Not doing something nobody was doing, but doing an existing thing fast enough that it becomes worth doing often.
4. Latency is what the customer feels, and nobody prices it
This is the axis that gets ignored and it decides the architecture.
Latency is time to the first useful response. It is distinct from speed because it is measured by whoever is waiting, not by whoever is running the job.
The question that follows is binary and it is the most important question in this note: is a person waiting?
If yes, you are in a live path. A caller on the phone, a customer in a chat window, someone watching a page. The budget is seconds. That rules out a large model thinking at length, and it rules in something fast and narrow called from code that owns the flow. The newer classes of model built for exactly this, which we covered in TypeSafe's System One and CLM-8B, return structured answers in about a tenth of a second because they do not generate text at all.
If no, you are in a background path. Overnight document processing, batch enrichment, a weekly summary. Latency is free here, so spend it: use the slower, more thorough model, let it check its work, run it twice.
Most disappointing deployments we see are one mistake: a batch-shaped model dropped into a live-shaped hole. The demo was impressive because nobody was waiting. In production a customer is, and eight seconds of silence on a phone call is a lost customer regardless of how good the eventual answer was.
5. What to automate first
With those three settled, the shortlist is nearly automatic. Look for work that is:
- High volume. A small improvement on something that happens fifty times a week beats a large improvement on something monthly.
- Low judgement. The task has a right answer you could describe to a new starter.
- Reversible. A mistake is embarrassing, not expensive. Nothing irreversible on a first project.
- Already understood. You know what good looks like, so you can tell whether it worked.
For most small businesses that points at the same place: the enquiries you are not responding to. Missed calls, messages that sit unread, the follow-up nobody got to. It is high volume, low judgement, reversible, and the cost of the current failure is measurable in lost work. We wrote the honest version of that case, including when not to do it, in what an AI receptionist actually fixes.
The other reliable first move is not automation at all. It is getting the record into one place, which is the argument in WhatsApp is already your customer record. Automation on top of a record nobody can see produces confident, fluent, uninformed output.
And the one to avoid: do not automate a task that should not exist. Several of the failure analyses make this point and it is worth repeating, because automating waste produces waste at scale, faster, with a subscription attached.
6. Where the model belongs
The last structural decision, and the one we have written about most.
Code should own the process. The model should be called where judgement is needed.
If you can draw the steps on a whiteboard before you start, you do not need a model to rediscover them on every request. Deterministic code is faster, cheaper, testable and identical every time. Reserve the model for the part that is genuinely hard: reading the unstructured message, deciding which of five categories this is, drafting language from context.
That is the whole argument in TypeSafe's System One, and it is also, from the safety direction, what we found reading OpenAI's dots, where an agent running unattended is restricted to reading and every write needs a grant.
For a small business the practical form is simple. The model drafts, a person approves anything that leaves the building, and the rules that decide what needs approving live in your system rather than in a prompt. That is how Nure AI OS is built: replies are drafted from the conversation and the record, and a person reviews and sends, with specific tasks set to run on their own only when you decide they should.
7. A first project that can actually be judged
One task. One number. Four to six weeks. A decision at the end.
- Week zero. Record the baseline. Do not skip this.
- Weeks one to four. Build or buy the narrowest thing that addresses the one task.
- Week five. Measure the same number, the same way.
- Then decide. Keep it, change it, or stop. Say in advance what result would make you stop, because a project nobody is willing to kill is a project nobody is really evaluating.
The aim of a first project is not transformation. It is finding out whether this class of work pays in your business, cheaply enough that the answer no costs you a month rather than a year.
8. What we would not promise
We build this kind of system, so discount accordingly.
AI will not fix an undefined process. It makes an existing process faster and more visible. Where there is no agreed way of working, it produces fast disagreement.
The savings claims in this market are mostly unaudited. You will see 15 to 20 hours a week and 30 to 40 percent cost reductions quoted widely. They come from companies selling the service, including figures we could have quoted here without checking. Your own baseline is the only number worth planning against.
Some things should stay human, and the test is whether the interaction is itself the product rather than the logistics around it.
If you want the architecture decided before the tool, on your own numbers, talk to us, or see how we build systems for businesses.
9. Sources
Failure statistics in this area are widely republished and the underlying definitions differ, so we have linked the sources rather than presenting them as settled.
- AI project failure rate in 2026: what the data shows, Folio3, collecting the RAND and related figures.
- Why half of GenAI projects fail, Gartner, on abandonment after proof of concept.
- AI projects fail in enterprises: 2026 reality check, for the success-criteria finding quoted in the opening.
- The real reason most AI projects fail, Forbes Technology Council, on failures being organisational rather than technical.
- Small business AI automation: where to start in 2026, for the prioritisation heuristics discussed in section 5, which we have reframed.
This note sits in our Operations track, alongside the operations and system design threads. The full library is at Research.