The current AI field is witnessing a stark contradiction: on one hand, large model capabilities are advancing rapidly, with iterations of models like GPT and Gemini coming so fast that AGI seems within reach at tech conferences; on the other hand, toB AI implementation is struggling, with 95% of enterprise AI adoptions ending in failure (MIT 2025 report data). Companies purchase AI models but don't know how to integrate them into business processes, and the gap between capabilities and applications has become an industry pain point.
The FDE model, born at Palantir, has recently sparked renewed discussion through a series of interviews on Y Combinator's (YC) official podcast "Lightcone" — between May and September 2025, heavyweight guests including former OpenAI Chief Research Officer Bob McGrew and YC President Garry Tan deeply analyzed its logic, turning this "old method" into a "new solution" for AI implementation, increasingly seen by AI entrepreneurs as the key to breaking through.
FDE is more than just "on-site engineers"
FDE stands for Forward Deployed Engineer, but it is far from simply "engineers on-site." It is a complete toB service delivery system: deploying a cross-functional team of engineers, product managers, and analysts deeply embedded in the client's business site to continuously discover real pain points and iterate solutions.
Its core logic is clear: not selling standardized software, but delivering "capabilities and results." For example, when facing a manufacturing client's defect rate issue, an FDE team wouldn't just provide a generic data analysis tool. Instead, they would be stationed 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 implementation of new technologies, not to redefine requirements. As Bob McGrew emphasized on the YC podcast: "FDE is a 'product pathfinder,' not a 'business designer.' Pathfinding means finding a path that technology can take within the client's existing business landscape, not drawing a new map."
The FDE model was born from Palantir's "forced innovation" to serve special clients
Palantir's clients include sensitive institutions like the U.S. Army Research Laboratory. These clients have two core pain points: first, their needs are highly uncertain — no one can clearly define what features "counter-terrorism data analysis" requires; second, their operations are highly confidential, making it difficult even for the clients themselves to fully define their needs.
The traditional "sell product + training" model completely failed: giving intelligence agencies a standardized software package either wouldn't be used or wouldn't comply with confidentiality procedures. So Palantir simply had engineers move into client buildings, work alongside intelligence analysts, and adjust solutions in real-time — this was the prototype of FDE. Later, systematically designed by Palantir's current CTO Shyam Sankar, it formed a division of labor between "Echo teams (embedded analysts with industry backgrounds)" and "Delta teams (engineering experts who quickly write prototypes)," transforming from a "last resort" into a core competitive advantage.
From niche practice to industry focus
For a long time, the FDE model was seen as Palantir's "niche practice," until the 2025 YC podcast "Lightcone" series of interviews brought it into the industry spotlight.
Among them, Bob McGrew's (also an early Palantir executive) interpretation was the most influential: he revealed FDE's underlying logic of "doing unscalable things at scale," clarified its differences from consulting and outsourcing, and provided a "24-hour implementation Prompt-FDE action checklist." YC President Garry Tan proposed that "an FDE sitting next to a client writing prompts is the core asset of an AI startup," directly pointing to the blind spot of implementation beyond model parameters.
The 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: More than just a slight difference
Many people confuse FDE with outsourcing or customized SaaS, but the underlying logic of the three is fundamentally different:
| Comparison Dimension | Outsourcing Development | SaaS + Light Customization | FDE Model |
|---|---|---|---|
| Source of Requirements | Proposed by management | Proposed by management | Discovered on the front line (uncovered by FDE on-site) |
| Type of Requirements | Managerial needs (reports, approval processes) | Primarily managerial needs | Business needs (conversion rates, operational efficiency) |
| Deliverable | Functional modules completed per requirements | Standard product + minor customization | An on-site team + continuously iterated solution |
| Driving Method | Top-down (boss decides) | Top-down (adjusted per management requirements) | Bottom-up (front-line needs drive) |
| Organizational Resistance | Low (doesn't touch existing processes) | Low (only optimizes surface-level functions) | High (challenges old processes and power structures) |
| Core Logic | Execute requirements | Optimize product | Uncover real needs and implement technology |
Take a real example: a company wants "customer data analysis." An outsourcing team would build a reporting system based on management's requirements. A SaaS vendor would add a "customized reporting module" to their existing product. An FDE team, however, would be stationed in the sales department, observe how salespeople follow up with clients and how data is collected, and ultimately create a tool that directly helps salespeople improve conversion rates — it could be a "customer churn warning alert" or an "automated follow-up script generator." It solves the real pain points on the front line, not just the "paper requirements."
FDE's Advantage: Directly hitting the core pain points of toB AI implementation
Why has FDE become popular in the AI era? Because it precisely solves three major challenges of toB AI implementation, especially excelling in "need discovery" and "technology adaptation":
Finding "real needs," not "paper requirements" (re-discovering needs, not redefining them)
Many toB AI projects fail because the "requirements are wrong" — management thinks they need an "AI reporting system," but the front-line sales team actually needs an "AI customer follow-up assistant." The FDE team embeds itself on the front line, using "on-the-job observation + scenario decomposition" to uncover the true needs. For example, a bank proposed "AI-optimized credit approval." The FDE team found that approvers spent 80% of their time on "checking data consistency." The final solution was an "AI automatic data validation" tool, which neither deviated from the client's core goal of "optimizing approval" nor precisely matched the technology to the actual pain point.
As Bob McGrew said: "The client's business goals already exist. FDE just finds the point where technology can intervene, not creates new needs."
Rapid iteration, avoiding "loss in requirement transmission"
In the traditional model, requirements pass through multiple layers — "front line → middle management → senior management → vendor" — and are often distorted by the time they are implemented. The FDE team is on-site, so they can discuss and adjust solutions the same day a problem is discovered, delivering a Minimum Viable Product (MVP) 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 report generation" to "automatic report generation," improving efficiency by 10%. But FDE dares to challenge old processes: for instance, if they find salespeople spend 80% of their time entering customer data, they build a "voice auto-entry + AI classification" tool, reducing that time to zero and achieving a 10x efficiency boost. This change stems from a deep understanding of front-line processes, not just a simple technology overlay.
FDE is not a "cure-all"; be aware of these challenges
While the FDE model is good, it is not without barriers. Companies looking to implement FDE must first consider these four difficulties:
High cost: Large upfront investment, difficult short-term profitability
Deploying a cross-functional team on-site costs 3-5 times more than outsourcing. Moreover, the initial 6 months might be spent on "researching requirements" with no clear output, posing a significant test for financial reserves.
Bob McGrew also cautioned on 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 "custom tailoring"
The FDE model heavily relies on the "on-site team + understanding of the client's business," making it difficult to "sell one product to 100 clients" like SaaS. When serving the 10th client, a new on-site team might still need to be formed, resulting in weak scaling effects.
However, the industry is exploring solutions, such as consolidating high-frequency needs discovered by FDE into general functions, forming a "customization → standardization" loop.
High organizational resistance: Easy to "offend people"
FDE challenges old processes, like "eliminating manual approval steps and using AI for automatic review," which can threaten the interests of middle managers. "Requiring front-line employees to use new tools" can also trigger resistance.
If not handled well, the project can easily be derailed by "internal resistance."
Difficult to measure value: Results are not "immediate"
Outsourcing delivers "features," 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 are not 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 exactly
Many think FDE is Palantir's "unique skill" — after all, it serves sensitive U.S. government departments with special connections and resources.
But ordinary toB companies wanting to implement FDE cannot and should not copy this model entirely. If implementing the FDE model, pay attention to the following three points:
Entry point: Use "AI/digitalization" instead of "industry experts"
Palantir needs "retired officers, intelligence experts" as FDEs because their clients are too unique.
But ordinary companies don't need this. AI and digitalization are cross-industry general capabilities, like "data integration," "process automation," and "AI predictive analysis," 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 on the YC podcast.
Self-positioning: Be a "critical partner," not a "requirement executor"
The core of FDE is not "do whatever the client asks," but "help the client discover problems."
For example, if a client says "we need an AI report," the FDE team should ask: "Why do you need the report? What problem are you trying to solve with it? How do front-line employees currently use reports?" Use a third-party perspective to question and find the real need behind it — possessing the ability to "re-discover needs," rather than blindly executing or redefining them.
Pacing: "Quick pilot → validate value → gradual expansion"
Don't try to "serve the entire enterprise" from the start. First, select a small scenario to break through: for example, help 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 the customer service department, supply chain department, gradually penetrating.
FDE might be the current best 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 many features there are," but on "whether it can solve real problems and create real value for the client." It is also a return from "technological fantasy" to "practical implementation."
As Bob McGrew said on the YC podcast: "OpenAIs 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 may mean higher costs and greater resistance, but it also means deeper customer stickiness and a more difficult-to-replicate competitive advantage. After all, the core of toB business is always "trust," and every day an FDE team spends on-site is an accumulation of that trust.
At the same time, it's important to note that "AI implementation" is not a need in itself. AI is just a method and tool to achieve user needs and solve user pain points; one should not implement AI for the sake of AI.
Regardless of whether the FDE model exists, the bottleneck in implementing toB business has never been whether product managers or engineers understand the client's business, but whether they can convince the boss and management while successfully delivering on the front line.
Essentially, there are only two types of toB business: management needs and business needs. Product managers and engineers mostly focus on the former because management is the buyer, but the real user is the latter — front-line employees. Hence, a common phenomenon in the past was that the boss and management thought an application was great, but it didn't actually improve efficiency much.
For example, many bosses are willing to spend money on OA SaaS like "DingTalk" for clocking in and managing workflows, but its business form isn't much different from handwritten signatures. It merely saves the time of physically transferring documents.
As for document editing tools used by employees, most companies use the free version of WPS, and many don't even have a unified tool standard within the enterprise, let alone being willing to pay for Office for their 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." The client's willingness and determination are the key to toB AI implementation.