The FDE Advantage: Turning Deployment into Compounding Value

Is FDE a bridge, or a permanent restructuring of GTM?

The surge in FDEs sends competing signals: a permanent restructuring of enterprise GTM, or a temporary bridge while AI matures enough to solve enterprise problems without customized support.

Our take: FDEs signal a permanent restructuring of enterprise GTM, driving revenue, adoption, and product feedback loops.

As frontier model quality converges, companies increasingly have access to the same underlying capabilities, shifting competitive differentiation toward how deeply a vendor embeds inside customer workflows to solve complex problems and drive measurable outcomes. FDEs can be a primary lever for building that differentiation, particularly when deployments demand a total overhaul of customer workflows rather than a point solution. 

Generally, in those cases, FDEs become the linchpins for delivering results. Some argue the role is temporary: as AI writes more of the code, the need for FDEs will fade. But one of the hardest parts of an enterprise AI deployment is defining the problem and earning customer trust, not writing the code. FDEs work through that ambiguity, define the problem directly working with customers, and design deployments that can succeed over time.

Companies are scaling the model because it pays for itself twice. 38% run FDEs as a revenue engine, materially contributing to expansion, retention, and strategic account outcomes. 24% run them as a product intelligence engine, where field customization feeds directly back into the core roadmap. Some of the most effective companies do both, generating near-term revenue while converting field insight into long-term product leverage. That dual return is what makes the model lasting.

‍

‍

Our 2026 State of AI Report shows half of the surveyed companies plan to scale their FDE model as a permanent part of their GTM motion, and AI builder respondents expect integration to reach 34% of enterprise customers by 2027. The trajectory points to a larger but still selective role, concentrated in complex, high-value deployments rather than broad account coverage.

That commitment is also visible in the broader market, and the labs and hyperscalers are also placing their bets. Microsoft committed $2.5B and 6,000 employees to Microsoft Frontier Company, embedding FDEs and industry-specialist sellers directly inside enterprise customers, and AWS put $1B behind its own unit days earlier. The AI labs moved faster and further. OpenAI raised over $4B for its Deployment Company in May, and Anthropic took a different approach by launching Ode with Anthropic, a standalone company backed by a consortium of leading investors. These investments reinforce that embedded deployment is becoming a lasting part of enterprise AI, even as the right operating model remains unsettled.

The scale of these commitments makes the execution question more urgent to avoid technical debt. On extensible platforms, customer-facing engineers build reusable product improvements that strengthen the core roadmap. On traditional architectures, the role drifts into a high-maintenance services function, layering bespoke work on top of the product; that work becomes increasingly expensive and reduces the amount of reusable code that can flow back into the core roadmap. 

The footprint must also evolve as the product matures, with FDEs focused on customer profiles with repeatable needs. ElevenLabs, for example, deliberately pulls FDEs back once a problem class can be solved out of the box, on the logic that today’s FDE work should eventually dissolve back into product as tooling matures. 

As FDE adoption expands, we expect the companies that outperform will be those that scale customer impact without allowing bespoke work to accumulate. That outcome depends on disciplined choices about where FDEs are deployed and how the function is structured, staffed, and measured.

How AI companies structure, staff, and measure FDE teams

No consensus operating model has emerged, largely because what an FDE does depends heavily on the company, product, and customer. In a fast-moving market, the best models stay agile and customer-first, guided by five principles.

1. Reporting lines: decide by competency, not title. The emerging rule is that people making actual code changes sit in R&D, while scoping, configuration, and change management often live in GTM. Ramp houses FDEs in engineering because most of the work now feeds the core roadmap. Anthropic places the function in GTM because the job is as much about helping customers get the most from their use of Claude as it is writing code.

2. Timing: FDE orgs are built on mature products. Operators describe a clear sequence: documentation handles early questions, solution engineering comes next, and FDEs become essential only once a company sells outcomes that require enterprise transformation. For a ten-engineer startup with a handful of enterprise deals, operators say everyone should be an “FDE.” The moment to formalize the role is when customer requests become a distraction for some engineers and traction for others.

3. Team composition: the role is specializing into sub-functions. At scale, the team splits into customer-facing generalists, builders, and technical implementers. ElevenLabs, which grew its FDE function from 12 to 60+ people in under a year, runs three roles: forward deployed software engineers, deployment strategists, and solution engineers. Anthropic built an Applied AI team, which includes customer-facing AI researchers, engineers, and product experts who move across accounts shaping agent architectures while dedicated FDEs go deep on one customer. Some companies, including Anthropic, fully embed with customers rather than optimize for short-term bookings, which preserves trust and technical depth in engagements.

4. Embracing AI: what we view as leading teams are building “FDE factories.” To optimize workflows, FDEs use agentic pipelines to turn inbound requests into a first-pass response, spec, and agent handoff. From there, the role splits in two: one path toward AI engineering and orchestration, the other toward customer judgment, problem definition, and change management. 

5. Measuring success: ROI follows the org. Revenue retention remains the north star, alongside win rates on FDE-supported deals and downstream product impact such as features that originated from customer deployments. Teams that place FDEs in the GTM org tend to treat them as part of the cost of sale and evaluate margin, deal cycle time, and overall sales efficiency. 

Beyond these five principles, attribution and capacity remain unresolved. Companies often cannot isolate how much of a deal was driven by FDE work, even though each additional deployment often requires more headcount. Without that visibility, teams risk either constraining growth through underinvestment or diluting margins through overstaffing. This attribution challenge also shapes how companies monetize the function.

How AI companies price and charge for FDEs

Monetization of the FDE model is fragmented. 30% of companies bundle FDEs into the software subscription cost, 29% charge a separate professional services fee, and 25% run a hybrid. That fragmentation is a reflection of the attribution challenge: without a clear way to price the value FDEs create, companies default to charging for access, time, or capacity rather than outcomes.