95% of AI projects deliver nothing. Here's what we think the other 5% got right.

There's a report MIT put out in August last year that found around 95% of AI projects inside businesses produced little or no measurable return, and we run an AI implementation company, so you'd think that's the last thing we'd want to put in front of you. But we think it's probably the most useful thing you can know before you spend any money on this, because when you read what they actually measured, the reason those projects failed had very little to do with the AI itself.

What the report actually says

It came out of MIT's Project NANDA in August 2025, it's called The GenAI Divide, and the headline number comes from a fairly straightforward piece of research. They interviewed 150 leaders, surveyed 350 employees and went through 300 publicly disclosed AI deployments, and roughly 5% of those projects were producing real revenue acceleration whilst the rest had little or no measurable impact on the profit and loss. We should say it's a preliminary report and it hasn't been peer reviewed, so we wouldn't treat 95% as a precise law of nature, and plenty of people have picked holes in the methodology since. But the direction of it matches what we see in businesses, and the reason it gives for the failures is the part worth your time.

The report is quite clear that the divide isn't down to model quality. It calls the problem a learning gap, by which it means the tools don't learn or adapt to how the company actually works, and the organisations don't change how they work to fit the tools. So you end up with software that's perfectly capable sat next to a process it knows nothing about, and not much happens.

So why are we telling you this?

Because it's our whole argument, and MIT has made it better than we could. If those failures were caused by the AI being rubbish then we'd have a real problem, and they're not. They're caused by nobody doing the work of understanding the business before the building starts, and that work is the thing we actually sell.

AI is a very good junior engineer

Here's what we think people get wrong about what they're buying. Modern AI is genuinely capable, so it writes decent code, it reads documents faster than any person can, it'll do the same dull task ten thousand times over without complaining, and so on. But it isn't a strategist, so it won't tell you that your quoting process is broken because two departments have been keeping separate spreadsheets since 2019, and it won't notice that invoices go out late for reasons that have nothing to do with typing speed and everything to do with one person having to approve them whilst they're out on site.

So the honest comparison is a very good junior engineer in their first week. Give it a clear, well scoped job and it'll hand back a genuinely good piece of work, and give it a vague instruction with no understanding of the business and it will confidently do the wrong thing, quickly, and charge you for the privilege. That last bit catches people out more than anything else. AI bills by the token, which is roughly a chunk of a word, so every confident wrong turn is money, and an unfocused implementation doesn't just waste a few weeks, it shows up on the bill at the end of the month.

AI wasn't the problem. It was the systems and the skill sets behind it.

So if the technology works and the money is real, where does it break? Nearly every failure we've seen comes down to one of three things, and not one of them is the model.

1. 1.The systems underneath were already complicated, and nobody untangled them first. Most businesses are running on platforms that got bolted together over years, so two of them don't quite talk to each other and somebody bridges that gap by hand every Tuesday afternoon. Put an agent on top of that and it does the broken thing faster, in more places, and it's harder to see where it went wrong.
2. 2.Nobody took enough time to map how the work actually runs. The AI was handed a task without ever being handed an understanding of who does what, which of the official steps people quietly skip, and what happens on the day it all goes wrong, which never makes it into the process document and is usually where the time goes.
3. 3.The skill sets weren't in the room. Doing this properly needs somebody technical enough to design the system and comfortable enough with people to get the truth out of a room full of staff, and those two things rarely turn up in the same person. MIT's own numbers point at it, because AI bought in from a specialist succeeded about 67% of the time whilst internal builds managed roughly a third of that, and companies carried on building it themselves anyway.

And the expensive part is what happens next. The implementation underperforms, everyone concludes that AI doesn't really work here, and the business goes back to doing it the way it always did with a slightly worse opinion of the technology than it started with. The money spent on the pilot is the small part of that. A company that has decided AI isn't for them tends to stay decided for a couple of years, whilst their competitors get on with it.

What forward deployed engineering actually means

So the thing missing from most of these projects is somebody doing a fairly unglamorous job at the very start, which is working out how the business genuinely runs before anyone builds anything. In software that role has a name, forward deployed engineering, and the idea behind it is simply that you can't build anything useful for a customer from the outside looking in.

In practice it means a person who is technical enough to design an agent system properly, and comfortable enough with people to sit in a room with five or ten of your staff and get the truth out of them. Those two things don't often turn up in the same person, and we think that's a fair part of why so many implementations fail. Most consultants who can run that workshop can't build the thing afterwards, and we've met plenty of good engineers who have never once sat with a finance team whilst somebody explains what really happens when a supplier invoice doesn't match the purchase order.

The job in that room is to map one process properly, so not the whole business, one process inside one area like sales or finance or payroll or scheduling. You're after what actually happens in what order, which platforms are involved and which are only involved because somebody set them up years ago, where a human has to make a real judgement call, and what happens when it all goes wrong, because that last one never makes it into the official process document and it's usually where the time goes.

Only once you've got a complete map of that process, and you actually understand the problem you're trying to solve, can you honestly say what AI should be doing about it. Most implementations are simply too hasty, so they skip that and go straight to building, which is why so many of them end up automating something nobody needed automating. Sometimes the answer is an agent that runs the whole thing, sometimes it's automating two steps and leaving the rest alone, and sometimes it turns out one platform is redundant and removing it saves more time than any AI was going to. Would you rather find that out in week one, or six months into a build?

The thing that quietly kills good solutions

There's one more decision that determines whether any of this survives contact with your team, and it gets missed constantly. If a job used to take thirteen steps and your shiny new solution does it in one, adoption is going to struggle no matter how good the solution is, because nobody trusts a single button that swallows an afternoon's work, and the people who owned those thirteen steps can't see where their job went.

So we build for gradual change instead, which means it keeps a similar shape and the checkpoints stay roughly where you'd expect to find them, but an agent is now doing the hour of copying between two systems in the middle and one platform has quietly disappeared. It still feels like the process your team already knows, and it runs many times faster.

How we run it

So that's what Pulsar does, and we think the order of it matters more than any single piece. We educate first, so you know where AI is strong and where it needs directing. Then we audit, which is the mapping work above done properly with your people in the room. Then we show you the quick wins you could implement yourselves next week, because there are always a few and you shouldn't be paying anyone for those. Then we build the agent systems that are worth building, and if you want the digital side redesigned as well then we'll do that too, though it's a component of the work rather than the way in.

That gap MIT found between bought in and built in, 67% against roughly a third of that, we'd put down to the mapping far more than anything clever in the engineering. If there's a process in your business that eats more time than it should, that's the conversation worth having, and we'd start by properly understanding it before we sold you anything at all.