Most companies have put AI at the edges. A copilot in one team. A chatbot on the website. A pilot inside marketing, or support, or legal. The industry conversation has already moved on to agents - software that does the work itself, end to end.
I want to argue that we skipped something on the way, and that the thing we skipped is worth more than the thing we are chasing.
Most pilots produce nothing, and the reason is not the model
MIT’s Project NANDA looked at enterprise AI in 2025 and found that around 95% of generative AI pilots produced no measurable impact on profit or loss. The number has been quoted a lot. The explanation has not.
Their finding was not that the models were too weak. It was that the tools “cannot retain feedback, adapt to context, or improve over time.” They called it a learning gap. The pilots that worked were the ones embedded in a real workflow, with memory.
Treat that as a description of the failure rather than proof of any particular fix - it is survey and interview work, and it says so itself. But the description matches what I see. Most companies have given a very capable model almost nothing to be knowledgeable about. It knows language. It does not know the business.
The reframe
The obvious response is to give the model more context so it can do more work. That is the automation path, and it is real.
But here is the thing I keep coming back to:
Companies do not need AI that knows more. They need AI where work is chosen, funded, coordinated and stopped.
Automation makes work faster. It does not ask whether the work should happen. And in most organisations I have seen, the larger cost is not work done slowly. It is work that should never have started.
What that costs
Someone in this field put a number to it in a conversation recently: roughly £600,000 per 100 employees per year, lost to what he called distraction - the non-core work, the noise, the projects that are nobody’s priority but somebody’s initiative.
I cannot source that number, and I am not going to pretend otherwise. What I can tell you is that it sits at the conservative end of what published work suggests. That is £6,000 per employee. Bain’s research into organisational drag - the material behind Time, Talent, Energy - puts the loss at 20 to 25% of a company’s productive capacity, with the best quartile losing about half that. Kaplan and Norton’s finding that most employees cannot state their own company’s strategy has been reproduced for two decades.
If you want to see where the money goes, look at what it takes to run a project. In another conversation, someone described the overhead on delivery in their business - coordination, governance, reporting, rework - as somewhere between 70 and 150% on top of the project itself. That is far above the 6 to 15% the project management literature quotes, because it is measuring something wider: not the project manager’s salary, but everything the organisation does around the work in order to keep doing the work.
I am not going to add those two numbers together. They overlap - the meetings and the status reports appear in both - and stacking them would tell you a bigger story than the evidence supports. One is the size of the problem. The other is a picture of where it lives.
Where a company brain actually changes something
We build what we call a context engine, or a company brain: one place that holds what the organisation knows - decisions, meetings, commitments, priorities, history - in a form both people and models can read.
The automation use is obvious. The one almost nobody is using is this: put that context at the point where work gets decided.
Someone proposes a project. Before it reaches a steering committee, an assistant that knows the business can say: this overlaps with something another team started in June; this does not map to any current priority; a version of this was tried in March and stopped for these reasons.
That is a different intervention from a dashboard. A dashboard reports. This arrives at the moment a decision is being made, with the specific history that bears on it. The decision points worth starting with are narrow and familiar: project intake, budget requests, hiring, roadmap trade-offs, the meeting that gets scheduled because nobody knew the question had already been settled.
”We tried this. It was called an intranet.”
This is the right objection and it deserves a straight answer.
OKR platforms promised cascading goals. Business intelligence promised shared facts. Intranets and enterprise search promised shared knowledge. They largely failed, and not because the interface was bad. They failed because the official truth was stale, incomplete or politically inconvenient, and because none of them sat anywhere near a consequence.
What is different is narrow, and I would rather claim it narrowly. Those systems required a person to go and look, then translate what they found into their own situation. A model with organisational context does the translation, and it can be present at the moment the decision happens rather than in a system you visit. That is the whole of the difference. It is smaller than the usual pitch, and I think it is real.
The hard part is whose truth wins
Retrieval is not the difficult bit. Governance is.
A strategy deck, a chat thread, a board pack and a manager’s private view can all disagree about what matters this quarter. If an assistant tells someone confidently that their project is not a priority, and it is working from last quarter’s plan, you have made things worse. You will have spent trust you do not get back.
So the questions that decide whether this works are not technical: who is allowed to declare a priority, which source wins when two conflict, how quickly a priority goes stale, what happens when the assistant is not sure, and who checks it when it is wrong.
We build this into our own brain as a matter of course - every claim carries its source and date, a policy governs what may be recorded at all, and a check runs daily against the things the system asserts to be true. It is unglamorous, and it is the part that makes the rest safe.
What I have seen myself
We run our own company brain. Everything above is easier to argue because I have watched it work on us.
In a single afternoon recently, working through our own backlog, it found three things.
Two tasks had been sitting as overdue - one for 68 days, one for 52. Both were already finished. One was published on our own website; the other had been written a month earlier. Nobody had connected the work to the task.
A meeting in our records had never happened. The note said a coffee was confirmed for a particular morning, and cited the email thread it came from. The thread contained no such message. It had sat there for five weeks, generating a warning about an outcome nobody had chased, for a meeting that never took place.
And a live application, running behind a login, turned out to be invisible to the plan written for its successor.
None of these were automation problems. Nothing needed to be done faster. They were the same problem three times: nobody could see across the whole picture at once, so things that were obviously wrong stayed invisible. The value was not speed. It was knowing what was actually true.
Where I would not take this
Alignment is not free, and it is not always good. A company where everyone pushes on the same square inch is also a company where nobody wanders off and finds the next thing. Plenty of valuable work starts local, opportunistic and slightly off-plan, and a system that faithfully enforces this quarter’s priorities will kill some of it.
And there is a problem software does not solve. Misalignment usually benefits someone. Projects have sponsors, teams defend headcount, and a system that makes wasted effort visible is threatening to whoever was making it. I do not think a better assistant fixes that. It removes the excuse of not knowing, which is a smaller claim than the one usually made here, and about as far as I would honestly go.
Where this ends up
Start narrow: one decision point, with the context that bears on it, somewhere a consequence already exists.
But it is worth being clear about where it leads. If it works at the intake meeting, there is no obvious reason it stops there. Everyone in the business could have something that knows where the company is going, what has already been tried, and what everyone else is working on - not to tell them what to do, but so they are never the last to know.
Most organisations spend a great deal of money on people making perfectly reasonable decisions with a fraction of the picture. That is the part worth fixing, and it is not an automation problem.
somai builds the foundations organisations need to work with AI properly. We run our own company brain, which is where most of the examples above come from. Companion to Why every company will build a brain, which argues why the brain is now worth building at all; this piece is about where to point it first.