The Engineer in the Room: How OpenAI and Palantir Sell Software by Deploying Armies of People
Both Palantir and OpenAI rely on Forward Deployed Engineers embedded at client sites to make their products work. Michael Burry thinks that's a problem — and he's shorting both.
The gap between the software pitch and the consulting reality.
Introduction
There's a pitch every enterprise software company makes: buy our platform, integrate it into your workflows, and watch the results roll in. It's clean, scalable, and — critically — it justifies a premium valuation because software doesn't need to hire more people every time it wins a new customer.
Palantir and OpenAI are both making that pitch. But here's the twist: behind the scenes, both companies are deploying teams of highly-paid engineers directly into their clients' offices to make the product actually function. These are called Forward Deployed Engineers — FDEs — and they are at the centre of one of the most pointed critiques of the current AI boom.
Michael Burry, the investor made famous by his bet against the 2008 housing market, has large short positions against both companies. His argument isn't complicated: if you need to send an engineer to every customer to make your software work, you're not really a software company. And the market is valuing you as if you are.
What Is a Forward Deployed Engineer?
A Forward Deployed Engineer is exactly what it sounds like. Rather than sitting in a company's HQ building product, an FDE is embedded at a client's site — working inside the customer's environment, understanding their specific data, processes, and problems, and customising the software to make it useful for that particular organisation.
Palantir pioneered this model in the mid-2000s, originally serving intelligence agencies and the US military. The logic made sense at the time: their clients handled extraordinarily sensitive data that couldn't leave secure facilities, and the problems were complex enough that off-the-shelf configuration wasn't going to cut it. You needed smart people on the ground.
The model worked — and Palantir built an entire culture around it. FDEs at Palantir are considered elite. They're well-compensated, intellectually stretched, and often work on genuinely consequential problems. The company's early wins in defence and intelligence were built on this foundation.
OpenAI arrived at a similar model from a different direction. As it moved from API access for developers toward serious enterprise contracts, it ran into the same problem every enterprise software company runs into: large organisations are complex, their data is messy, their requirements are specific, and their IT teams are stretched. Selling a subscription is easy. Making it actually work inside a Fortune 500 company is a different matter entirely. So OpenAI started building out its own FDE capability — engineers who sit with enterprise clients and make ChatGPT Enterprise or the API actually deliver results.
Why Both Companies Have Doubled Down on This
The cynical read is that FDEs are a crutch for software that isn't quite ready to stand on its own. But that's not entirely fair.
Enterprise environments are genuinely hard. Data is siloed, legacy systems are everywhere, procurement processes are slow, and the gap between a demo and production deployment can be enormous. Almost every serious enterprise software company has some version of professional services — consultants and implementation specialists who help clients get value from the product.
The difference with Palantir and OpenAI is the scale and centrality of the FDE function to their business model. These aren't implementation consultants helping with a one-time setup. In many cases, FDEs are in active, ongoing deployments — continuously adapting the software to the client's changing needs.
For Palantir, FDEs are not a department — they are a philosophy. The company has historically been willing to deploy teams of engineers to clients willing to pay for deep, customised AI and analytics capabilities. Some of those contracts are worth tens or hundreds of millions of dollars. The FDE is what justifies the price tag.
For OpenAI, the FDE push reflects the reality that general-purpose AI needs significant work to become specific-purpose AI. Teaching a large language model to navigate a bank's compliance requirements, or an insurer's claims process, requires people — not just prompts.
Michael Burry's Position
Burry's short positions against both companies are substantial. His Scion Asset Management held put options against Palantir worth approximately $912 million in notional value, and against Nvidia worth roughly $187 million — with both bets tied to the same underlying thesis about the AI trade being overextended.
His critique of the FDE model is essentially this: the market is valuing Palantir and OpenAI's revenue at software multiples, but a significant portion of that revenue is generated and sustained by human labour deployed on-site at clients. That's not software. That's consulting. And consulting companies don't trade at 150 times revenue.
To put Palantir's valuation in perspective: at its peak in late 2025, it was trading at a price-to-sales ratio of 152, compared to Nvidia at 33x and Meta at 22x. Those are extraordinary numbers for a company whose revenue model leans heavily on the ongoing deployment of expensive engineers.
The bull case for Palantir is that the FDE model is a land-and-expand strategy — FDEs get the product embedded deeply into a client's operations, making it nearly impossible to rip out, and eventually the software runs itself. Palantir calls this the "ontology" — a shared data layer that becomes the operating system of an organisation over time.
Burry's counter is simpler: that day hasn't come yet for most clients, the FDE costs are real and ongoing, and the valuation assumes a level of scalability that the current model doesn't support.
What This Means for Enterprise Buyers
As someone who works in enterprise technology, I find this debate particularly relevant. The FDE model is genuinely useful for buyers — having a dedicated expert embedded in your organisation dramatically accelerates adoption and reduces the risk of an expensive software purchase gathering dust.
But it also creates a dependency. If the value of the product is partly in the person delivering it, what happens when that person leaves, or when the contract is up for renewal and you're asked to pay more? The switching costs are real, but so is the question of whether you're buying software or hiring engineers through a software company.
For enterprise buyers evaluating either platform, the honest question is: what does the product look like without the FDE? If the answer is "significantly less useful," that tells you something important about what you're actually paying for.
The Broader Question
The FDE story is a microcosm of a larger tension in the current AI moment. We're in a period where the narrative — AI will transform every industry, the best platforms will become infrastructure — is running ahead of the financial reality. FDEs are expensive. Training, deploying, and retaining the calibre of engineer Palantir and OpenAI recruit costs serious money. Those costs show up in margins, in headcount growth that tracks suspiciously closely to customer growth, and in the fundamental question of whether the economics ever improve the way a true software business should.
Michael Burry has been wrong before, and he's been spectacularly right before. Whether he's right about this one depends on a question that neither company has fully answered yet: can the software work without the engineer in the room?
Key Takeaway
Both Palantir and OpenAI, while impressive businesses in their own accord, have a significant part of their revenue depending on embedding human engineers at client sites, not just selling software licences. The market is pricing them as pure software companies. Michael Burry is betting that gap between narrative and reality is where the money is.
I'll have a follow up on this soon where i will go into the technical analysis of Michael Burry's thesis and why i think this is a valid concern.