What Does a Forward Deployed Engineer Do? Roles and Responsibilities, Explained

A forward deployed engineer is a software engineer who builds and ships production software inside a customer’s environment rather than in the vendor’s own product organisation. The work splits between engineering: integrations, data plumbing, LLM systems running against the customer’s real data, and working directly with the people who will use it, from operators to executives.

This page explains why the role exists, names the five things a forward deployed engineer is genuinely responsible for, and then draws the line that no competitor draws: what an FDE is not on the hook for, and which adjacent title owns it instead.

Why Does the Forward Deployed Engineer Role Exist?

Every competitor on this SERP jumps straight to “what does an FDE do?” without explaining why the seat exists at all. The answer is the page’s most useful section.

The role exists because a certain class of product cannot be sold and then left alone. It only becomes valuable after somebody has fitted it to one customer’s messy data, one customer’s workflow, and one customer’s approval chain. Until that happens, the product is a demo, not a system.

Marty Cagan of the Silicon Valley Product Group puts it directly (SVPG, 17 September 2025): forward deployed engineers are “technical people that embed with the target customer in order to deeply understand their environment, their problems, and what’s truly required to solve those problems and deliver the outcomes they need.” His argument is that this is a discovery mechanism, not a delivery cost: the FDE learns what the product needs to become by building inside the customer’s reality.

The concrete version of this is Illinois Tech’s account of OpenAI forward deployed engineers working with John Deere (June 2026): travelling to Iowa, working directly with farmers ahead of a tight growing-season deadline, scaling personalised guidance, and strengthening the underlying product while doing it. The work was not support. It was engineering, on site, under time pressure, against real agricultural data.

The scale evidence is named and dated: AWS announced a $1 billion investment in June 2026 to build a dedicated Forward Deployed Engineering organisation, embedding engineers directly inside customer teams to “co-develop and deploy agentic AI solutions in days.”

The line to land: the job exists because the last mile of enterprise software is not a support problem, it is an engineering problem. Until it is engineered, the product does not work at the customer.

The Five Things a Forward Deployed Engineer Is Responsible For

These five are grouped by who the work is for, not by verb. That is what makes them different from the flat bullet lists every competitor already has.

Responsibility	Who It Serves	What It Looks Like in a Week	How You Know It Is Being Done Badly
Building production software in the customer’s environment	The customer	Writing integrations against the customer’s real data, on their stack, inside their security review	The prototype only ever ran on an extract you were emailed, not on live data
Running technical discovery with the people who will use it	The customer and the product	Interviewing operators (not just managers), turning a vague complaint into a scoped, written problem statement	You spoke to the VP but never to the person who will click the button every morning
Owning delivery end to end	The customer and your team	From first prototype to something running in production with a named owner, no handoff to another team halfway	The system shipped but nobody on the customer side can explain what it does
Feeding the field back into the product	The vendor’s product team	What broke at the customer becomes a product change: a bug report, a feature request, a pattern worth abstracting	You shipped three engagements and the product team never heard about any of them
Making the work reusable, then handing it over	The next engagement and the customer’s team	Turning one customer’s solution into a pattern the next engagement starts from, transferring ownership to people who will keep it running	You are still the only person who can fix it six months later

Building Production Software in the Customer’s Environment

Real integrations against real data, on the customer’s stack, network policy and security review. Not demos, not prototypes on sample data. Anthropic’s posting asks for “production applications built inside customer systems using its models, including MCP servers, sub-agents and agent skills that will be used in production workflows.” 

Palantir’s asks for “wrangling massive-scale data and developing custom applications tailored to customer needs.” OpenAI’s asks the engineer to “own technical delivery across multiple deployments from first prototype to stable production.”

Running Technical Discovery with the People Who Will Use It

Interviewing operators, not just managers. Turning a vague business complaint into a scoped, written problem statement. This is a hard requirement in every posting, never a soft skill in the footer. Palantir: “engaging directly with customer stakeholders, from technical teams to executives.” OpenAI: “embed closely with customer teams, understand their needs, and guide adoption of what you build.”

Owning Delivery End to End

From first prototype to something running in production with a named owner. No handoff to a delivery team halfway. The FDE who scopes the problem builds the solution and deploys it. The FDE who only builds and hands off to someone else to deploy is a contractor, not a forward deployed engineer.

Feeding the Field Back into the Product

What broke at the customer becomes a product change. OpenAI asks the FDE to “share field feedback that helps Research and Product understand where the models succeed and where they can improve.” Anthropic asks FDEs to “contribute insights back to our Product and Engineering teams.” This is the responsibility that separates an FDE from a consultant. A consultant ships and invoices. An FDE ships and the product gets better.

Making the Work Reusable, Then Handing It Over

Both Anthropic and OpenAI ask the engineer to “identify and codify repeatable deployment patterns” or build “tools, playbooks, or building blocks that others can use.” Then transferring ownership to people who will keep it running. Wikipedia’s entry on the Forward Deployed Engineer notes the role’s responsibilities overlap with solutions architects, professional services engineers and systems integrators, but the product feedback loop and the reusability requirement are what make it distinct.

What a Forward Deployed Engineer Is Not Responsible For

Five titles this role is most often confused with, and the line that separates each one.

Solutions engineer. Pre-sales. Owns the demo and the technical win, not the production system. A solutions engineer proves the product can work; an FDE makes it work.

Technical account manager. Owns the relationship and the escalation path, not the code. A TAM ensures the customer has someone to call; an FDE ensures the customer has a system that runs.

Implementation consultant. Owns configuration of an existing product, usually billed by time rather than measured on outcome. An implementation consultant sets up what the product already does; an FDE builds what it does not do yet.

Support engineer. Owns incidents against a shipped product, not new builds. A support engineer fixes what broke; an FDE builds what has never existed.

DevOps or platform engineer. Owns the vendor’s own infrastructure, not the customer’s deployment. A DevOps engineer keeps the internal platform running; an FDE keeps the customer’s version running.

Three questions to ask a recruiter to find out which of these a posting really is:

• What share of the week is hands-on-keyboard coding?
• Who owns the system after go-live?
• Does anything I build go back into the product?

A posting that cannot answer the third question is not a forward deployed engineer role.

How the Role Changes from Company to Company

The same title means different things depending on who wrote the posting.

Palantir (the original). Deeply embedded, data-platform work at scale. The posting bar starts at 1+ years post-college. The FDSE title is the blueprint every other company copied.

Frontier AI labs (Anthropic, OpenAI). Production LLM systems, agents and evaluation. Anthropic asks for 4+ years in a technical customer-facing role. OpenAI asks for 5+ years that include customer-facing work. The work is heavier on AI-specific engineering and lighter on general data platform work.

Enterprise vendors and Indian product companies. The same seat may be titled deployment engineer, solutions engineer or implementation engineer, and the AI content varies enormously. Across the Indian postings we reviewed in September 2026, the experience bar clustered around 3 to 6 years.

The observation worth stating plainly: the same title spans a first engineering job and a senior hire depending on who wrote the posting. This is exactly why readers misjudge whether they qualify. 

Frequently Asked Questions

If the responsibilities above read like the job you want, the part most engineers have to build deliberately is the production AI half: shipping LLM systems that survive a customer’s real data and real security review. The Advanced Certificate in AI Forward Deployed Engineering with IIT Delhi is built around that: RAG architecture, agentic systems, LLM evaluation and observability, cost and latency at scale, security, and production deployment, across six months of live online sessions with recordings and five projects.