Forward deployed engineering: when to pay for the engineers instead of the software
It isn’t a new service. It’s a confession, and a lock-in vehicle. Three conditions tell you when the premium is worth it anyway.
The demo went great. Everyone clapped and the pilot got funded. 6 months later it’s still a pilot, and nothing about the business has changed.
In the span of 3 days, the 2 largest cloud vendors on earth said the same thing with 9 zeros behind it.
On June 30, 2026, AWS committed $1 billion to a “Forward Deployed Engineering“ group that drops pods of 5 or 6 engineers into a customer’s operations, builds the AI system in their environment, and leaves.
2 days later Microsoft went bigger — $2.5 billion, 6,000 engineers, a new unit called Frontier Company built to sit inside the customer’s building and run the AI alongside their people.
The AI labs got there first: OpenAI put more than $4 billion behind a deployment company in May, Anthropic $1.5 billion.
5 of the biggest names in AI made the same bet in the same quarter.
*None of the press releases will say it out loud: Is this is an admission the software doesn’t work on its own?*
If Copilot seats and model licenses produced outcomes, nobody would need 6,000 people flown in to make them stick.
The number underneath all of it comes from MIT. Their 2025 study of enterprise AI found that 95% of generative-AI pilots deliver no measurable impact on the P&L (the actual profit-and-loss statement).
Not 40 percent. 95.
And the cause isn’t the models. MIT traced the failures to integration, data plumbing, and workflow redesign: the unglamorous last mile between “the demo worked” and “the business changed.”
A demo is a model home: staged, spotless, wired to nothing. Nobody can sell more product into that gap.
So the vendors have decided to sell people.
Where this came from
Palantir invented it around 2011, when it retitled its integration engineers “forward deployed engineers“ (internally, “Deltas,” a deliberate nod to Delta Force).
The problem Palantir kept hitting was that its customers, often intelligence agencies, couldn’t say what they needed. There’s no writing a spec for a problem nobody can articulate. So Palantir stopped trying and put its engineers inside the customer to watch the actual work and build in real time. For a stretch it employed more forward deployed engineers than product engineers.
Palantir’s own description still shows what makes this different from everything before it.
A product engineer builds one capability for many customers.
A forward deployed engineer builds many capabilities for one customer.
The genius was never the embedding. Consultants have embedded for decades.
It was the flywheel: the custom thing an engineer built inside one client got studied, generalized, and folded back into the product, so the gravel road one customer paved became a highway the next one drove for free.
None of this is 2026 news.
The venture firm a16z wrote the playbook in a June 2025 essay whose title gives away the whole game: “Trading Margin for Moat.“
The argument was that AI startups should deliberately run lower software margins to embed engineers, because the implementation is where the lock-in lives.
The billions Microsoft and Amazon just committed are that memo, executed at a scale only a hyperscaler can afford.
What’s actually different from an SI
On paper, a pod of 6 senior engineers billing to build a system sounds exactly like the systems integrator (SI) everyone already knows.
The vendors are desperate to say it’s different.
AWS contrasts its model with the “assess and recommend” posture of traditional consulting; Microsoft’s Judson Althoff went out of his way to say Frontier “goes beyond what has been labeled as Forward Deployed Engineering.”
Some of that is real. The pods are small and senior.
Palantir describes the role as a startup CTO who owns end-to-end execution, not a pyramid of junior analysts on a time-and-materials meter. The deliverable is working software plus the runbooks and trained staff to keep it alive, not a slide deck.
Done well, it looks less like hiring a consultant and more like hiring a personal trainer who shows up and sweats alongside the client: the whole point is that one day the client lifts alone.
Done badly, it’s what Constellation Research calls human middleware: a person-shaped patch over a product that isn’t finished. That’s what I’d listen for.
Directions on Microsoft, an analyst shop that has tracked Microsoft’s moves for decades, put the economics plainly. In the words of its analyst Lane Shelton: the free or subsidized deployment is the customer-acquisition cost, and the consumption meters are the payback.
It’s the telephone carrier’s free phone: the handset costs them money, and the 2-year plan is where they make it back.
The engineer embedded in the operation is building on the vendor’s platform, wiring in the vendor’s roadmap, generating the metered token and cloud spend that lands on next year’s invoice.
The buyer isn’t only buying help. They’re financing the vendor’s revenue ramp with their own dependency.
What’s dying is the billable hour, not the consultants
The lazy version of this story is that the AI vendors are coming for the consulting firms, that $3.5 billion of embedded engineers is a direct hit on Accenture and Deloitte and McKinsey.
It isn’t, and the org charts prove it.
OpenAI’s deployment company counts McKinsey and Bain among its backers.
Google’s forward deployed engineers ship alongside Accenture, Deloitte, and Capgemini.
ServiceNow’s forward deployed engineering program is, literally, a co-delivery partnership with Accenture.
Even Microsoft, with 6,000 of its own engineers, routes a lot of the actual delivery through the same big integrators it supposedly threatens, Accenture and the Big Four among them.
So the thing dying here isn’t the consulting firm. It’s the billable hour.
Every one of these programs is a bet against time-and-materials and toward outcomes attached to consumption.
It’s the difference between paying a plumber by the hour and paying the water company by the gallon.
That’s really a genuine shift, and on its face it appears to be a healthier one.
When a vendor only gets paid if the system produces value, their incentive finally lines up with the buyer’s: they can’t win by parking a team on-site and running the clock. They win when the thing works well enough that you’d renew.
Paid by the hour, the logic runs backward — every problem left unsolved is next month’s invoice.
The catch is that consumption isn’t your outcome — it’s a proxy for it.
Better than the hourly meter, which pays a vendor just to keep showing up. But a proxy the vendor controls: they design the architecture, the agents, the token and cloud footprint that lands on next year’s invoice.
The water company doesn’t get to plumb your house. This one does.
An engagement tuned to grow your usage and one tuned to grow your results aren’t the same engagement — even when the same engineer is doing the work.
When the FDE premium is worth it
Strip away the positioning and there are 3 conditions where embedded engineering beats a traditional integrator.
They’re the same reasons Palantir built the thing to begin with.
1. The problem has no playbook
If a clean spec exists and a dozen firms could deliver it, that’s a commodity, and I’d pay commodity prices: a configurable product or a normal SI. Nobody hires an architect to build a cookie-cutter house. The premium is for the problems nobody’s solved yet — where you build it and figure it out at the same time.
MIT’s data backs this from an odd angle: buying from specialized vendors succeeded about 67% of the time, versus internal builds that worked roughly a third as often.
The FDE premium buys someone who has already crossed this specific last mile.
2. The data is too sensitive to hand off.
AWS is aiming this squarely at regulated industries: financial services, government, healthcare.
If the work needs standing access to operational data that can’t leave for an arms-length engagement, a team embedded and governed directly is a real answer, not a markup.
3. You intend to own it afterward.
This is the one a CFO can’t let slide. The entire value of the model is the transfer.
Manhattan Associates describes its version as helping a customer stand up 1 or 2 agents and teaching the team to build their own from there. If there’s no defined handoff, no exit milestone, no point where the team runs it without the pod, it isn’t a capability.
It’s a dependency, and the meter never stops.
That leaves one uncomfortable question — and it’s not the one the vendor wants you asking. Not “what outcome will you deliver.”
Ask instead: what does the fully-loaded consumption cost look like in year 3, and what does it cost to leave once the vendor’s roadmap is the architecture?
With a fixed scope, a real knowledge-transfer plan, and a cap on the lock-in, the premium can absolutely be worth it.
If the answer is a shrug and a promise that the outcomes will speak for themselves, that’s not special forces. It’s consultants who never leave, with an arguably nicer logo on the badge.
The 95% number is the one to keep watching. Every vendor is citing it to justify the spend, and they’re right that the deployment gap is real.
The open question is whether embedding their engineers actually closes it — or just converts a stalled pilot into a metered subscription, with the failure quietly rebranded as progress.
I’d want to see the second cohort of customers, the ones who never make the launch-day press release, before I trusted the first answer.
Wouldn’t you?
Have you brought an embedded vendor team inside your operation, or turned one down? I’m trying to separate the cases where it actually transferred capability from the ones where it just deepened the dependency. Tell me which you saw.
References:
MIT (Project NANDA), The GenAI Divide: State of AI in Business 2025. 95% of pilots deliver no measurable P&L impact; buy-vs-build success rates. Report PDF
Microsoft, “The Microsoft Frontier Company” announcement, July 2, 2026
AWS / About Amazon, “$1 billion Forward Deployed Engineering” announcement, June 30, 2026
OpenAI, The Deployment Company (May 2026); Anthropic enterprise AI services JV (May 4, 2026). TechCrunch coverage
a16z (Joe Schmidt), “Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups”, June 2025
Palantir engineering blog, “Dev versus Delta”. The forward deployed engineer / “Delta” role.
Constellation Research, “Forward deployed engineers: the promise, peril in AI deployments”. Covers “human middleware” and Manhattan Associates.
Directions on Microsoft (Lane Shelton), “Microsoft launches its own Forward Deployed Engineering unit”
BCG, “The Widening AI Value Gap” (Sept 2025); McKinsey, “The State of AI 2025”