Silicon Valley's hottest job is here! 100+ AI companies are scrambling for FDEs — even OpenAI is hiring
As AI model capabilities iterate rapidly, "how to put AI into practice" has become the key challenge, and the Silicon Valley FDE model (the on-site engineer model) is rising again. Over 100 AI agent companies, along with OpenAI, are recruiting FDEs — engineers stationed at customer sites who bridge the gap between "what the product can do" and "what the customer needs."
With model capabilities iterating so fast, how to actually put AI into practice has become a topic on everyone's mind.
The reason is simple: even though AI is powerful, figuring out how to truly weave this "magic" into your own complex, specific business processes has become an almost insurmountable gap.
So, to solve this problem, a new model has re-emerged in Silicon Valley: the FDE.
Simply put, an FDE is an engineer stationed at the customer's site, responsible for bridging the huge gap between "what the product can do" and "what the customer needs."
How hot is this model right now? On YC's job board, more than 100 AI agent companies are hiring FDEs, and even OpenAI itself has built an FDE team dedicated to serving major clients.
Even Bob McGrew (former Palantir executive and former Chief Research Officer at OpenAI) couldn't help joking: when he attended an AI startup conference, nobody was interested in ChatGPT or GPT-4 — everyone just wanted to ask him one thing: how exactly does Palantir's FDE model work?
Today, Crow is going to talk about why this heavy, exhausting model from over a decade ago suddenly caught fire in the AI era.
01 The FDE model: the backbone of Palantir's $400 billion valuation
The FDE model originated at Palantir.
It's no exaggeration to say that the FDE model is what built today's $400 billion Palantir.
The story starts from Palantir's founding. In 2003, Palantir had just been established and wanted to build an analysis software for the CIA (Central Intelligence Agency) and the NSA (National Security Agency).
But they ran into trouble right away. Because of the special nature of intelligence work, you simply couldn't ask spies directly "how do you do your job" — no one would ever tell you.
What made it worse was that these tasks varied enormously: counterterrorism, counter-nuclear proliferation, anti-money laundering... they all sounded like "information analysis," but the data sources, workflows, and priorities were completely different.
At the time, Palantir founder Stephen Cohen brought a demo to the CIA, and they poured cold water on it immediately: "This has nothing to do with what we do."
Anyone else might have been discouraged, but Cohen came back with a crucial question: "Then what would you want it to do?" That question became the turning point of Palantir's fate.
The team quickly realized that the traditional model — where sales collect requirements and engineers then build — simply wouldn't work. Someone had to embed directly at the customer's site, explore together with them, and iterate while using. That was the prototype of the FDE model.
This model proved its worth on the battlefield quickly. In Iraq and Afghanistan, what US troops feared most was roadside bombs; the traditional approach relied on patrols or after-the-fact sweeps, which was dangerous and inefficient.
Palantir engineers embedded with the soldiers found that what they needed wasn't fancy intelligence dashboards, but just a small tool to mark "this road is suspicious" on a map. So the engineers threw together a simple map on the spot — soldiers could tap to flag risky road sections, others would immediately see the update, and they could avoid dangerous areas.
This seemingly crude "makeshift solution" immediately changed the soldiers' daily routine and reduced casualties — and it was eventually absorbed into Palantir's platform as a standard feature, used in scenarios from smuggling tracking to money flow analysis.
Later, Palantir's key figure Shyam Sankar simply turned this "necessary evil" into an official playbook: he named these on-site engineers Forward Deployed Engineers — they weren't just service executors, but more like "product pathfinders."
For a long time, this "counterintuitive" approach never caught on in Silicon Valley. The reason is simple: it requires a lot of manpower, margins are extremely low in the short term, and it's far less straightforward than SaaS.
But Palantir had no choice.
They found that every customer's needs had subtle but fatal differences — features built for customer A were completely useless for customer B. Either you became an outsourcing shop, or your product bloated into a monster, and in the end nobody was satisfied.
Shyam Sankar's (the company's CTO) solution was: since customization is unavoidable, turn customization itself into a weapon. What they built wasn't a rigid product, but a highly flexible platform.
FDEs lay down "gravel roads" in the field; the headquarters team picks out the most valuable parts, paves them into "highways," and builds them into the platform. Over time, the platform grows stronger and stronger, and there are fewer and fewer "dirt roads" at new customer sites, freeing FDEs to focus on deeper problems.
This is what makes Palantir fundamentally different from other tech companies.
By the standard Silicon Valley playbook, once a company finds PMF, it immediately creates distance from customers, standardizes the product, then hires salespeople aggressively and scales up, selling the same thing to all customers. That's fast — that's a "money printer."
But Palantir went the opposite way: even after finding PMF, they chose to keep doing the heavy, exhausting work. FDE engineers still embed at customer sites, solving customers' unique problems while bringing the most valuable parts back to build into the platform.
This is actually a brand-new business philosophy: scaling the unscalable. This approach — seemingly clunky, yet continuously accumulating advantages — gradually became Palantir's greatest moat.
02 How did the "old-school" FDE model suddenly catch fire?
Why is the FDE model hot again now? The reason is simple: the traditional SaaS logic of selling software completely breaks down in the AI era.
AI is an entirely new species with no established benchmarks. In payments there's PayPal, in CRM there's Salesforce — you can benchmark against them and do better. But AI agents have no unified definition yet; every customer is like wiring up electricity for the first time — even the plugs are different. A bank wants risk modeling, a logistics company wants route scheduling — they both sound like "using AI," but the implementations are completely different things.
What makes it worse is that customer needs vary enormously — no single "standard product" can win them all.
Take a real example: a company building an AI legal assistant found that when pitching big law firms, the lawyers cared most about whether contract clauses could be accurately flagged; but when the same product was offered to small and mid-sized firms, they cared more about "can it help me write first drafts." The same "AI lawyer," completely different scenarios.
This means the cost of product exploration is extremely high. You have no choice but to send people to the customer's site, use and iterate together with them, to truly understand the problem. That's exactly how Castle, a YC-backed company, got started: engineers camped out in a bank's customer service center, watching the mortgage process, and gradually tuned the AI voice assistant until it was actually usable.
Why is it worth being this "heavy"? Because AI contracts are often huge. Once you solve a customer's core pain point, the value multiplies.
Back in the day at the Department of Defense, Palantir built just a small tool letting soldiers mark suspicious roads on a map — yet it directly reduced the risk of stepping on landmines, and that kind of value is priceless. Today, many AI startups sign deals with big banks and major logistics companies worth tens of millions of dollars, easily enough to support the heavy upfront investment.
And so, the FDE has become the standard playbook for AI companies to land customers: first brute-force it with manpower to figure out the needs, then abstract the "makeshift solutions" into a platform, and finally make money through platformization.
When many people hear this, their first reaction is often: isn't this just consulting? Both involve sending people to the client's site to help solve their most urgent problems. But Bob McGrew points out that a truly healthy FDE practice and consulting are worlds apart.
The first dimension of difference is money.
Consulting firms are straightforward: one project, one fee. Ten projects require ten times the headcount, so costs and revenue are almost linear, and margins rarely see a qualitative leap.
The logic of an FDE software company is completely different: at the start, you send people on-site with heavy investment and low efficiency, often losing money. But as frontline experience keeps accumulating into the product, an inflection point arrives—the core product becomes more and more complete, deployments get lighter, and FDE investment shrinks.
At the same time, once you've solved the first pain point, you've won the client's trust, and contract values keep climbing. Eventually, the curves look like this: the cost line goes down, the value line goes up, and gross margin turns from negative to positive. That's what a healthy FDE company should look like.
The second dimension of difference is the product.
An FDE team is not a bunch of "outsourced dev shops" kept in the field. The real value lies in whether "discoveries from the frontline" can be absorbed and consolidated by the headquarters product team. If FDEs are just writing small tools for clients, they will inevitably sink into the customization quagmire.
Here, the product manager's role is especially critical. They can't simply stuff client requests into the product as-is, or the product will become increasingly bloated. They must have extremely strong abstraction skills—able to take one client's specific need, extract the underlying general problem, and design it into a feature that ten future clients could all use.
That's exactly how Palantir's ontology came about in the first place: instead of directly building an "anti-terrorism database" or a "funds database," it was abstracted into a general model of "objects + relationships," allowing flexible reuse across scenarios.
So how does an FDE team actually work?
03 Mastering the FDE Model: Two Types of People Are Key
To truly implement the FDE model, the best case study is Palantir.
Bob McGrew revealed that Palantir's internal FDE team has two key roles: Echo (embedded analysts) and Delta (deployment engineers).
People on the Echo team mostly come from the client's industry. They need to dive deep into the client organization, understand the users' jargon, figure out the real pain points, and also maintain the client relationship along the way.
The Delta team, on the other hand, consists of "deployment engineers" who rapidly write code, turning Echo's ideas into a working prototype solution.
It sounds like a clear division of labor, but the difficulty is that neither type of person is easy to find.
For Echo, you need people with a rebellious spirit—people from niche domains who truly know the industry inside out, yet deeply understand that the existing model doesn't work and crave change.
The Delta team consists of true geeks. They need to deliver a working prototype in the shortest possible time. Rough is fine; being usable is what matters most. Because they have to present a "visible result" in front of the client's executives.
One defines the problem, the other solves it. Put together, they're essentially a mini startup team: unfamiliar environment, limited resources, and a mandate to deliver results fast. That's why Palantir later became known as "Silicon Valley's entrepreneurial West Point," producing a large number of founders.
Of course, to make the FDE model work, there are three "rules of survival":
First, you must win over the client's CEO. Palantir only takes on projects addressing the top 5 issues the client's CEO cares about most—otherwise it would rather not do the project at all. Without executive backing, internal processes absolutely cannot be pushed forward.
Second, in the early stage, you must dare to lose money to build buzz. Big clients have been through too many failed projects; they trust neither themselves nor you. You have to earn their trust with offers like "money back if it doesn't work."
Third, beware of becoming an outsourcer. Clients will often give you small, "easy to report on" tasks, but they won't hand you the truly critical pain points. The FDE's mission is to find and solve the big problem that can change the client's fate. Only by solving the first core problem do you get the chance to penetrate deeper into more central systems.
That's the essence of FDE: scaling the things that supposedly shouldn't be scaled. It sounds clunky, but in a new market with no standard answers, it's precisely the most reliable path.
By Lin Bai
This article was written by [乌鸦智能说] (Crow Intelligence), a contributor to 人人都是产品经理 (Everyone Is a Product Manager), and originally published/authorized on 人人都是产品经理. Reproduction without permission is prohibited.
Cover image from Unsplash, under the CC0 license.
