FDE in the AI Era

Foundation models revived a role Palantir invented in 2006. In 2025-2026, OpenAI runs a $4B deployment JV, Anthropic launched a $1.5B FDE consulting JV, and Ramp organizes FDEs into pods. Here is what changed.

Why AI revived the FDE role

For most of the 2010s, the FDE pattern was associated with Palantir, and SaaS companies viewed it as an artifact of selling to government and finance. Foundation models changed that abruptly. A model that can read a customer's emails, write code in their codebase, or summarize their tickets is generic in a way no SaaS product ever was, and generic in exactly the way that makes FDE work valuable. The customer has the workflow, the data, and the constraints; the model has the capability. The engineer who closes the gap is the FDE, and the gap-closing work, evaluation pipelines, retrieval over their corpus, guardrails calibrated to their tolerances, UI hooks into their existing tools, is mostly engineering, not prompting.

The 2025-2026 landscape, with names

OpenAI announced the 'OpenAI Deployment Company' in 2025, structured as a $4 billion joint venture with TPG, Advent International, Bain Capital, and Brookfield. OpenAI also acquired Tomoro, an FDE-style firm, which brought roughly 150 FDEs in-house. By mid-2025, OpenAI had 10+ FDEs across 8 cities on 3 continents, led by Colin Jarvis (up from about 2 in early 2025). Anthropic announced a $1.5 billion standalone FDE consulting joint venture with Blackstone, Hellman & Friedman, and Goldman Sachs in May 2026, with a $300 million founding commitment. Anthropic's own job listings advertise founding FDEs in Boston, NYC, Seattle, San Francisco, and DC. Ramp organizes about 15 FDEs in pods, led by Leo Mehr. Google Cloud's FDE org expanded aggressively under Thomas Kurian, with reporting suggesting (attributable to industry chatter, not an official statement) that the interview loop was compressed from 4-6 rounds over weeks to as few as 2 rounds in 2 days. The race is real and quantified.

The three-phase engagement

OpenAI describes its engagement model publicly on the Deployment Company page in three phases. Phase 1, Early scoping: 'a couple of days onsite with the customer' to understand the workflow before any building. Phase 2, Validation: building evals and quality checks calibrated to what 'good' means for that customer. Phase 3, Delivery: onsite presence 'typically for a few days per week' while the system is built and put into the customer's hands. The structure is doing real work. The first onsite trip de-risks the project before engineering commitment, the evals create the contract for what counts as done, and the delivery phase preserves the bandwidth advantage that comes from being in the same room as the user. If you are interviewing, knowing this three-phase structure and being able to talk about what you'd do at each is concrete signal.

Evals are the new tests

In conventional software, tests tell you a change didn't break something. In AI software, that role belongs to evals: a set of inputs with expected (or graded) outputs that you run before and after a change. As an FDE you will spend more time building evals for one customer than you ever spent writing unit tests for a feature, because their data is the eval set. Not Anthropic's, not OpenAI's. Theirs. A good customer-specific eval suite has three things: a labeled set of inputs that look like real production traffic, a grading rubric that captures what 'good' means for this customer (often unique), and a way to compare two model or prompt versions on it cheaply. Anthropic's job listing explicitly lists 'evaluation' as a required production LLM skill alongside prompt engineering, agents, and deployment-at-scale. Without an eval suite, every prompt change is theological.

Prompts and models drift; engineers don't

Models change underneath you. Anthropic deprecates a version, OpenAI tweaks behavior, your fine-tuned model is retrained. Each of those events can break a customer engagement silently: outputs subtly degrade, edge cases that used to be handled regress, formatting shifts in ways their downstream parser doesn't tolerate. As an FDE, you own this risk even when it's not technically your code that changed. The mitigations are: pin model versions where the provider allows it, run the eval suite on a schedule (not just at deploy time) and alert on regression, and treat any provider-side model upgrade as a real engineering project that needs re-evaluation before customer rollout. Customers who haven't lived through one of these silent regressions don't know to ask; you have to volunteer it.

Guardrails are customer-specific

Every AI deployment needs guardrails: refusing certain topics, redacting certain inputs, validating outputs, falling back when the model is uncertain. The catch is that the right guardrails are almost entirely customer-specific. A healthcare customer needs PHI redaction with audit trails. A financial-services customer needs explicit disclaimers and human review on certain outputs. A retail customer mostly needs the system to not say embarrassing things about competitors. Cribbing guardrails from one customer to another usually produces something either too lax (blowing past the new customer's compliance line) or too strict (refusing useful queries the new customer expected to work). Build the guardrail layer thin and configurable, and write the actual rules per engagement.

The trust ladder

AI features are adopted in stages, and an FDE's job often involves moving a customer up the ladder rather than dropping them at the top. The bottom rung is suggestion mode: the model proposes, the human always reviews. The middle is supervised autonomy: the model acts on its own for safe categories, escalates for risky ones. The top is full autonomy: the model just does it. Customers almost always overestimate which rung they're ready for in the first meeting and underestimate it after the first surprise. The right FDE move is to ship at the rung below where they think they want to be, get them comfortable with the failure modes, then move them up explicitly when the evals support it. Skipping rungs is how AI projects implode politically.

Key takeaways

•Foundation models revived the FDE pattern because they are generic in exactly the way that demands customer-specific wrapping.
•OpenAI Deployment Company is a $4B JV (TPG, Advent, Bain, Brookfield) with 10+ FDEs in 8 cities led by Colin Jarvis; acquired Tomoro brought ~150 more.
•Anthropic FDE consulting JV with Blackstone/Hellman & Friedman/Goldman Sachs, $1.5B, $300M founding commitment, announced May 2026.
•OpenAI's public 3-phase engagement: scoping (days onsite) → evals → delivery (days/week onsite). Each phase de-risks a specific failure mode.
•Evals replace unit tests as the way you know a change is safe. The customer's data is the eval set. Anthropic's own job spec requires production eval experience.
•Models drift underneath you. Pin versions, run evals on a schedule, treat upstream upgrades as projects.
•Guardrails are customer-specific. Build the layer thin and configurable; write the rules per engagement.
•Move customers up the trust ladder one rung at a time; don't deploy where they say they want to be.

Exercise

Pick an AI feature you've used or built. Sketch what its eval suite would look like for one specific customer profile: 10 input examples, the grading rubric, and which of the three trust-ladder rungs the deployment should start at. Then plot what onsite presence you'd need across OpenAI's three engagement phases.

Self-check

1.Name the structural form each of these companies has chosen for FDE work: OpenAI, Anthropic, Ramp.
2.What are the three phases of OpenAI's described engagement model, and what failure mode does each one de-risk?
3.Why are evals more important than unit tests for AI features in customer environments?
4.Why does cribbing guardrails from one customer to another usually fail in both directions?
5.Why is starting one rung below the customer's stated comfort level the right move on the trust ladder?

Sources

Next lesson

Productionizing Custom Work

When does Palantir push a Delta's work into the Foundry platform? When does it stay bespoke? The rule of three, the handoff problem, and the contract you owe the team that inherits the code.

→