The Difference Between a Forward Deployed Engineer and a Consultant With a Better Title Is One Design Decision
Palantir's echo/delta split, the gravel-road-versus-paved-road tension, and the four questions that tell you if your FDE program is real.
A note on how this gets made: the thinking, the research, and the position are mine, in the words and the images both. AI does the assembly. I work this way because it makes me learn and think harder, not less, and that's worth saying openly, not quietly disclaiming.
Palantir's founders had a specific problem building their first customers in the intelligence community: they didn't know any spies. No network, no warm intros, no existing relationships to sell into. So they did what any founder is told to do. They built a demo, put it in front of a real prospective user, took the feedback, and iterated.
That part of the story is standard startup advice. The part that isn't standard is what happened after they found product-market fit.
Most companies, once they know what to build, move to scale it: one product, sold the same way, to each customer, with the goal of doing less custom work per account over time. Palantir did something closer to the opposite. It built a platform, and it put its own engineers physically inside each customer's building to construct the specific thing that customer needed on top of it. That embedded presence wasn't overhead to be minimized. It was treated as the actual product.
That's the origin of the Forward Deployed Engineer, and it's worth understanding the mechanics before you decide whether your own company should build one.
Why the LinkedIn version isn't the whole story
My LinkedIn piece on this covered the headline: Microsoft, Amazon, OpenAI, and Anthropic have all committed real money, close to $9 billion combined, to forward-deployed engineering units in the same month, because 95% of enterprise AI projects studied by MIT show no measurable business impact. That's the public thesis, and it's real.
The part it leaves out is what determines whether any given FDE program works: the internal design decision that separates it from expensive consulting with a better job title. That's a leadership question, not a hiring one, and it's the one I'd want answered before building or buying into a program like this.
The two roles the job posting leaves out
Palantir's model runs on two distinct functions working together. One, sometimes called the echo team, is embedded analysts with real domain depth (often ex-military, ex-healthcare, someone who's lived inside the world being sold into) whose job is to find the customer relationship and identify which problem is worth solving. The other, the delta team, is the engineers who take that problem and build a working prototype fast, with the expectation that the first version gets thrown away.
Neither role works without the other. An echo team with no delta team produces relationship management with nothing shipped. A delta team with no echo team produces technically impressive software no one at the customer needed.
The discovery only survives contact with the customer's organization if it's solving something inside that customer's own CEO's top five priorities. Solve something adjacent to that, however clever, and there's no organizational energy at the customer to push it through.
The tension that doesn't fully resolve
Here's where most attempts to copy this model quietly fail. The FDE's job is to solve one customer's problem the simplest way that works: the gravel road. The product team's job is to build something that serves many customers at once: the paved road. Those two things usually look structurally different from each other.
If the product team tries to design the paved road by sitting in a room thinking hard about it, without FDE input, they build the wrong thing more often than not. The pattern that works instead: the FDE team ships something for one customer, brings it back to the product team, the product team identifies which other customers would benefit, and FDEs from those other accounts join the room when the generalized version gets designed.
This is also the honest answer to the "isn't this consulting" criticism, which is a fair one to raise. Margins on a new account often start negative and turn positive only after a year or more on-site, which looks exactly like a services business if you stop the story there. The reason it isn't one: Palantir invested in a general underlying schema, an "ontology" of objects, properties, and links flexible enough to encode wildly different domains (a person, a ship, a money transfer) without a bespoke product per customer. Building for one customer risks over-fitting to that customer forever. The discipline is pulling up a level of abstraction each time, until you find the operation that's common across accounts, and that discipline is what turns embedded engineering into a product business instead of a labor business.
What leaders should actually inspect before scaling this
If you're evaluating a vendor's FDE program, or thinking about building your own, the job title tells you nothing. These questions do:
Is the problem it's solving a genuine top-five priority for the customer, or a nice-to-have? If it's the latter, no amount of embedded engineering talent will get it through the customer's own organization.
Is the deal structure built for this, or is it a standard support contract with a fancier name on the seat? Access level, response SLAs, and who owns the outcome all have to be real commitments, not marketing language layered onto an existing services line.
Is there a path from one customer's solution to a reusable product feature, or does each account start from zero? If nothing generalizes, you're running a services business that happens to call its staff engineers.
Is your own platform complex enough to need this, or is the complexity coming from somewhere else (integration debt, unclear ownership, a process problem dressed up as a technical one)? Forward deployed engineering is expensive. It's worth it when the problem is real and worth solving. It's an expensive way to paper over a problem that wasn't about engineering in the first place.
I've watched Salesforce, Agentforce, and MuleSoft forward-deployed engineers collaborate on the same account, and the pattern holds in practice: when the answers above are yes, the engineering effort compounds into something the customer keeps and the vendor can resell in a different form. When the answers are no, it's a consultant with better branding, and the customer eventually notices.
What to inspect next
If your company is evaluating a vendor's forward deployed program, or building one of your own, run the four questions above against the actual contract and org chart, not the pitch deck. The gap between those two documents is usually where the truth is.
Sources
Bob McGrew (former Chief Research Officer, OpenAI; early Palantir executive; now serving with a US Army Reserve technology advisory unit), on the origin and mechanics of Palantir's forward deployed engineering model, background material for this piece.
Companion piece on LinkedIn, covering the 2026 industry-wide forward deployed engineering build-out across Microsoft, Amazon, OpenAI, and Anthropic: https://www.linkedin.com/pulse/microsoft-amazon-openai-anthropic-just-committed-9-devinarayanan-xnbjc
CNBC, Microsoft commits $2.5 billion, 6,000 employees to AI implementation unit: https://www.cnbc.com/2026/07/02/microsoft-commits-2point5-billion-6000-employees-ai-implementation-unit.html
TechCrunch, Microsoft launches its own AI deployment company with $2.5 billion commitment: https://techcrunch.com/2026/07/02/microsoft-launches-its-own-ai-deployment-company-with-2-5-billion-commitment/
GeekWire, Microsoft unveils $2.5B "Frontier Company" to embed AI engineers inside customers: https://www.geekwire.com/2026/microsoft-announces-2-5b-frontier-company-to-embed-ai-engineers-inside-customers/
Salesforce Ben, What Salesforce Forward Deployed Engineers Do and How You Can Become One: https://www.salesforceben.com/what-salesforce-forward-deployed-engineers-do-and-how-you-can-become-one/