The FDE Playbook: Inside the Role at OpenAI and Palantir

With the rise of AI agents, there is no incumbent product to replace. When a company buys a traditional SaaS product, they know exactly what they are getting. When an enterprise buys an AI agent, they are buying an outcome that has never existed before.

This is why the Forward Deployed Engineer (FDE) has become the most critical role in the AI ecosystem.

To understand how the role functions at the absolute highest levels, we analyzed the strategies of two leaders in the space: Colin Jarvis (Head of Forward Deployed Engineering at OpenAI) and Bob McGrew (Former Chief Research Officer at OpenAI and early Palantir executive).

Here is the ultimate FDE playbook for eating pain and excreting product.

---

1. The Palantir Origin Story: Delta and Echo Teams

Palantir practically invented the FDE role. As Bob McGrew explains, they were selling software to spies. You can’t exactly run a standard Silicon Valley A/B test on national intelligence workflows.

Palantir realized that every customer’s problem was slightly different. Instead of building a highly specialized product for one customer, they built a generalized platform (the Palantir Ontology) and sent FDEs into the field to build the “gravel road” for each specific customer.

Palantir split the FDE function into two distinct profiles:

1. The Echo Team (Embedded Analysts): Domain experts (e.g., former military officers or intelligence analysts). Crucially, they had to be “heretics”—people who understood the legacy system but hated it. Their job was to manage the account and discover the true problem.
2. The Delta Team (Deployed Engineers): Fast prototypers. These were not craftsmen looking to write maintainable code that would last 12 years. They were hackers who could eat a massive amount of pain, write rough-and-ready code, and deliver an outcome on a brutal timeline.

The Gravel Road vs. The Paved Highway

The FDEs (Deltas) build the gravel road. They hack together whatever is necessary to solve the CEO’s top 5 problems in the client’s messy environment.

The internal Product Team then looks at that gravel road, analyzes how it could generalize to the next 10 customers, and builds the “paved highway.” This tension between FDEs wanting to solve the immediate problem and the Product Team wanting to build generalized software is exactly what creates billion-dollar B2B AI products.

---

2. OpenAI’s Approach: Zero-to-One and “Eval-Driven Development”

At OpenAI, the FDE team is viewed as a “Zero-to-One” SWAT team. They aim at problems that can save or generate customers tens of millions to low billions of dollars.

Colin Jarvis explained how OpenAI approaches enterprise deployment:

Building Trust Takes Longer Than Building the Tech

When OpenAI deployed GPT-4 at Morgan Stanley for wealth management, the core technology (Retrieval-Augmented Generation over research reports) was working in 6 to 8 weeks.

However, it took another 4 months of running pilots, collecting evals, and iterating before the wealth advisors actually trusted the system enough to use it. The FDE job is not done when the code compiles; the job is done when the user adopts it.

Eval-Driven Development

FDEs at OpenAI use what they call “Eval-Driven Development.” When working with a major European semiconductor company to fix hardware verification bugs, they didn’t just let the LLM loose.

They built deterministic guardrails. A piece of LLM-written code is not considered “done” until there is a rubric-graded suite of evals that mathematically verifies its efficacy. The LLM handles the probabilistic reasoning, but the FDE builds the deterministic scaffolding to ensure it never hallucinated a critical supply chain disruption.

Excreting Product: From Custom to AgentKit

A successful FDE engagement shouldn’t just result in a happy customer; it should result in a new product.

OpenAI’s FDE team worked with Klarna to build a customer service application that scaled across 400 different policies. They realized that parameterizing instructions and tools was highly effective. They open-sourced this as a framework called Swarm.

They then took Swarm to T-Mobile (a 10x more complex environment) and validated it again. Finally, they handed those validated primitives back to the core Product team, which eventually resulted in the release of the Agent SDK and AgentKit.

This is the ultimate evolution of an FDE: you eat the pain of a massive enterprise deployment, and you excrete a generalized product that the rest of the world can use.

---

3. Why AI Startups Must Adopt the FDE Model

If you are an AI startup founder, you cannot rely on traditional SaaS product-market fit (PMF).

In traditional SaaS, PMF means you find a flow that works, and then you scale by touching the customer less. You want zero-touch onboarding.

With AI agents, the opposite is true. According to McGrew, the FDE model is about doing things that don’t scale, at scale. You want to touch the customer more. You want to drive the contract size up by embedding deeply into their organization and solving higher-value problems over time.

You aren’t selling software seats; you are selling an outcome. And the only way to guarantee an outcome with a probabilistic model is to put a Forward Deployed Engineer in the room to make sure it works.