Most companies are getting very little back from what they have spent on AI. The reason is not the models. It is that nobody went inside the business and did the work that turns a general tool into a specific one.
Almost every owner I talk to has tried something. A licence bought for the team, a chatbot on the website, a pilot somebody championed for a quarter. Almost none of them can tell me what it earned.
Researchers at MIT published a report in 2025 called The GenAI Divide: State of AI in Business. Its headline finding travelled further than the report did: ninety five percent of the generative pilots they looked at produced no measurable impact on the profit and loss. Around five percent produced a real return.
The finding has been argued with since, and fairly. It rests on a sample of executive interviews, leader surveys and publicly described deployments rather than audited accounts, and a pilot that has not yet moved the profit and loss is not the same thing as a failure. Treat the exact number as directional. What is harder to argue with is the pattern underneath it, which matches what I saw from an executive seat over enterprise systems.
Fortune's summary of the report
The cause it names is not model quality. The tools are extraordinary and they keep getting better. What the report describes is a learning gap: general tools do not learn a particular company's workflows, so they stall the moment the work stops being generic. A model that is brilliant at the average case is useless at your exceptions, because your exceptions are not written anywhere it can read them.
There is a second finding in there that got less attention and deserves more. More than half of the budgets went to sales and marketing tools, while the returns that did show up were in the back office, in the ordinary administrative work that nobody demonstrates at a conference. The money went where the excitement was rather than where the waste was.
One thing, mostly. Somebody went inside the business.
Not a demonstration, not an onboarding call, not a customer success manager with a quarterly check-in. Somebody technical sat with the people doing the work, learned how the work actually runs, found where the decisions get made and on what basis, and then built against that. The tool was shaped to the operation rather than the operation being asked to shape itself to the tool.
The industry has a name for that person now. A forward deployed engineer. Palantir built its business on the idea and the large model companies have since copied it, because they all found the same thing: the product alone does not land.
The gap is not between companies that have AI and companies that do not. It is between companies somebody went inside, and companies that were sold a login.
Strip the title back and the job is unglamorous. They sit where the work happens. They watch a job go from the phone call to the invoice and write down what really occurs, including the three steps nobody mentions because everyone has always done them. They find the place where two systems disagree and decide which one is right. They separate the cases that run the same way every time from the ones that need a person. They put the work somewhere it can be counted.
Only after that do they automate anything. By then the automation is almost boring, because every hard question was answered on the way to it.
That sequence is the whole trick, and it is why buying the tool first so rarely works. The tool was never the missing part.
A forward deployed engineer is expensive and the model was built for large customers. A company of forty people does not get one. It gets a licence, a webinar and a help centre, and it is left to do the embedding itself, with a team that already has a day job.
Meanwhile the conditions in a company of that size make the need sharper, not softer. There is no internal systems team. The process genuinely does live in people's heads, because for years that was the efficient place to keep it. The owner is the integration layer. Every one of those facts is exactly what a general tool cannot read.
Before anybody can deploy forward into your business, the business has to be legible. Somebody has to map how the work runs, write the procedures, decide which cases are exceptions, give every record one home, and put a queue under the work so it can be counted. Five layers of it, and automation sits on top as the sixth.
That is not a delay before the interesting part. It is the part that decides whether the interesting part works. It is also, inconveniently, the part that cannot be bought as a product, because it is different in every business.
Fulcrum is the forward deployed version of this for operations rather than for code. We come into the business, learn how it runs, design how it should run, and build that design into the software people actually use. We stay for the running of it when an owner wants that.
We do not write the software ourselves, and I would rather say so plainly than let it be assumed. Where nothing on the market fits, the design becomes a scoping document and we bring in a development partner and run them against it. The engineering seat is real and it is filled by somebody who is not me.
What I am claiming is narrower and, I think, more useful. Most of what stops automation working in a company of ten to two hundred people is not an engineering problem at all. It is an operations problem wearing an engineering costume.
Pick one workflow. Name where it starts and where it ends. Spend two weeks finding out how it truly runs, what it costs and where it breaks, and get a ranked list of what to do about it. Some of that list will be things you can fix yourself next week for nothing. Some of it will belong to somebody who is not us.
Then, and only then, decide what to automate. The answer will be smaller than the sales pitch and it will hold, because by that point you will know what you are automating.
Two weeks, one piece of work, from a named start to a named end. The roadmap is yours whether you buy anything else or not.