Currently, the AI field is witnessing a stark contradiction: on one side, large model capabilities are advancing at a breakneck pace, with models like GPT and Gemini iterating so fast it's hard to keep up, and technical presentations make AGI seem within reach; on the other side, the implementation of toB AI is struggling, with 95% of enterprise AI adoption projects ending in failure (data from MIT 2025 report). Companies purchase AI models but don't know how to integrate them into business processes, and the chasm between capability and application has become an industry pain point.
The FDE model, born at Palantir, has recently sparked renewed discussion due to a series of interviews on Y Combinator's (YC) official podcast Lightcone—from May to September 2025, heavyweight guests like former OpenAI Chief Research Officer Bob McGrew and YC President Garry Tan deeply dissected its logic, turning this "old method" into a "new antidote" for AI implementation, now seen by more and more AI entrepreneurs as the key to breaking the deadlock.
FDE is More Than Just "On-site Engineers"
FDE, short for Forward Deployed Engineer, is far from simply "engineers stationed on-site." It is a complete toB service delivery system: deploying a cross-functional team of engineers, product managers, and analysts to deeply embed themselves at the client's business site, continuously discovering real pain points and iterating solutions.
Its core logic is clear: don't sell standardized software, but deliver "capability and results." For example, when facing a manufacturing client's defective product rate issue, an FDE team wouldn't just provide a generic data analysis tool. Instead, they would station themselves at the factory, understand the production process and data formats, and customize a solution that directly reduces the defective rate—this solution could be a software tool or process optimization advice, ultimately guided by "business outcomes."
It's worth noting that FDE's core mission is to drive new technology adoption, not to redefine requirements. As Bob McGrew emphasized on the YC podcast: "FDEs are 'product pathfinders,' not 'business designers.' Pathfinding is about finding where technology can go within the client's existing business landscape, not drawing a new map."
The Birth of the FDE Model Stemmed from Palantir's "Forced Innovation" in Serving Special Clients
Palantir's clients are sensitive agencies like the U.S. Army Research Laboratory. These clients have two core pain points: first, highly uncertain requirements—no one can clearly define what specific features "counter-terrorism data analysis" needs; second, highly confidential operations—even the clients themselves struggle to fully define the requirements.
The traditional "sell product + training" model completely failed: giving intelligence agencies a standardized software suite either meant it wouldn't be used or it wouldn't comply with security protocols. So, Palantir simply stationed engineers in the client's building, working side-by-side with intelligence analysts to adjust solutions in real-time—this was the prototype of FDE. Later, systematized by Palantir's current CTO Shyam Sankar, it evolved into a division of labor structure with "Echo teams (embedded analysts with industry background) + Delta teams (engineering experts who rapidly prototype)," transforming from a "last resort" into a core competency.
From Niche Practice to Industry Focus
For a long time, the FDE model was seen as Palantir's "niche practice," until the series of interviews on YC's Lightcone podcast in 2025 brought it into the industry spotlight.
Among them, Bob McGrew's (also a former Palantir executive) interpretation was the most influential: he revealed the underlying logic of FDE "doing unscalable things at scale," clarified its differences from consulting and outsourcing, and provided a "Prompt-FDE action checklist for 24-hour implementation"; YC President Garry Tan proposed that "FDEs writing prompts sitting next to clients are the core assets of AI startups," directly pointing to the implementation blind spots beyond model parameters.
Podcast data confirms its impact: after the interviews were released, the number of "Forward Deployed Engineer" job postings on YC's job board surged, with over 100 YC-backed companies starting recruitment.
FDE vs. Outsourcing/SaaS: The Differences Go Beyond a Little
Many confuse FDE with outsourcing or customized SaaS, but the underlying logic of the three is vastly different:
| Comparison Dimension | Outsourced Development | SaaS + Light Customization | FDE Model |
|---|---|---|---|
| Requirement Source | Proposed by management | Proposed by management | Discovered at the business frontline (FDEs stationed on-site dig them out) |
| Requirement Type | Managerial needs (reports, approval workflows) | Primarily managerial needs | Business needs (conversion rates, operational efficiency) |
| Deliverable | Functional modules completed per requirements | Standard product + minor customizations | A stationed team + continuously iterating solutions |
| Driving Method | Top-down (boss decides) | Top-down (adjusted per management requests) | Bottom-up (driven by frontline needs) |
| Organizational Resistance | Small (doesn't touch existing processes) | Small (only optimizes surface functions) | Large (challenges old processes and interest structures) |
| Core Logic | Execute requirements | Optimize product | Uncover real needs and implement technology |
A real example: A company wants "customer data analysis." An outsourced team would build a reporting system as requested by management; a SaaS vendor would add a "customized reporting module" to their existing product; while an FDE team would station themselves in the sales department, observe how salespeople follow up with customers and how data is collected, and ultimately create tools that directly help sales improve conversion rates—this could be a "customer churn warning alert" or "automated follow-up script generation," solving the real pain points of the frontline, not just staying at the "paper requirement" level.
Advantages of FDE: Hitting the Core Pain Points of toB AI Implementation
Why has FDE become popular in the AI era? Because it precisely addresses three major challenges in toB AI implementation, especially excelling in "requirement discovery" and "technology adaptation":
Finding "Real Needs," Not "Paper Requirements" (Requirement Rediscovery, Not Redefinition)
Many toB AI projects fail because "the requirements are wrong"—management thinks they need an "AI reporting system," but frontline salespeople actually need an "AI customer follow-up assistant." FDE teams embed themselves at the frontline, uncovering the truth behind requirements through "shadowing + scenario breakdown": for instance, a bank proposes "AI to optimize credit approval." The FDE team discovers that loan officers spend 80% of their time "verifying data consistency," ultimately implementing an "AI automated data validation" solution. This neither deviates from the client's core goal of "optimizing approval" nor precisely adapts the technology to the actual pain point.
As Bob McGrew said: "The client's business objectives already exist; FDEs just find the point where technology can intervene, not create new demands."
Rapid Iteration, Avoiding "Requirement Transmission Loss"
In traditional models, requirements pass through multiple layers: "frontline → middle management → senior management → vendor." By the time of implementation, they are often distorted. FDE teams are on-site; issues discovered can be discussed and adjusted the same day, with a Minimum Viable Product (MVP) ready in 2-4 weeks, significantly reducing trial-and-error costs.
Driving "10x Change," Not "10% Optimization"
Outsourcing and SaaS mostly focus on "incremental improvements," like changing "manual reporting" to "automated reporting," improving efficiency by 10%. But FDE dares to challenge old processes: for example, discovering that salespeople spend 80% of their time entering customer data, they create a "voice auto-entry + AI categorization" tool, directly reducing that time to zero, achieving a 10x efficiency boost. This kind of change stems from a deep understanding of frontline processes, not merely layering on technology.
FDE is Not a "Panacea"; These Challenges Demand Caution
While the FDE model is good, it's certainly not without barriers. Companies considering FDE must first think through these four difficulties:
High Cost: Large Upfront Investment, Difficult Short-Term Profitability
Stationing a cross-functional team on-site incurs manpower costs 3-5 times higher than outsourcing. Moreover, the first 6 months might be spent solely on "requirement research" with no clear output, posing a significant test for financial reserves.
Bob McGrew also cautioned in the YC program: "FDE is not a 'quick fix' for small teams; it requires sufficient funding to support the initial exploration phase."
Difficult to Scale: Each Client Requires "Tailor-Made" Solutions
The FDE model heavily relies on "stationed teams + understanding client business," making it hard to scale like SaaS where "one product sells to 100 clients." When serving the 10th client, you might still need to form a new stationed team, resulting in weak scaling effects.
However, the industry is exploring solutions, such as turning high-frequency needs discovered by FDEs into common features, forming a "customization → standardization" closed loop.
High Organizational Resistance: Prone to "Making Enemies"
FDE challenges old processes, like "replacing manual approval with AI automated review," which can threaten middle managers' interests; "requiring frontline staff to use new tools" might trigger resistance.
If not handled well, projects can easily be dragged down by "internal resistance."
Hard to Measure Value: Results Aren't "Immediate"
Outsourcing delivers "functionality," SaaS delivers "usage volume," while FDE delivers "business outcomes"—like "helping the client increase conversion rates by 15%."
But outcomes are influenced by various factors like market conditions and client cooperation. If expectations aren't met, it can easily lead to a crisis of trust.
Implementing FDE requires sharing risks with the client.
toB Companies Don't Need to Copy Palantir
Many think FDE is Palantir's "secret weapon"—after all, it serves sensitive U.S. government departments with special connections and resources.
But ordinary toB companies wanting to adopt FDE cannot and need not copy this model exactly. If implementing the FDE model, pay attention to the following three points:
Entry Point: Use "AI/Digitalization" Instead of "Industry Experts"
Palantir needed "retired military officers, intelligence experts" as FDEs because their clients were too special.
But ordinary companies don't. AI and digitalization are cross-industry general capabilities, like "data integration," "process automation," "AI predictive analysis," needed by almost all industries.
Using these capabilities as entry points is easier to implement than finding "industry experts." This is also the core logic of the "Prompt-FDE" methodology discussed in the YC podcast.
Self-Positioning: Be a "Critical Partner," Not a "Requirement Executor"
The core of FDE is not "doing whatever the client asks for," but "helping the client discover problems."
For example, if a client says "we want AI reports," the FDE team should ask: "Why do you need reports? What problem are you trying to solve with them? How do frontline employees currently use reports?" Use a third-party perspective to question and find the underlying real needs—possess "requirement rediscovery" capability, not blindly execute or redefine requirements.
Control the Pace: "Quick Pilot → Validate Value → Gradual Expansion"
Don't start by trying to "serve the entire enterprise." First, choose a small scenario to break through: for example, start by helping the client's sales department with an "AI customer follow-up tool," deliver results in 2-4 weeks, and use data to prove "it can increase conversion rates by 10%." After gaining trust, expand to customer service, supply chain departments, gradually permeating.
FDE Might Be the Current Optimal Solution for toB AI Implementation
The essence of FDE is a mindset shift from "selling products" to "selling value"—no longer competing on "how high the model parameters are" or "how comprehensive the features are," but competing on "whether you can help clients solve real problems and create real value"; it's also a return from "technological fantasy" to "implementation practice."
As Bob McGrew said on the YC podcast: "The OpenAIs of the world are responsible for building the rocket, while FDEs are responsible for teaching ordinary people how to fly it—the latter is what determines the rocket's value."
For AI entrepreneurs, the FDE model might mean higher costs and greater resistance, but it also means deeper customer stickiness and harder-to-replicate competitiveness. After all, the core of toB business is always "trust," and every day an FDE team is stationed on-site is a day of accumulating trust.
Also note that "AI implementation" is not a requirement in itself. AI is merely a method and tool to achieve user needs and solve user pain points. Don't pursue AI for AI's sake.
Regardless of the FDE model, the bottlenecks in toB business implementation have never been whether product managers or engineers understand the client's business, but whether they can secure buy-in from the boss and management while delivering results for frontline operations.
Essentially, toB business has only two types: one is management needs, and the other is business needs. Product managers and engineers mostly focus on the former because management are the buyers, but the real users are the latter—frontline employees. Hence, a common phenomenon in the past: bosses and management think the application is great, but there's little actual efficiency improvement.
For example, many bosses are willing to spend money on OA SaaS like "DingTalk," which seems convenient for clocking in and managing workflows, but its business form isn't much different from handwritten signatures. It only saves the time of manually passing documents around.
As for document editing tools used by employees, most companies basically use free WPS, and the vast majority of companies don't even have a unified tool standard internally, let alone spend money on Office for employees.
Therefore, before implementing the FDE model and having "engineers understand the client's business," the first issue to solve is the "client's willingness" problem. The client's willingness and determination are the key to toB AI implementation.