Palantir was founded in 2003 with a hard go-to-market problem: how do you sell software to an intelligence community whose work is hidden by design? The founders couldn't walk into a CIA office and ask what was broken.
So Stephen Cohen built a prototype in eight weeks and took it to analysts with one question: does this match what you do? For the first several rounds the answer was no. But once they had a tangible thing in front of them instead of a survey, the analysts started describing their work in concrete terms. Each conversation produced a list of edits, each list a new version. Build, show, listen, rebuild.
Then came the part the rest of the industry missed. As Palantir scaled, the standard advice (generalize across your first segment, then move on) stopped working. A counterproliferation workflow wasn't a counterterrorism workflow. Financial intelligence wasn't signals intelligence. The generalized product didn't quite fit anyone.
Enter the forward deployed engineer
The answer is most associated with Shyam Sankar, Palantir's thirteenth employee, who became its first forward deployed engineer and is credited with naming the role. The early deployments took "shoulder to shoulder" literally: three-month rotations through Kandahar, midnight helicopter rides to forward operating bases, summers embedded with Navy SEAL teams debugging databases between rocket-fire alerts.
None of that was for romance. The point was proximity. The FDE was inside the room where the work happened, close enough to see what broke, fix it, and put the fix in front of the operator without waiting on a routing slip from headquarters.
Palantir also has a scar that shows what happens without the embed. In 2013 it built Phoenix, a product for storing bank transaction data, with no customer in the room. Bank data is imperfect, and when Phoenix hit a blank date field it defaulted to January 1, 1970. Its retention design bucketed data into ten-minute windows, so it dutifully prepared a window for every ten minutes between 1970 and 2013: 2.3 million Cassandra keyspaces, and a server that needed fourteen terabytes of RAM just to boot. Vinoo Ganesh, who worked on it, doesn't blame skipped research. The team had built software for operators it had never sat beside.
The metaphor that explains the economics
The framing Sankar uses, a metaphor Bob McGrew coined: the FDE builds a gravel road, a fast, customer-specific, sometimes ugly path from where the product is to where the customer needs it to be. The product team back home looks at the gravel roads several FDEs have built, spots the pattern, and turns it into a paved highway: a general capability future FDEs can use without rebuilding it.
McGrew has described the mechanics. An FDE builds something for one customer. The product team asks what the general version would be, finds three or four other customers where the pattern applies, pulls those FDEs into one design conversation, and builds it once in the core product. Four FDEs then deploy it across four customers instead of each hand-rolling their own.
This is the difference between an FDE motion and professional services. Services firms build an endless string of gravel roads and never pave any of them. In a working FDE motion, the road network keeps growing until a new customer can drive on existing highways for most of the trip and only needs gravel for the last mile. At that point you can serve them with far less FDE labor per contract dollar, and gross margins start climbing toward software levels.
The ontology: where the value piles up
Palantir's second insight was architectural. If every FDE invented their own data representation, there'd be a different schema at every site and no coherent product. The fix was the ontology, a layer above the database where each FDE defines the objects, properties, and links that matter for that customer's domain, in one consistent format. The same engine could power a counternarcotics workflow and an aerospace manufacturing line, and improvements carried across customers.
Sankar has said plainly that this is where Palantir's economic value sits. With models commoditizing and chips concentrated in a few hands, the value in between goes to whatever grounds the model in the customer's actual semantics. A customer two years into a deployment doesn't rip and replace, because by then the ontology encodes too much of how their business really runs.
Every AI startup adopting the FDE motion should ask, from the first engagement, what its ontology is. It might be a skill library, a domain eval framework, or a workflow registry. The category stays the same: the artifact that turns each customer's lessons into leverage for the vendor and stickiness with the customer. Without it, the motion is services. With it, you have a software business with a services on-ramp.
Product strategy or sales motion? Two Palantir alumni disagree
There's a live argument among Palantir alumni about what the FDE motion fundamentally is, and both sides are right about different companies.
Vinoo Ganesh says it without hedging: "Forward deployed engineering is a product strategy. Being an FDE is an extension of the product function, not the go-to-market function." In his telling, Palantir's Foundry exists because FDEs in the field discovered, one deployment at a time, what the product needed to be.
Kevin Bai, another alum, comes at it from the commercial end. For him the FDE is a design partnership scaled into the enterprise, the motion that makes it possible to sell a deeply technical product to a non-technical buyer at all.
The way to settle it is company stage. Early on, when the platform barely exists, Ganesh is right: the FDE's most valuable output is discovering what to build, and treating the team as a sales channel starves the product of the signal it was created to produce. At scale, with the highways paved, Bai is right. The mistake is running the late-stage playbook early. As Ganesh puts it, you can treat FDEs as a go-to-market extension "when you're Palantir and have twenty years and unlimited money."
The model the industry filed away as a government-contracting oddity is now how most of AI goes to market. The alumni it produced (Anduril, Kalshi, ElevenLabs, and a long tail of others) are collectively worth more than $50 billion.