Stop sending me engineers: what OpenAI, Anthropic and Microsoft misread about enterprise AI

The AI industry says enterprises can’t absorb AI. Its answer is to absorb it for them.

That’s not the same thing.

The engineer across the table knew the model cold. Not vendor-deck cold. He could tell me where it would break, what it would cost, and which benchmark numbers to ignore. One of the better technical minds who has ever sat in that chair.

Forty minutes in, I asked which of our problems he would point to first. He named a minor workflow one of my directors had mentioned that morning.

The easy read is that he didn’t know my business. True, and not very interesting. Here is the real issue: the people who sent him are making the exact mistake they are being paid to fix.

They’re not wrong about the problem

The frontier labs aren’t confused, and I want to be fair before I disagree.

MIT found that about 95% of enterprise AI pilots produced no measurable profit impact, despite tens of billions spent. Winning the benchmark wasn’t winning the deal. And a customer who never gets to production never renews.

So, they did the logical thing. They sent engineers:

• OpenAI: Launched the OpenAI Deployment Company in May with $4 billion of initial investment from 19 partners, starting with 150 forward-deployed engineers (FDEs) and deployment specialists.
• Anthropic: Partnered its engineering capability into an enterprise AI services venture with Blackstone, Hellman & Friedman, and Goldman Sachs, reportedly valued above $1.5 billion.
• Microsoft: Launched Frontier Company in July with $2.5 billion and approximately 6,000 embedded engineers and industry experts.
• AWS: Committed $1 billion to a forward-deployed engineering unit embedding engineers with customers.
• Market surge: FDE job postings grew roughly 800% in nine months, with principal-level compensation past $1.2 million.

That is a serious response. But it answers the wrong question.

All that capital is aimed at getting customers into production and keeping them there. We have been reading it as the playbook for getting AI into the wider economy. Those are two entirely different problems, and only one of them currently has anyone working on it.

The same mistake, twice

One structural fact tells you what this really is: the forward-deployed function sits on the commercial side of these companies, not in research. OpenAI capitalized its deployment arm as a separate business with outside investors.

That’s not an accusation; the org chart is simply more honest than the positioning. What that structure measures is pilots converted to production within the quarter. Against that scoreboard, the model isn’t shallow at all. It’s optimal.

Now look at the same failure from my side of the table.

A team builds an intelligent demand-forecasting agent. Accuracy improves by double digits. The engineering readout is genuinely good. And absolutely nothing happens to cash.

Accuracy was never the point. It only matters if it changes an operational decision: how much safety stock you hold, what commitments you make to suppliers, or what you schedule to build. If none of that changes, you haven’t freed a single dollar. Worse, if the model was tuned for fill rate, because that’s what the commercial team asked for — inventory climbs, working capital gets suffocated, and you are worse off than before. The project wins. The company loses.

Anyone who runs S&OP knows this reality: inventory is cash sitting on a shelf. Every forecast is a claim on that cash. Every service-level promise decides how much liquidity you lock away. The value is never in optimizing a single, isolated number; it is in managing the trade-offs between them.

Outside engineers cannot own those trade-offs. Look at what their engagements are sold on: a deflected ticket, an automated records request, a closed underwriting case. Local, siloed inside one function, and measurable in weeks. Those are the only outcomes an outsider can deliver before rolling off to the next logo.

The results a CFO cares about cross three functions and only show up in cash two quarters later.

Delivery vs. Diffusion

This gets celebrated as AI reaching the real economy. In practice, it does close to the opposite:

• The learning runs one way. Anthropic’s job listings are the most explicit about this, asking engineers to codify repeatable deployment patterns and contribute those insights back to product and engineering. That is honest, and it is the point. Analysts have flagged the same concern from the buyer’s side: that deep reliance on frontier labs hands those labs insight into the very industries they may later enter.
• Capability is replaced instead of built. The engagement leaves behind a functioning workflow, but zero internal muscle to solve the next bottleneck. Constellation Research warned this year that FDEs are often used as a crutch for product immaturity, and as part of a broader vendor dependency play. Without Palantir’s feedback loop — where every deployment continuously enriches an integrated customer ontology — this is simply an expensive systems consultancy with a frontier brand name.
• The mid-market waits. Dice reported in August that the shortage of engineers is now directly holding back enterprise AI returns. The scarcest engineering talent sits inside Fortune 50 anchor accounts, while the companies that make up most of the economy queue behind them.

In engagements structured this way, the lab learns your business. You learn their product.

So here is the test I now apply to any engagement, including the ones I sign: when it ends, are we better at finding the next problem ourselves?

If the capability leaves the building when the outside engineer packs up their laptop, that was delivery, not diffusion. Delivery is a fine business, but it doesn’t compound. Diffusion is nothing but compounding.

What we did instead

We eventually fixed our inventory problem.

Not by pointing an off-the-shelf frontier model at raw ERP tables, but by redesigning our entire planning architecture from the ground up. We staffed the initiative with operators who had spent years inside our supply chain and knew where the real constraints actually sat — the lead time, the allocation rule, the supplier commitment that no outsider would have known to model and then applied AI directly to those decision points.

The result: Inventory came down and stayed down, turns improved, and the part that matters for this argument, nobody had to be flown in to do it again the following quarter.

There is no version of that outcome a single outside engineer could have designed, no matter how brilliant the model in his hands.

The bigger stake

Scale this up and the macro picture becomes clear. A country’s AI advantage will not come from a few hundred flagship deployments. It will come from millions of operators applying AI to operational decisions they were previously making badly.

Which brings me back to the man across the table.

We are spending millions sending AI experts to learn business. We should be sending business operators to learn AI.

• Business knowledge is slow. It took most of my career to instinctively know which trade-offs to make around working capital and inventory.
• AI execution is fast. An experienced operational team can master agentic tooling, evals, and model orchestration in a matter of months.

We are running the harder transfer at immense cost and mistaking it for progress.

I don’t need more forward-deployed engineers. I need backward-deployed domain experts.

Nobody is selling those. Which means the only people who can build them are already on your payroll.