Forward Deployed Engineers: What They Do, What They Cost, and Why You Keep Losing Them

Job postings for Forward Deployed Engineers have exploded. According to industry reporting based on Indeed data, FDE postings rose 729% in a year, from 643 in April 2025 to 5,330 in April 2026.

In May 2026, OpenAI launched the OpenAI Deployment Company, acquiring Tomoro and bringing roughly 150 Forward Deployed Engineers and Deployment Specialists into the business from day one. Within the same month, Anthropic announced a new enterprise AI services company with Blackstone, Hellman & Friedman and Goldman Sachs, with applied AI engineers working alongside customers to build and deploy Claude-based systems.

A role that was once treated as Palantir-specific operating jargon has become one of the defining enterprise AI roles of 2026.

It is also one of the most mispriced. Startups are copying the model without understanding the compensation, incentives or reporting lines that make it work. VCs are underwriting FDE-heavy go-to-market plans with SaaS-era engineering budgets. And frontier labs, which understand the role best, are quietly resetting the market for everyone else.

This piece explains what the role actually is, what it pays across the US and Europe, what founding engineers in frontier AI should expect, and who should lead the function once you build one.

A Forward Deployed Engineer is a production engineer who embeds inside the customer's environment and ships working systems after the deal is signed.

Not demos.
Not architecture diagrams.
Not recommendations.

Code that runs in the customer's production stack, against their data, inside their security perimeter.

Palantir built the role because government and enterprise customers did not need more features. They needed engineers who could make the features work inside fragmented data systems, complex workflows and decade-old infrastructure. That distinction still matters, because it is where most hiring processes go wrong.

A solutions engineer sells the dream during the process and usually hands over at signature. A consultant writes the recommendation and leaves. An FDE arrives after signature, lives in the account for weeks or months, ships the integration, and feeds what they learn back into the core product.

The role writes code in two places: the customer's environment and the company's product. That second half is what separates a product company running FDEs from a consulting shop with better branding.

The profile is genuinely three-way: production engineering credibility, client-facing judgement, and tolerance for ambiguity. In the LLM era, a fourth layer has been added on top: agentic orchestration, evaluation frameworks and the discipline of making probabilistic systems behave inside deterministic enterprises.

Because the bottleneck in enterprise AI moved from models to deployment, and the deployment failure rate became impossible to ignore.

MIT NANDA's State of AI in Business 2025 report found that only a small minority of integrated GenAI pilots were extracting meaningful value, while the vast majority showed no measurable P&L impact. The models worked. The deployments did not.

Systems could not talk to legacy SQL databases. They could not handle the customer's authentication stack. They could not meet data residency requirements. They could not be maintained by the teams who inherited them. Every enterprise has seen the demo. Far fewer have the internal capability to turn the demo into a governed production system.

The FDE is the market's answer.

Palantir's Q1 2026 investor release reported 85% year-on-year revenue growth, 104% US revenue growth, and full-year US commercial revenue guidance of at least 120% growth. That is the clearest available public evidence that the embedded model can work at scale.

The signal was not lost on the labs. When OpenAI and Anthropic both institutionalised forward deployment in May 2026, the role stopped being a Palantir curiosity and became part of the default operating model for enterprise AI.

For founders, the trigger point is usually consistent. You need your first FDE when the third customer asks for the same integration the founder has now built twice. You need the function before enterprise pilots start dying between the wow demo and production.

More than a product engineer at the same level, in every major market.

The premium is structural. You are paying for one person who can ship production code and manage a high-stakes enterprise relationship, and the intersection of those two populations is small.

There are two different compensation conversations in this market: cash compensation and total compensation.

Cash compensation is what most companies can compare cleanly: base salary plus bonus. Total compensation is where the frontier-lab market pulls away, because equity can represent the majority of the package. Public compensation benchmarks and market conversations suggest that senior and staff-level FDE-equivalent roles at frontier labs can move far above conventional engineering bands once equity is included, with the largest packages concentrated at OpenAI, Anthropic and similar AI-native employers.

Below is our current market view from live mandate work, observed offers and market conversations across the US and Europe. These are indicative total cash figures, base plus bonus, for individual contributors. Equity is treated separately because stage, company quality, valuation and liquidity profile distort the comparison.

Three notes matter when reading the table.

First, frontier labs sit at or above the top of every cash band and increasingly benchmark senior FDEs against research engineers rather than product engineers. Once equity is included, the strongest US lab packages can move materially above the figures shown here.

Second, the European discount to the US is real but narrowing at the senior end. The candidate pool is global, and the strongest European FDEs increasingly receive US-anchored offers.

Third, Dublin and continental Europe require careful interpretation. The upper end of those ranges is not the normal domestic engineering market. It usually reflects US-funded AI companies, globally benchmarked candidates, or roles with unusually high customer, product and revenue ownership.

Palantir remains the reference employer and the largest single source of talent, which means Palantir's retention economics effectively set the floor for everyone recruiting from it.

The reason market numbers appear inconsistent is that many public compensation discussions mix base salary, total cash and total compensation. That distinction matters in FDE hiring.

This is why sophisticated FDE candidates do not ask only, "What is the number?" They ask, "What is cash, what is equity, what is liquid, and what has to be believed for the offer to be worth what the company says it is?"

You usually lose FDEs for one of four reasons.

First, the compensation structure tells them you think they are a solutions engineer. Second, the reporting line tells them they will be used as pre-sales labour. Third, the product organisation has no mechanism to absorb what they learn in the field. Fourth, the equity story is not credible enough to offset frontier-lab opportunity cost.

The best FDE candidates do not just compare numbers. They read the operating model.

If the role reports to sales, carries a commission-style plan, and has no route into product or engineering leadership, the candidate understands the assignment: custom deployment work with a hotter title. That is not enough to pull someone out of Palantir, OpenAI, Anthropic, Databricks or a serious AI-native startup.

This is why FDE hiring fails even when the headline package looks competitive. The problem is rarely just money. It is what the money reveals.

A company that pays FDEs like sales engineers is telling candidates the role exists to move deals through the quarter. A company that pays them like standard product engineers is telling candidates it has not understood the commercial load. A company that cannot explain how field learning becomes product roadmap is telling candidates they will spend their time building one-off custom work that never compounds.

Strong candidates notice. The best ones walk away early.

The honest answer is that founding engineers are underpaid in cash and paid in ownership. The negotiation that matters is usually about equity, not base salary.

A founding engineer, meaning one of the first one to five technical hires who carries platform-level responsibility before the company can afford specialists, should think in three components: base, equity percentage, and the terms that determine what the equity is actually worth.

The frontier AI market has reset this conversation in two ways.

First, the opportunity-cost benchmark is no longer a FAANG package. It is a frontier-lab package. Labs are paying senior engineers cash and equity that startup ownership has to beat on expected value, not sentiment. A founding engineer leaving a lab is giving up a highly valuable four-year package and knows it.

Second, secondaries have become part of the founding conversation. Candidates who have watched lab employees access liquidity now ask when they will. Startups that treat the question as impertinent lose finalists to those that answer it.

The terms matter as much as the percentage. Early exercise, a long post-termination exercise window, the strike price relative to the last round, acceleration on change of control, and refresh expectations all change the real value of the offer.

Ten-year exercise windows are now a credible ask from sophisticated candidates. Ninety days is a red flag.

A founding engineer who negotiates 1.5% with a ninety-day window may have agreed to golden handcuffs. One who negotiates 0.9% with early exercise and a ten-year window may hold the better position.

Pay for productisation, not deployment hours, because the incentive design decides which company you become.

The recurring failure mode is wiring FDEs into go-to-market with commission-style variable pay tied to deal outcomes. It feels commercially rigorous and quietly converts the function into a services business. Every incentive points toward billable customisation. None points toward feeding reusable capability back into the product.

The structures that work share three features.

One warning on titles: rebadging solutions engineers as FDEs to ride the market rate lasts exactly one interview process.

Candidates from Palantir, the labs and serious AI-native companies ask what you shipped into production in the last two quarters. The answer exposes the rebrand. Title inflation in this market does not raise the perceived level of the role. It lowers the perceived seriousness of the company.

The leadership hire decides whether FDE becomes a product accelerator or a margin problem. It is the least understood seat in the function.

The function is so new that almost nobody has run it twice. The genuine bench is small: Palantir delivery leaders, the first generation of FDE managers at the labs, and a handful of operators who built embedded engineering functions inside enterprise AI companies before the title existed.

Everyone else is a translation risk.

Consulting leaders build utilisation machines. Sales engineering leaders build demo teams. Professional services leaders build margin-managed delivery organisations that starve the product of feedback.

The reporting line is the other half of the decision. The evidence from companies running the model well points one way: FDE leadership reports into product or engineering, with a hard commercial interface, not into sales.

The moment the function reports to the CRO, its roadmap becomes this quarter's pipeline.

An FDE is a revenue role wearing an engineering badge. Price it like either one alone and you will lose the person who is both.

The same is true of the leader, doubled.

Test for judgement in ambiguity, because it is the one component of the profile that cannot be taught and the one most often missing.

The engineering half of the assessment is straightforward: production evidence, integration complexity actually navigated, systems that survived contact with someone else's infrastructure. You want references from both the technical and commercial side of past deployments, because the candidates who impress engineers and terrify account teams, or the reverse, are exactly the ones this role breaks.

The harder half is the open-ended problem.

The now-standard FDE interview drops the candidate into a large, ambiguous, real-world scenario with messy data and competing constraints, then watches how they decompose it. What it reveals is not the answer but the ordering: whether the candidate scopes before building, asks about constraints before proposing architecture, and treats the client's stated problem as a hypothesis rather than a specification.

The volunteers are often wrong for the role. Strong product engineers who want variety but resent client friction self-nominate enthusiastically. So do strong communicators whose production credentials are a demo reel.

The person you want is usually harder to extract. They are busy being indispensable inside someone's biggest deployment.

That is an assessment problem before it is a sourcing problem. It is the reason FDE hiring resists the standard recruiting process. The pool is small, the profile is three-way, the failure modes are expensive, and the strongest candidates are not applying to anything.

The Forward Deployed Engineer is not a solutions engineer with a better title, and not a consultant who can code. It is a production engineering role with direct revenue consequence.

That is why the market keeps mispricing it.

Pay for engineering alone and you lose the commercial judgement. Pay for deployment alone and you build a services organisation. Put the function under sales and the roadmap becomes this quarter's pipeline. Put it too far from the customer and you lose the only feedback loop that makes the model compound.

The companies that win FDE talent in 2026 will not simply pay more. They will understand what they are buying: production engineers who can turn enterprise AI from a demo into a governed operating system.