What Is an FDE?

A concept increasingly mentioned in real AI deployment is FDE. It represents work that must happen between technical capability and production results. A model may generate content, analyze data and act, but a business still has questions: who connects data and systems? Who handles access and security? How does the workflow change? How do people actually adopt it? Who remains responsible for results?

FDE stands for Forward Deployed Engineer, a role proposed and used by Palantir; the original full title was also Forward Deployed Software Engineer (FDSE).

The history of the role predates the generative-AI deployment boom by nearly twenty years. This article asks what FDE is, where it came from and how it works.

FDE grew out of Palantir's customer sites

In 2006, Shyam Sankar, with a background in electrical and computer engineering, joined Palantir as employee number 13. He later became CTO and was among the company's earliest Forward Deployed Engineers.

When he joined, CEO Alex Karp asked an unusual question: why can French restaurants maintain such a high standard?

Karp observed that good restaurant servers participate deeply in the whole system. They understand dishes, preparation and guest feedback, and bring what happens at the table back to the kitchen. Front and back of house become a system continually responsive to guests. Karp wanted Sankar to create a similar organization for software engineering.

This analogy addressed a real problem. Palantir's early customers were largely intelligence and military organizations whose data was scattered across systems, permissions were strict and missions changed on the ground. Users struggled to write complete software requirements in advance; headquarters could not understand their daily decisions and actions from a few interviews.

Palantir placed engineers able to change the product alongside users. They observed real work, encountered actual contexts, data and constraints, wrote and deployed code on site, then adjusted from use. In the restaurant analogy, if the core product team is the kitchen and the customer site the table, the FDE is the server between them, seeing work and bringing feedback back to improve the product.

In “The Primacy of Winning”, Sankar says he named the approach Forward Deployed Engineering in 2007, borrowing the idea of deployment to the front line from Palantir's customers. A contemporary 2009 Science report already called Sankar and colleagues “forward-deployed engineers.”

FDE has two meanings: a delivery model embedding engineers at customer sites, and a job title for the people carrying it out.

How does Palantir divide the model into roles?

A delivery model and frontline roles

Palantir summarizes the model as “FDE is a radical commitment to the outcome.” Engineers enter the customer's real environment from the first conversation and remain involved through building, launch and use until the system changes how the customer operates.

Palantir distributes this responsibility among Echo, Delta and Dev, collaborating on one customer outcome with different primary ownership.

Echo, or Deployment Strategist, owns the business problem and adoption path. Working in users' daily environment, Echo clarifies data, decisions and bottlenecks, turns vague needs into defined problems, success criteria and workflows, then organizes training, observes feedback and validates business impact after launch. Palantir's Deployment Strategist job description describes these activities.

Delta is the narrower FDE role. Early frontline delivery centered on platforms, data and production software, so a typical title was FDSE. In the AI era, models, context, tool calls and evaluation enter the delivery scope, and Palantir includes Forward Deployed AI Engineers—FDAEs—in Delta. The role retains FDSE's outcome responsibility while focusing more on AI-era software and is the FDE most often discussed today.

Delta turns Echo's defined problem into a sustainable production system: connect data, write code, build applications or Agents, and supply permissions, evaluation, monitoring and exception handling. After launch it maintains the outcome and returns field experience to product teams.

Dev turns recurring needs across projects into platform capabilities. Common data connections, permissions, model evaluations and workflows become reusable product components for future Delta teams.

Palantir's official explanation distinguishes them as mirror images:

• Delta: one customer, many capabilities. Ownership centers on one customer's result, combining platform, data, code, applications, models and tools.
• Dev: one capability, many customers. Ownership centers on a reusable product capability serving many customers.

Return to the restaurant:

• Echo is like the front-of-house manager, understanding guests' real needs, designing service and observing satisfaction.
• Delta is like the on-site head chef, turning needs into dishes and owning the result.
• Dev is the central-kitchen R&D chef, turning recurring recipes, sauces and tools into standard capabilities for many restaurants.

Palantir also notes that Echo is typically closer to product management and Delta more technical, but both participate in product, engineering and strategy. In my own AI work, Echo feels like an AI product manager who understands marketing growth and customer sales; Delta resembles a full-stack engineer who understands products and algorithms.

I do not specifically call myself an FDE, though people have contacted me for similar services. Some may have been misled by people using the term on Douyin: FDE has demanding requirements. Installing Claude Code or Codex, making a couple of Skills and offering training is not the full work. My current positioning is closer to Echo—talking with customers, organizing business and processes, and proposing solutions and strategy—consistent with my experience as an AI-assisted marketing expert and product manager.

To see how outcome responsibility becomes a sustained AI workflow, we also need the underlying system.

What system foundation supports FDE?

Palantir's frontline teams do not build from zero at each site. They bring three existing platform capabilities. Palantir describes Foundry for data operations, AIP for generative AI and Apollo for continuous delivery. They answer: how is a business system built, how does AI enter it, and how does software continue to deploy and run?

Foundry connects raw data from databases, tables and legacy systems to company rules and daily work, so the system can interpret information, support judgments and employee actions, and link reminders, approvals and next steps. A key layer is the Ontology: defining business concepts such as customers, orders, assets, projects and people as objects, their properties and relationships, possible actions and permissions. Foundry is not only storage or reporting; it brings data into daily decisions and execution.

Ontology began as a philosophical concept, asking what exists, what things are and how they relate. Computer science borrowed the term for explicit domain concepts and relations that machines can process.

In our restaurant, the front desk sees reservations and tables, servers see guests and orders, the kitchen sees dishes and ingredients, and finance sees bills. They serve one meal but keep scattered records. An Ontology defines guests, reservations, tables, dishes, orders and staff as business objects; it records who booked which table, which dish belongs to which order, what an inventory shortage can trigger and who may change a table or waive a bill.

When an owner asks AI, “Which important guests have not confirmed tonight? Which orders may be affected by shortages? Remind the people responsible,” AI need not guess fields and infer relations across tables. It can find objects, judge relationships and perform permitted actions in a defined business world. Ontology is like a map of the business world shared by staff, software and AI.

AIP is Palantir's generative-AI platform, not one model or just a chat box. It safely connects selectable models to Foundry and Ontology context, permissions and actions, letting teams build Agents, automation and AI applications and check reliability using evaluation, logs and monitoring. Foundry defines what the business has and can do; AIP lets AI understand, judge and act within that scope.

Apollo is a continuous-delivery platform, described as mission control for automated deployment. It manages software versions, environments, approvals, monitoring, upgrades and rollback for Foundry and AIP across cloud, on-premises and restricted or isolated networks. It does not interpret business or make AI reason; it keeps the other systems running reliably across environments.

Together, Foundry makes business executable, AIP connects AI and Apollo sustains delivery and operation. FDE combines them around a customer problem into an AI system or workflow that can enter real production.

This foundation grew over time. Gotham and other early products connected intelligence and operational data to field work. Foundry expanded from data into analytics, machine learning, modeling, simulation, digital twins and workflows. Apollo addressed continuous delivery across environments. AIP joined as a separate AI platform after generative AI rose in 2023, connecting models, Agents, automation and evaluation to the existing system.

The foundation is both a product of FDE and its support. How does the model turn a specific site problem into something people use, that runs reliably and improves?

Turning a customer problem into a sustainable system

The point is not delivering platform features one by one, but owning a problem from discovery and modeling through launch and improvement.

Palantir does not prescribe a fixed series of FDE actions. Its materials emphasize a continuous loop: engineers get close to customer problems, build and deliver on site, and return feedback to core engineering to evolve the product. Palantir calls it “the human version of backpropagation”.

Backpropagation trains a neural network by producing a result and adjusting parameters based on error. Applied metaphorically to FDE, product capability enters the customer site; problems exposed there return to the core product team and drive updates. Put a working solution into real business, see where it does not fit and what users need, adjust quickly and retain effective methods in the general product.

Former Palantir FDE Nabeel Qureshi, who spent eight years there, describes the process more concretely: spend most of the week on site understanding real workflows, quickly build a small usable piece of software, validate it with users and revise from feedback. FDE solves the current customer's problem first; the core team extracts common needs and turns successful solutions into capabilities for more customers.

OpenAI provides a more complete description for AI-era FDE: diagnose where AI can create value, choose a few priority workflows, connect models to enterprise data, tools, permissions and processes, then design, build, evaluate and review safety before a controlled launch and continued improvement from real results.

Despite different products and organizations, a recurring line appears: find a worthwhile workflow on site, build a functioning system, validate it in production and return effective learning to the product.

To remember this field-to-product path, I distilled it into the DRIVE loop: Discover the problem; Represent an executable business model; Implement and verify a minimal loop; Validate in production; Evolve by returning field learning to the product.

1. Discover. Echo enters actual work to see who does it, how and where it gets stuck. Before making a product, define the problem, success criteria and pilot boundary: what should change and how will we know it helps?

2. Represent. Echo and Delta translate field language into objects, relations, rules, actions and permissions: who the customer is, who may approve, when to remind and when to hand off to a person. The Ontology is not merely copying material into a table; it gives people, software and AI a shared understanding of what is being handled and what can be done.

3. Implement. Delta connects real data and tools and makes an application, automation or Agent. Rather than deploy every feature at once, make one end-to-end task work with real data and test crucial assumptions through evaluations and user tests.

4. Validate. Echo and Delta add security, access, monitoring and exception handling, encourage adoption and observe results. This is complete only when the system enters the workflow, operation is visible and business results can be checked.

5. Evolve. Delta and Dev separate customer-specific needs from recurring ones, turning the latter into reusable components, tools or methods for the next project.

Real projects move back and forth among the five stages, with Echo, Delta and Dev collaborating throughout. Represent is crucial: the roles translate what people handle, how things relate and what can happen next into an identifiable business model—the Ontology.

Three takeaways:

1. FDE is a role and a way of connecting site problems, business models, production systems and feedback in a loop.
2. Echo, Delta and Dev collaborate; Delta is FDE in the narrower sense, with Foundry, AIP and Apollo supporting the team.
3. The model can be understood through DRIVE. A particularly important step is Represent: translating real business problems into machine-recognizable Ontology. I may discuss Ontology in a separate piece.