Forward deployed engineer (FDE)

What is a forward deployed engineer?

A forward deployed engineer (FDE) is a software engineer on the payroll of a software or AI vendor who works inside your company for a few months, on your systems and your data, to turn a vague ambition into something that runs in production. Then they hand it over and move to the next customer. The engineer belongs to the vendor. The problem, the data and the result belong to you.

Palantir built its business on the role. From the early 2010s it sent its own engineers, internally nicknamed Deltas, to sit with customers and build working software on Palantir's platform, and for years it employed more of them than ordinary product developers. The idea stayed a Palantir curiosity until AI products hit the same wall Palantir had hit: the software works in a demo, and then it meets a real company's order system, its half-documented processes and its Excel files.

In 2025 the role spread fast. The investment firm a16z called it the hottest job in startups in June 2025, the Financial Times counted a rise of more than 800 percent in monthly FDE job listings between January and September 2025, and OpenAI, Anthropic, Salesforce and a long list of AI startups now hire under that title. In 2026 the model went a step further: OpenAI launched a separate deployment company built around FDEs in May, Anthropic set up a comparable venture with investment partners the same month, AWS announced its own forward deployed engineering unit in June, and the AI Engineer World's Fair in San Francisco gave forward deployed engineering its own conference track.

What an FDE does day to day

The job descriptions from OpenAI and Anthropic read alike. OpenAI's posting has its FDEs own discovery, scoping, system design, build and production rollout, judged on adoption and on eval-driven feedback that changes the product roadmap. Anthropic's posting has them build production applications inside customer systems, deliver pieces like MCP servers and sub-agents, and codify repeatable deployment patterns for the product team. A deployment runs through the same stages.

• Discovery. The engineer sits with the people who do the work, not with the steering committee. What does a planner actually do when an order is late? Where does the information live? OpenAI's deployment company describes a first phase as a focused diagnostic followed by a small number of priority workflows chosen with the customer's leadership.

• Data plumbing. Most of the calendar goes here: read access to the ERP, an export from the ticketing tool, a way to look up a customer without copying the whole database. The AI part rarely fails; the connection to your data does.

• Evals and prompt work. Before anything is built, the engineer collects examples of good outcomes from your experts and turns them into a test set. Every prompt and configuration change is then scored against that set instead of against someone's gut feeling.

• Integration. The result has to land where people already work: a button in the CRM, a draft in the mailbox, a line in the order system. Anthropic's description of an engagement is engineers sitting with clinicians and IT staff to build tools that fit the workflows those staff already use.

• Change management and handover. Training the team, watching the first weeks of real use, and documenting what was built. Cursor's forward deployed team put the goal plainly at the 2026 World's Fair: when the vendor walks away, the customer should not turn things off.

Forward deployed engineer versus an implementation partner

An implementation partner or an external team billed by the hour can do most of the same tasks. The difference is who learns from the deployment.

Who learns

When an FDE spends three months in your warehouse, the vendor learns. The workaround for your ERP becomes a connector in the product. The prompt that finally handled Belgian VAT numbers becomes a default. The vendor's roadmap changes because of what the engineer saw at your site, which is exactly why the vendor is willing to pay for it. OpenAI's posting counts that feedback as a success measure, and Anthropic asks its FDEs to bring deployment patterns back to the product team.

When an external team does the same work, that team learns. The reusable pieces end up in their toolkit and get sold to the next client. The vendor's product does not change.

In both cases the party that learns least by default is you, unless you insist on it. That is the single most useful thing to know before signing.

Who pays whom

An external team invoices you for hours. An FDE is usually priced into the deal: part of the licence, part of a paid pilot, or a services line that the vendor sells at or near cost. a16z's advice to startups is explicit on that point: sell the services at cost and judge the team on retention, because the software subscription is where the margin comes back. The cost does not disappear, it moves into the contract.

What it costs and how it is billed

Three billing shapes cover most of the market.

1. Bundled in the enterprise deal. The frontier labs reserve their FDEs for large accounts. According to press reports in 2025, OpenAI's custom deployments started around ten million dollars, which puts them out of reach for a Belgian SME. The new deployment ventures from OpenAI and Anthropic aim at mid-sized companies, but the price point is not public.

2. Paid pilot. An AI startup charges a fixed fee for an eight to twelve week pilot with one or two of its engineers on your problem, often credited against the first year's licence if you continue. This is where an SME is most likely to meet an FDE.

3. Per engineer-month. A day rate or monthly fee for a named engineer, closer to classic services. Some vendors, and partner programmes like the one AWS launched in 2026, run their FDE work through partners who bill this way.

Whatever the shape, ask for the total over three years, not the pilot price. The pilot is the cheap part.

A worked example

A distributor with 60 staff buys an AI agent from a young vendor to answer order-status mails. The vendor includes one FDE for ten weeks in a paid pilot.

Week one the engineer shadows the two people who answer those mails and pulls 300 past mails with their replies. Weeks two and three go into a read-only link to the order system and a small service that finds an order by customer and reference. Week four the engineer and the two colleagues mark 150 of the old mails with the right answer; that becomes the eval set. Weeks five to eight are prompt and configuration work, each version scored against the 150 cases until the agent gets nine out of ten right and flags the rest for a human. Weeks nine and ten the agent drafts replies that a person approves, and the engineer writes down what was built and why.

The vendor comes out with a tested order-system connector and a better default prompt. The distributor comes out with a working agent, an eval set and two colleagues who understand it. If that last part is missing, the pilot did not succeed, however good the demo looked.

What to watch out for with an FDE engagement

The knowledge leaves with the engineer. An FDE knows your setup better than anyone in your company after ten weeks. When they rotate to the next customer, that knowledge goes with them unless it was written down and taught. A critique published in 2026 by a defence software firm frames it sharply: a growing FDE headcount signals a product that never matured and a customer locked into permanent dependency on vendor staff. The amount of vendor support you need should fall month by month.

Dependence on one vendor's people. Configuration, prompts and connectors built by the vendor's engineer tend to live in the vendor's tooling. If the relationship ends, what stays behind on your side?

Scope creep. An engineer on site who is good at their job will find five more problems worth solving. Each one may be worth doing, but each one also grows the contract. Keep a written scope for the pilot and a separate list for later.

The roadmap bias. The FDE is measured on adoption of their product. When the honest answer is "this part is better done with a simple rule in your ERP", you may not hear it. Someone on your side needs enough technical judgement to ask.

What to ask for before you sign

1. A named internal owner from day one. One person from your company who sits in every session and can explain the system when the engineer is gone. Without this, the rest of the list will not happen.

2. The eval set as a deliverable. The test cases your experts labelled are your company's knowledge. They should be yours, in a format you can run yourself, and they are the thing you will need when you switch models or vendors.

3. Prompts, configs and connectors in your own repository. Not a screenshot, not access to the vendor's console: the actual files, under your version control.

4. Handover documentation and a support tail. A written description of what was built, how to change a common thing, and who answers questions in the three months after the engineer leaves.

5. A declining support curve in the contract. Agree up front what "you can run this without us" looks like and when you expect to reach it. If the vendor cannot describe that moment, the engagement has no end.