Last week I argued that the era of selling foundation models as products is over, and that the era of selling them as embedded transformations has begun. OpenAI's DeployCo, Anthropic's deployment vehicle, and Google's just-announced AI organization inside its Go-To-Market team are all reaching for the same Palantir playbook: hire elite engineers, embed them inside the customer, and treat the bespoke implementation as research and development rather than cost of goods sold. The full case is in The Deployment Epoch.
That argument holds. The labs really are pivoting. The deployment epoch is real.
What I did not say strongly enough is that this pivot might not work for them, and probably will not work for most of the imitators who follow. The Forward Deployed Engineer model has a history, and the history is not flattering. I want to make the skeptic's case here, because the deployment epoch will be the dominant narrative for the next year, and the assumption that Palantir's economics generalize to a broader enterprise AI market is the most fragile part of that narrative.
the thesis I want to argue against
The standard FDE pitch is that embedding senior engineers inside the customer captures context, surfaces frontier problems, and feeds reusable patterns back into the core platform. Run that loop enough times and you have a product that no one without that field experience can build. Run it well and you build a moat made of operational knowledge, not just features.
That is the Palantir story. It worked at Palantir. It might work at OpenAI, Anthropic, and Google. But the conditions that made it work at Palantir are unusual, and most attempts to import the model elsewhere have ended badly. The labs are now scaling the FDE motion by an order of magnitude, simultaneously, against the same customers, with the same talent pool. That is a stress test the model has never faced.
the margin problem
Software's defining advantage is repeatable delivery at near-zero marginal cost. That is what justifies the multiples. The FDE model directly contradicts this advantage. Each engagement requires scarce, expensive talent. Each engagement requires bespoke work. Each engagement, by design, is treated as research and development, which is a polite way of saying it loses money for years.
The bet is that those losses convert into platform features everyone benefits from. The reality, in most companies that have tried this, is that the custom work does not generalize. Customer A wants a workflow Customer B finds irrelevant. The reusable substrate that was supposed to emerge from a hundred deployments looks more like a hundred slightly different snowflakes, each with a maintenance contract attached.
When that happens, the FDE organization stops being R&D and starts being a high-touch services business with software branding. Margins drift from SaaS economics toward consulting economics. Growth slows because each new dollar of revenue requires roughly proportional headcount. The exit multiple compresses because investors stop pricing the company as a platform.
This is the consulting trap. It is easy to enter and hard to exit, because the customers who paid for the bespoke work expect continued bespoke service, and the engineers who built the bespoke work expect to keep building it.
the institutional knowledge problem
FDEs are repositories of the most valuable kind of knowledge in software: how a specific customer actually works. That knowledge does not document itself. It lives in the heads of the embedded engineers. When those engineers leave, or burn out, or rotate to a new account, the customer relationship resets, and the company has to rebuild the trust and context from scratch.
This is not hypothetical. Palantir's reputation for grinding engineers through twelve to eighteen month embeds is part of what makes the model work at the unit-economics level and also part of why Palantir has historically struggled to scale linearly. The intensity of the embed produces the value. The intensity of the embed also produces the churn.
For the foundation model labs entering this game, the churn problem is worse, not better. They are competing for elite talent against each other, against the hyperscalers, and against any startup with a credible AI thesis. The same engineer who is willing to sit inside a bank for a year for OpenAI is being offered a founding role somewhere else every Tuesday.
the talent profile problem
The FDE profile is rare. You need an engineer who writes production code at a senior level, navigates C-suite politics, can sit through a six-hour change-control board meeting, and still produces a working agentic workflow at the end of the quarter. The Venn diagram of those skills is small. Palantir cultivated that profile deliberately, over fifteen years.
Most companies that imitate the model fail at hiring. The engineers they bring on are either too technical to navigate the customer or too customer-facing to write the platform. What they end up with is a high-priced solutions engineering team with a confused identity, drifting toward what professional services has always been: necessary, billable, and not strategic.
There is no shortcut. You cannot scale a rare profile to thousands of seats in two years by writing a bigger check. The hyperscale joint ventures the labs just announced are betting otherwise. I think they will discover that the talent constraint binds harder than the capital constraint.
the Zhongtai parallel
The closest historical parallel to the current FDE rush is not actually Palantir. It is China's middle platform movement, the Zhongtai strategy that Alibaba championed in the late 2010s and that almost every major Chinese tech company copied between 2018 and 2021.
The pitch was structurally identical to the FDE pitch. Build a centralized, reusable platform that absorbs the messy integration work from every business unit. Capture context once, apply it many times. Break the silos, enable rapid iteration. The promise was that the middle platform would turn integration burden into a flywheel.
The execution did not match the pitch. The middle platforms became enormous internal organizations that absorbed budget, dictated roadmaps, and produced work the business units saw as overhead rather than acceleration. By 2022, Alibaba had begun dismantling its own middle platform. Other firms followed. The strategy is now widely regarded inside Chinese tech as managerial theater, a rebranding of the integration tax rather than a solution to it.
The lesson is uncomfortable. A model that promises to capture context, reduce duplication, and produce reusable platform value is exactly the kind of model that organizations rush to copy and exactly the kind of model that quietly fails to deliver, because the underlying work does not generalize as cleanly as the slides suggest. The middle platform was supposed to be the operating system of the modern Chinese enterprise. Five years later it is mostly remembered as the operating system of a particular kind of overconfidence.
I am not predicting the same trajectory for FDE. I am noting the structural arguments are similar, and the gravitational pull toward services economics is the same.
the strongest counter
The most credible counter-argument is that AI is different because the model itself is doing more of the integration work than any previous category of software. Agents that can read a codebase, talk to tools, and produce coherent multi-step workflows reduce the human labor required at the edge. If the model gets good enough, the FDE becomes a configuration role rather than a construction role, and the unit economics improve.
There is something to this. If 2027 brings agents that can self-integrate against an enterprise data model, the FDE workload shrinks, the talent constraint loosens, and the labs' joint ventures start to look less like consultancies and more like deployment factories.
The risk is that this is exactly the version of the model that does not require the FDE in the first place. If agents are good enough to do the integration, the value migrates again, this time to the orchestration layer and the enterprise that owns the data, not to the foundation model vendor doing the deployment. The labs are betting the FDE is a permanent fixture of enterprise AI delivery. The skeptic's case is that the FDE is a transitional role the technology is in the process of automating away, and that the multi-billion-dollar bets being placed on it right now are partially funding the team that will be obsoleted in three years.
where this lands
The deployment epoch is real. The pivot from API to embedded transformation is real. OpenAI, Anthropic, and now Google are not making a strategic mistake by hiring Forward Deployed Engineers in size. They are buying a bridge across the integration gap the developer ecosystem could not close on its own.
The question is whether that bridge is the destination or just the route to it.
My read is that it is the route. The FDE model will produce real revenue, real customer references, and real platform learnings over the next three to five years. After that, one of two things happens. Either the labs successfully productize the field learnings and graduate back into high-margin software companies, or they do not, and the multi-billion-dollar joint ventures quietly converge on the economics of every other systems integrator in history.
The history of software, and the history of the middle platform, suggests the second outcome is more likely than anyone betting on FDE today wants to admit. Palantir is the existence proof that this model can work. It is not a proof that it generalizes.
If you are an enterprise watching this play out, the lesson is to use the FDE bridge while it is being subsidized by frontier-model capital, and to refuse to be locked into the bespoke layer that comes with it. The labs need your data and your operational reality more than you need their engineers. That is a stronger negotiating position than the deployment-epoch narrative would have you believe.
The deployment epoch has begun. But the deployment epoch is not where the value finally settles. It is where the next migration starts.