Forward Deployed Engineer: The Role, the Skills and a 2026 Roadmap, Ansh Gupta

Two years ago, if you said "forward deployed engineer" to most developers, you got a blank look or a joke about Palantir. In 2026, OpenAI, Anthropic, AWS, Microsoft and Google Cloud all have teams built around the title, and it is one of the most searched job titles in AI.

Most of what gets written about it is either a recruiter's pitch or a salary table. I want to do something more useful: describe what the job actually is, using the job posts themselves as the source, say plainly who it suits and who it does not, and lay out a roadmap that someone with a normal software background could follow.

A disclosure first. I have not held the FDE title. I spent a year and a half at an agency building sites and storefronts for international clients, which is the older, less glamorous cousin of this job, and I now build a SaaS product end to end. That is the lens. Where I am relying on published sources rather than my own experience, I will say so, and they are linked at the end.

What the role actually is

A forward deployed engineer is a software engineer who works inside the customer's world instead of behind the product. You sit with the customer's team, learn their systems and constraints, and build the thing that makes the product actually work for them, in production, on their infrastructure.

The title comes from Palantir, which was using it by 2009. It borrows "forward deployed" from military language: the people stationed close to where the work happens, rather than back at headquarters.

The reason AI labs revived it is simple once you see it. A frontier model is extraordinarily capable in the abstract and completely inert inside a bank until someone connects it to the bank's data, permissions, workflows and compliance rules. That connecting work is not a sales task and it is not a research task. It is engineering, done on site, under ambiguity, with a customer watching. The model companies worked out that the bottleneck to revenue was not model quality. It was deployment.

What the job posts ask for

Here is the useful part, because job descriptions are the most honest document a company publishes about a role.

Anthropic's Forward Deployed Engineer posting lists the work as building production applications with Claude inside customer systems, and delivering technical artifacts like MCP servers, sub-agents and agent skills. It also asks FDEs to identify repeatable deployment patterns and feed them back to product and engineering. Travel is roughly 25% to customer sites. The listed salary range is $280,000 to $320,000 for New York, San Francisco and Seattle.

The requirements are just as specific:

4+ years in a technical, customer-facing role, or as a software engineer with consulting experience.
Production experience with LLMs: advanced prompting, agent development and evaluation frameworks.
Strong Python, and a record of shipping production applications.
High agency in ambiguous, complex organisations.
Communication strong enough to run discovery with customers.

Preferred: a background in a vertical like financial services or healthcare, experience with enterprise IT systems, and TypeScript or Java as additional languages.

OpenAI's FDE postings read similarly. They describe FDEs leading end-to-end deployments of frontier models alongside strategic customers, asking for 5+ years of engineering or deployment experience that includes customer-facing work, having built or deployed LLM-powered systems, and strong judgment on evaluation, privacy, security, governance and reliability. The healthcare-specific version explicitly welcomes people who built inside payers, providers or EHR companies.

Read those two side by side and the shape is clear. It is not a junior role. It is not a pure coding role. And the phrase that keeps coming up is not "10x engineer". It is some version of judgment under ambiguity, in front of a customer.

What a week actually looks like

This is the part the job posts compress into one line, so let me unpack it based on how deployment work goes in practice.

Discovery. The customer says they want "an AI assistant for claims". What they actually need is usually narrower and stranger: a way to pull three fields out of scanned PDFs, cross-check them against a legacy system nobody has documentation for, and route exceptions to a human. Finding that out is the job. Most failed deployments fail here, by building what was asked for instead of what was needed.

Building against real constraints. Their data is in a warehouse you have read-only access to through a VPN that drops every forty minutes. Their security team will not approve anything that sends certain fields off-premise. The production environment runs an older runtime. You build anyway.

Evaluation. This is the skill that separates people who have deployed LLMs from people who have demoed them. A demo works on five hand-picked inputs. A deployment has to work on the ten thousand ugly ones, and you need a way to prove it before the customer's compliance team will sign off. Building evaluation suites that catch hallucinations, regressions and grounding failures is not optional here. It is the core deliverable.

Handing it over. An FDE who leaves behind a system only they understand has failed, even if it works. The artifacts need to be maintainable by the customer's own team.

Feeding back. When you solve the same integration problem at three customers, that is a product feature waiting to be built. Good FDEs are the product team's best source of truth about what the real world needs.

FDE versus the roles it overlaps with

Honesty requires this section. The FDE title overlaps heavily with solutions architects, sales engineers, customer engineers and professional services engineers. Andreessen Horowitz has called it "title arbitrage", meaning an older role with a newer, more attractive name.

That criticism is partly fair. The difference, where there is one, is mostly about who writes the production code:

A sales engineer proves the product can work, usually in a demo or proof of concept, before the deal closes.
A solutions architect designs how it should fit, and often hands the build to someone else.
A forward deployed engineer builds the production system and owns it until it is running and handed over.

If a job titled FDE is mostly demos and pre-sales calls, it is a sales engineering job with a nicer title. Ask in the interview what share of the role is shipping production code. The answer tells you which job you are actually being offered.

Who this job suits, and who it does not

It suits you if you like being the person who figures out what the problem actually is. If you are comfortable in meetings where nobody knows the answer yet. If you would rather ship something imperfect that people use than perfect something nobody sees. If you can explain a technical tradeoff to a non-technical executive without condescending to them.

It does not suit you if you want long stretches of uninterrupted deep work on one codebase. If travel is a dealbreaker. If you find it draining to be accountable, in person, for something that is not working yet. Engineers who have left FDE roles tend to cite exactly these: the travel, and the pressure of resolving a customer's problem on a customer's timeline.

Neither of those lists is a judgment. They are two different jobs, and plenty of excellent engineers are much happier in the second one.

The roadmap

This is staged, not timed. People arrive with very different backgrounds, so "month three" means nothing. What matters is finishing each stage properly before leaning on the next.

Stage 1: Be a strong generalist engineer first

Nobody hires an FDE for their customer skills alone. The job posts ask for production shipping experience because on site, there is no one to hand the hard part to.

What that means concretely:

One backend language properly. Python is the one every FDE posting names. If you come from JavaScript like I do, TypeScript is a real asset for the platform side, but add Python.
APIs and integration. REST, webhooks, auth flows (OAuth especially), pagination, rate limits, retries. Enterprise deployment is mostly integration.
Data. SQL well enough to read someone else's schema and write correct queries against it. You will spend a lot of time in databases you did not design.
Deployment. Containers, one cloud provider, environment config, secrets. Enterprise customers deploy in their own cloud, so you need to be comfortable in whichever one they chose.

If you are early in your career, this stage is most of the work, and it is the right place to be.

Stage 2: Build real LLM systems, not demos

The job posts all say "production experience with LLMs". Here is what that phrase actually contains:

Prompting as engineering. Structured outputs, system prompts that survive adversarial input, and knowing when a prompt problem is really a retrieval problem.
Retrieval. Chunking, embeddings, hybrid search, and, more importantly, knowing when RAG is the wrong answer.
Agents and tools. Tool use, multi-step workflows, and the protocols the labs themselves ship. Anthropic's posting literally names MCP servers, sub-agents and skills as deliverables. I have written about MCP, skills and subagents if you want a starting point.
Evaluation. Build an eval set before you build the feature. Measure accuracy, grounding and regressions on every change. This is the single most underrated skill in the whole list.
Cost and latency. Know how model choice, caching and effort levels change your bill. It matters enormously once real volume arrives, and model choice is its own skill.

The portfolio test for this stage: one system that works on messy real data, with an eval suite you can show, and a written account of what broke and how you fixed it. That is worth more than ten demos.

Stage 3: Get customer-facing reps

This is the stage most engineers skip, and the one the job posts weight most heavily with "customer-facing" in the experience requirement.

Ways to get it without already having the title:

Agency or consulting work. This is where I got mine: client projects with real deadlines, stakeholders across time zones, and requirements that shift mid-sprint. It is unglamorous and it is excellent training.
Freelance projects for a real business, where you have to do the discovery yourself.
Internal customers. Volunteer for the project where engineering has to work closely with sales, support or operations.
Support rotations. Nothing teaches you how systems fail in the real world faster.

What you are building here is a specific habit: asking "what problem are you actually trying to solve?" before writing code, and translating between what a stakeholder says and what they need.

Stage 4: Pick a vertical

Both Anthropic and OpenAI list domain experience as preferred, and OpenAI has vertical-specific FDE roles such as healthcare. Domain knowledge compounds. An engineer who understands how claims processing, clinical workflows or trade reconciliation actually work is dramatically more useful on site than one who does not.

You do not need to pick on day one. But if you already work in finance, healthcare, logistics or government, that background is not a detour. It is an advantage most applicants do not have.

Stage 5: Build the proof and apply

For an FDE application, the strongest artifacts are:

A deployment write-up. Problem, constraints, what you built, how you evaluated it, what went wrong, what you would change. Written clearly, because writing clearly is part of the job.
An eval suite on GitHub. It shows the skill most applicants cannot demonstrate.
Evidence of customer work. Client projects, freelance work, an internal tool that another team adopted.

In the interview, expect a mix: a coding round, a system design round built around an ambiguous customer scenario, and a lot of questions about how you handle a customer who wants the wrong thing.

The honest summary

The FDE title is newer than the job. Consultants and agency engineers have been doing a version of it for decades. What changed is that AI made the deployment layer the scarcest, highest-value part of the stack, and the companies building frontier models realised their revenue depended on it.

If you like ambiguity, people and shipping, it is one of the most interesting jobs in software right now, and it pays accordingly. If you do not, it is still worth learning the skills in stages 1 and 2, because every AI engineering role in 2026 is asking for them. I break down what those roles ask for in what AI engineer job posts actually want.

Sources

#Forward Deployed Engineer
#Career
#AI
#Roadmap
#Engineering

Forward Deployed Engineer: The Role, the Skills and a 2026 Roadmap