On this page
Picture a typical "FDE project." Three engineers move into the client's office. By day they run requirement workshops with the business; by night they write APIs, edit SQL, wire up models, and build agents. Two weeks later a working system goes live. Three months later the project is signed off and the engineers go home.
The code sits in a client-specific repository. The requirements docs get filed away. Six months on, a different client has a similar need, so the company dispatches three more people, runs discovery all over again, builds another database, and rewrites the same business logic.
Many Chinese companies today would call this a "Palantir-style FDE."
It is certainly high-intensity, close-to-the-business engineering delivery. But if you want to borrow Palantir's FDE story, there is a more important question to answer:
After the engineers leave, what did the project actually leave behind for the company's underlying platform?
If the answer is mostly project experience, customer relationships, and a private codebase, then it is still a long way from Palantir's Forward Deployed Engineering.
1. The Point of FDE Is Not "Forward" — It Is the Platform Behind It
Palantir's own description of its platform already makes this clear.
In Foundry, the Ontology is defined as a digital model of the enterprise: datasets and models are mapped into Object Types, Properties, Link Types, and Action Types. This describes which business objects exist, how they relate to one another, and what actions people and systems can take on them.
In its platform architecture documentation, Palantir even calls its software architecture built around the Ontology a key differentiator.
So when a Palantir FDE joins a company, the job is not simply "the client asks for features and I build them."
The more central job is to translate the business semantics of the client's real world into structures the platform can operate on continuously:
Business entities become Objects.
Entity relationships become Links.
Business states and executable operations become Properties and Actions.
Data scattered across ERP, CRM, databases, files, and APIs flows into a unified data pipeline.
Ultimately, analytics, applications, agents, and automated workflows all rest on the same enterprise semantic model.
This step matters enormously.
A single application will go stale, requirements will change, and models will be replaced — but business semantics such as "what is an order," "what is a customer," "how do devices relate to work orders," and "who is allowed to perform which action" have a much longer life.
The genuinely valuable engineering output of an FDE is the gradual encoding of this tacit business knowledge into a computable, reusable enterprise model.
Being on-site is just one way to deliver it.
Palantir's own FDE openings now include both on-site and hybrid roles, and some positions only require traveling to the client site as needed. That alone shows that "sitting in the client's office every day" is not a sufficient condition for defining the role.
2. Why the Ontology Compounds
Once you understand this layer, the "compounding effect" often discussed around Palantir becomes easy to grasp.
Suppose a company's core business objects, permissions, relationships, data pipelines, and Actions have already been modeled into the Ontology.
The first use case is usually heavy.
The FDE has to understand the business, connect the data, handle permissions, define objects, establish relationships, design Actions, and then compose them into an application or workflow.
But from the second and third use cases onward, much of the foundational work is already done.
New agents can understand existing Objects directly; new applications can reuse existing permissions and Actions; new automations can call data pipelines that already exist; and new departments can extend the same enterprise semantic network.
This produces a crucial engineering phenomenon:
The additional code and modeling required for each new client requirement should keep shrinking.
That is the technical basis for "getting faster as you go."
If every client project has its own database, its own prompts, its own Python scripts, its own permission system, and its own front end, then it does not matter whether the team stays on-site for six months or two years — delivery cost stays roughly linear.
Ten more projects will, in all likelihood, require more engineers.
The model Palantir is after is one where the tenth use case builds more on the assets created by the first nine.
This is one of the dividing lines between a platform company and a project company.
3. The Overlooked Half: Organizational Compounding
Technical architecture only solves half the problem.
The other half comes from organizational design.
In 2026, a Palantir FDE with 14 years of experience, discussing Forward Deployed Engineering in the Palantir Developer Community, used a very precise word: metabolize.
Experience gained by field teams has to be continuously "metabolized" into the core platform. He also stressed that core product engineers, field teams, and internal operations teams are all part of the same Forward Deployed Engineering loop.
This matters especially for the many so-called FDE teams in China.
A team can absolutely have excellent engineers who genuinely sit with clients and solve hard problems — yet its organizational structure determines where that knowledge ends up.
The project ends and the group chat is dissolved.
The code stays in the client's repository.
Key design decisions live only in some engineer's head.
Capabilities added ad hoc for one client never make it onto the platform roadmap.
The next team does not even know the previous team solved a similar problem.
That kind of organization can hardly compound.
What it becomes, in the end, is IT services with strong engineering skills.
A true FDE model requires an extremely short feedback loop between field delivery and the core product:
Client problem → field abstraction → platform capability → reuse by the next client → new problems feed back into the platform.
If that chain breaks, Forward Deployed is left with only the Forward.
4. The Real Thing to Study in AIP Bootcamp Is the Switching Cost It Creates Up Front
This also explains why Palantir's AIP Bootcamp is such a fascinating piece of business design.
Palantir's definition in 2023 was blunt: clients and Palantir engineers work hands-on-keyboard to build a real use case from scratch in five days or less. Palantir's official documentation still describes Bootcamp as working alongside engineers to complete a use case in hours or days.
On the surface, it shortens the POC cycle.
From an architectural perspective, there is a deeper layer.
Once the client starts encoding its own data, business objects, decision logic, and workflows into the Ontology, what the two sides are actually building together is a piece of the enterprise's operating model.
If that co-building happens before a long-term purchasing decision, a switching cost can appear early.
Down the road, moving platforms would mean migrating far more than a few tables. The enterprise would have to re-express Objects, Links, Actions, permissions, and data pipelines, along with the workflows built around them.
This warrants caution.
The mechanism is, of course, a commercial moat for Palantir. But from a buyer's view, it is also a highly effective lock-in design.
When evaluating platforms like this, a company should not only ask "how fast is the POC?" It should also ask:
For the enterprise semantics we model together today, how would we migrate them when we leave the platform?
Good platform compounding and vendor lock-in often come from the very same technical mechanism.
5. Long Contracts Are an Outcome, Not the Cause
Another common misreading attributes Palantir's long customer relationships to "long-term contracts."
Palantir discloses in its SEC filings that it typically offers one- to five-year contracts, with shorter terms as well, and many contracts allow the client to terminate early.
What deserves more attention is customer expansion.
Palantir's Net Dollar Retention was about 114% in mid-2024, then rose to 120% in Q4 2024, 124% in Q1 2025, 128% in Q2, 139% in Q4, and 150% in Q1 2026 — reaching 157% in Q2 2026. Put roughly, it climbed from around 115% to 157% over about two years.
NDR alone obviously cannot prove that the Ontology is the only cause.
But it does reveal an important feature of Palantir's business model: a great deal of growth happens inside customers who are already on the platform.
A client starts with one scenario, and the underlying objects and data begin to be modeled. Then a second department, a third workflow, more Actions, and more AI use cases follow. As the platform gradually becomes operating infrastructure, continuing the relationship and expanding the contract naturally makes more sense.
Long-term contracts should therefore be read as a commercial outcome of platform compounding.
If a "FDE company" grows client revenue mainly by signing three-year framework agreements and adding more on-site staff, it is copying the operating model of a large IT outsourcer.
The metric that actually matters is whether a client's second requirement is clearly easier to deliver than the first, and whether the third is faster still.
6. One More Easily Confused Term: AI FDE
One term needs clarifying here as well.
The traditional Palantir FDE is a human engineering role.
Palantir later shipped a product called AI FDE, which entered beta in November 2025 and reached general availability on March 12, 2026.
AI FDE is an AI agent running inside Foundry. Through natural language, it can perform data transformations, manage code repositories, create and modify the Ontology, write Functions, and operate other Foundry capabilities.
The two should not be conflated.
But the arrival of AI FDE actually reinforces the earlier logic: once a company's data, objects, Actions, permissions, and workflows already live in a unified way inside Foundry, many platform tasks that once required a human FDE become eligible for agent automation.
The capability boundary of AI FDE is, at bottom, inherited from the platform modeling already done beforehand.
7. Six Questions for Chinese Firms to Tell Whether They Are Actually Doing FDE
So rather than giving solution engineers a trendier job title, check these six things:
-
Are all client projects built on the same core platform architecture? If every project ends up as its own standalone codebase, that is the first warning sign.
-
Does the team continuously abstract business objects, relationships, and Actions? Shipping features is only the first layer; forming a reusable business model is what creates lasting value.
-
Is a client's second use case noticeably faster? If every new requirement still takes a similar number of person-days, platform compounding has not happened yet.
-
Can cross-client problems settle into platform capabilities? Data connectors, permission capabilities, workflow frameworks, and shared components can all be productized — but you must draw a strict line between client-private business semantics and genuinely productizable capability.
-
Is there an institutionalized feedback mechanism between FDEs and the core product team? If experience only accumulates in individuals, the organization gains no compounding at all.
-
Can you explain both your client lock-in mechanism and your exit mechanism? The deeper a platform goes into the business, the higher the switching cost. A mature enterprise AI company should think about data portability, model replaceability, and the explainable boundaries of business logic at the same time.
What Chinese AI companies should really learn is not "send someone who understands the business and can write code to the client site."
Consultancies, systems integrators, and software outsourcers have been doing that for decades.
What makes Palantir worth studying is that it tries to turn the complexity of every client site into structures the platform can call on again and again.
The deeper the client goes, the thicker the platform; the thicker the platform, the cheaper the next requirement.
Only once this loop is truly established does Forward Deployed Engineering begin to shift from a high-cost delivery method into a platform-building mechanism that compounds.
So the next time a company says it is building an "FDE team," the only question worth asking may be this:
After these FDEs finish a project, what did your platform actually gain?