Forward deployed engineer (FDE)

A forward deployed engineer (FDE) is the person a vendor sends to finish the product in your building. The title came from Palantir, the AI labs revived it, and Gartner wrote a guide to it in March 2026. This page explains the role, where it came from, how it differs from the jobs next to it, and why the demand now comes from post-sales teams. The argument about what it means for buyers is in Forward deployed engineers are a symptom, not a cure.

Where the role came from

Palantir built the role in its first decade. Its early customers were intelligence agencies whose problems could not be written into a requirements document, so the company put engineers on site to find the problem and build the tool there. Internally they were called Deltas, as distinct from the Devs who built the product; Palantir’s own description of the split is that a Dev builds one capability for many customers and a Delta builds many capabilities for one. Until 2016, according to The New Stack, the company had more Deltas than software engineers. The part that gets copied least is the loop behind it: what a Delta hand-built for one customer was studied by the product teams, and the patterns that recurred became product for everyone.

The AI labs revived the title when their models met enterprise workflows. OpenAI set up a forward deployed engineering team in 2024, and Anthropic followed with an applied AI group. The New Stack put the rise in job postings for the role at more than 800 percent between January and September 2025. Gartner’s guide calls the rise of the model a sign of AI platform immaturity, which is the kindest accurate description.

What the job looks like day to day

An FDE sits inside the customer’s technical team for the length of a deployment. The first weeks go on finding the workflow nobody documented: which system holds the record that matters, who actually approves what, where the exceptions go. Then the wiring: connectors to the systems of record, the data plumbing the demo skipped, the list of what the agent must refuse, the sessions with security and compliance. Then staying until the numbers hold and the customer’s own people can run it. One FDE told The New Stack that the model is usually the cleanest part of the job; the hard part is the workflow nobody wrote down.

That list is the four tests in Agentic in Production: a refusal list, a named approver for anything irreversible, a trace of every run and a budget per step. None of them lives in the model, which is why a platform cannot ship an agent on its own, and why someone has to be sent.

How it differs from the roles next to it

Role	When they appear	What they are measured on	Who keeps what they build
Solutions engineer	Before the sale	The deal closing	Nobody; the demo is thrown away
Customer success manager	After the sale	Adoption and renewal	Nothing is built; they train and escalate
Professional services or a system integrator	After the sale	Hours or milestones	You, on paper, if the contract says so
Forward deployed engineer	After the sale	The outcome, and adoption of the vendor’s platform	Usually the vendor, unless you negotiate it
Internal FDE, on your payroll	Whenever you hire one	Whatever you measure them on	You

The forward deployed engineer is the only vendor-side role in that table that writes production code after the contract is signed and is paid for the result rather than the hours. That is the whole difference. It is why the role is valuable, and why it is risky: the person who understands what was built is on the vendor’s payroll.

Why post-sales teams are hiring them

Customer success was built for software that is finished when it is sold. Its job is to get people to use a product that already works: onboarding, training, the quarterly review, the renewal. An agent is not finished when it is sold. It becomes finished in your environment, against your systems, under your rules, and until that work is done there is nothing for a customer success manager to drive adoption of. So vendors put engineers into post-sales and gave them the title, reporting them into customer success or, at the labs, an applied AI group. The reporting line is the tell: the vendor has learned that the product does not reach Monday morning by itself.

If you run post-sales at a vendor and are hiring forward deployed engineers, you are paying to close a gap the product should close. Palantir’s loop is the only version that pays back: what they build for one customer has to become product for the next, or you have started a services firm by accident. If you are the customer, an FDE in the vendor’s post-sales team tells you the product is not done for your environment, and that the person finishing it is paid by someone else. I see this from both sides. Ailoitte sells delivery and, with Leverge, a platform, so part of this argument is against my own business.

What to ask before you say yes

Say yes to the engineer and no to the geometry. Ask for the outcome as a written evaluation set, a refusal list and a budget, priced before the work starts. Ask who owns every artefact, and expect the answer to be you. Put one of your own engineers next to theirs as the owner of the refusal list, not an observer. And ask for the date and the condition on which the engineer leaves; if there is no answer, the engagement has no end. The vendor evaluation playbook has the full list of questions, and AI Velocity Pods are what those conditions look like when a delivery model starts from them.

Sources

Palantir, A Day in the Life of a Palantir Forward Deployed Software Engineer, 2020, for the Delta and Dev split. The New Stack, Why OpenAI and Anthropic are hiring forward deployed engineer teams, May 2026, for the ratio of Deltas to software engineers, the OpenAI and Anthropic teams and the growth in job postings. Chandrasekaran, A. and Thanaraj, R., An AI Leader’s Guide to Forward Deployed Engineering to Scale AI, Gartner, March 2026, paraphrased; the report itself is available to Gartner clients.