Currently, the AI field is witnessing a stark contradiction: on one hand, large model capabilities are advancing at a breakneck pace, with models like GPT and Gemini iterating so rapidly that it's hard to keep up, and technical presentations make AGI seem within reach; on the other hand, the implementation of AI in the B2B sector is struggling, with 95% of enterprise AI adoption projects ending in failure (according to MIT's 2025 report). Companies purchase AI models but don't know how to integrate them into their business processes, creating an industry pain point: the gap between capability and application.
The FDE model, born at Palantir, has recently gained renewed attention 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 remedy" for AI implementation. It is increasingly seen by AI entrepreneurs as a 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 B2B 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: not selling standardized software, but delivering "capability and results." For example, when facing a manufacturing client's defect rate issue, the 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 defect rate—this solution could be a software tool or process optimization suggestions, ultimately guided by "business outcomes."
It's worth noting that FDE's core mission is to drive the adoption of new technology, 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 fit 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 specify what functions "counter-terrorism data analysis" needs; second, highly confidential operations—even the clients themselves struggle to fully define their needs.
The traditional "sell product + training" model completely failed: giving intelligence agencies a standardized software package 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 to work side-by-side with intelligence analysts, adjusting 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 backgrounds) + Delta teams (engineering experts who quickly build prototypes)," 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 sitting next to clients writing prompts 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" positions on YC's job board surged, with over 100 YC-backed companies starting recruitment.
FDE vs. Outsourcing/SaaS: More Than Just a Few Differences
Many confuse FDE with outsourcing or customized SaaS, but the underlying logic of the three is vastly different:
| Comparison Dimension | Outsourcing Development | SaaS + Light Customization | FDE Model |
|---|---|---|---|
| Source of Requirements | Proposed by management | Proposed by management | Discovered at the business frontline (unearthed by embedded FDEs) |
| Type of Requirements | Managerial needs (reports, approval workflows) | Primarily managerial needs | Business needs (conversion rates, operational efficiency) |
| Deliverable | Functional modules completed per requirements | Standard product + minor customizations | An embedded team + continuously iterated solutions |
| Driving Force | Top-down (boss decides) | Top-down (adjusted per management requests) | Bottom-up (driven by frontline needs) |
| Organizational Resistance | Low (doesn't disrupt existing processes) | Low (only optimizes surface functions) | High (challenges old processes and power structures) |
| Core Logic | Execute requirements | Optimize product | Uncover real needs and implement technology |
A real-world example: A company wants "customer data analysis." An outsourcing 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 embed 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—such as a "customer churn warning alert" or "automated follow-up script generation." This solves the real pain points at the frontline, not just addresses "paper requirements."
Advantages of FDE: Hitting the Core Pain Points of B2B AI Implementation
Why is FDE gaining traction in the AI era? Because it precisely addresses three major challenges in B2B AI implementation, especially excelling in "requirement discovery" and "technology adaptation":
Finding "Real Needs," Not "Paper Requirements" (Re-discovering Needs, Not Redefining Them)
Many B2B 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 at the frontline, uncovering the truth behind requirements through "shadowing + scenario deconstruction." For instance, a bank requested "AI to optimize loan approval." The FDE team discovered that loan officers spent 80% of their time "verifying data consistency," ultimately implementing an "AI automatic data validation" solution. This didn't deviate from the client's core goal of "optimizing approval" but precisely adapted 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 can be discussed and adjusted the same day they are discovered, 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 often 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 might create a "voice auto-entry + AI categorization" tool, directly reducing that time to zero, achieving a 10x efficiency gain. This kind of change stems from a deep understanding of frontline workflows, not merely layering on technology.
FDE is Not a "Cure-all"; These Challenges Demand Caution
While the FDE model has advantages, it is not without barriers. Companies considering FDE must first consider these four difficulties:
High Cost: Significant Upfront Investment, Difficult Short-Term Profitability
Stationing a cross-functional team on-site incurs labor costs 3-5 times higher than outsourcing. Moreover, the first 6 months might be spent solely on "requirement discovery" with no clear output, posing a major 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."
Difficulty Scaling: Each Client Requires "Tailor-Made" Solutions
The FDE model heavily relies on "embedded teams + understanding of 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 embedded team, resulting in weak scaling effects.
However, the industry is exploring solutions, such as turning frequently discovered needs into common features, forming a "customization → standardization" loop.
High Organizational Resistance: Prone to "Stepping on Toes"
FDE challenges old processes, like "replacing manual approval with AI auto-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 derailed by "internal resistance."
Difficulty Measuring Value: Results Aren't "Immediate"
Outsourcing delivers "functionality," SaaS delivers "usage," 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.
B2B Companies Don't Need to Copy Palantir Exactly
Many think FDE is Palantir's "secret weapon"—after all, it serves sensitive U.S. government agencies with special connections and resources.
But ordinary B2B 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 specialized.
But ordinary companies don't. AI and digitalization are cross-industry universal capabilities, like "data integration," "process automation," "AI predictive analytics"—needed by almost all industries.
Using these capabilities as an entry point 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 the ability for "requirement re-discovery," not blindly execute or redefine needs.
Pace Management: "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 the organization.
FDE Might Be the Optimal Solution for Current B2B 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 "practical implementation."
As Bob McGrew said on the YC podcast: "The OpenAIs of the world are responsible for building the rocket, and 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 loyalty and harder-to-replicate competitiveness. After all, the core of B2B business is always "trust," and every day an FDE team is embedded on-site is a day spent building that trust.
It's also important to note that "AI implementation" is not the need 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 B2B implementation have never been about whether product managers or engineers understand the client's business, but about whether they can secure buy-in from bosses and management while delivering for frontline operations.
Fundamentally, there are only two types of B2B business needs: managerial needs and 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. This often led to a phenomenon in the past: bosses and management thought the application was great, but there was little actual efficiency gain.
For example, many bosses are willing to pay for 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 physically passing documents.
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 address is "client willingness." The client's willingness and determination are the key to B2B AI implementation.