Forward deployed engineering, Part 1: What a forward deployed engineer actually does

The title forward deployed engineer (FDE) now appears on public job boards at Google Cloud, Microsoft, OpenAI and Anthropic. In my work with partners, the question I hear next is always the same: what does an FDE actually do all day, and how is it different from the technical roles we already have?

This part answers that question from the basics. I start with what public job descriptions say, then define the role in plain words, look at where the term came from, and compare the FDE with four roles people often confuse it with. Then I walk through how an engagement runs, using the same fictional company as the Production-ready agents series, and finish with the mix of skills the job needs.

This series is about what the job involves and how to do it well. It is not a guide to getting hired anywhere.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: what a forward deployed engineer actually does, from embed to hand-over, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Where does this show up in an FDE job description?

Here are four lines from public postings, quoted directly:

“…an embedded builder who bridges the gap between frontier AI products and production-grade reality within customers.” (Google Cloud, Forward Deployed Engineer IV, GenAI)

“…moving beyond high-level architecture to code, debug, and jointly ship bespoke agentic solutions directly within the customer’s environment.” (the same Google Cloud posting)

“Embed deeply with strategic customers to understand their business challenges and technical requirements in detail.” (OpenAI, Forward Deployed Software Engineer)

“Validate: prove the outcome with measurement the customer agrees with, not with a demo.” (Microsoft, Principal Forward Deployed Engineer)

Three words carry most of the meaning: embedded, ship and outcome. The rest of this post unpacks them.

What is a forward deployed engineer?

The simple definition first. A forward deployed engineer is a software engineer who works inside one customer’s organisation, writes and ships the code that gets a product working on that customer’s real systems, and brings what they learn back to the team that builds the product.

Now the more formal version, built from the postings above. An FDE is an engineer employed by a technology vendor, assigned to a strategic customer for a defined engagement, who owns the technical delivery of a production system on the customer’s estate and acts as a feedback channel from the field to the vendor’s product and engineering teams.

That definition has five parts, and each one is a term you will meet throughout this series:

Vendor. The company whose product is being deployed: Google Cloud, OpenAI, Anthropic and so on. The FDE is employed by the vendor, or by a partner working on the vendor’s behalf.
Engagement. A piece of work with a start, an agreed goal and an end. It is usually measured in weeks or months, and it ends with a hand-over.
Estate. Everything the customer already runs: their data platforms, identity provider, networks, security rules, code repositories and, just as important, their people and processes.
Production. A system that real users rely on, that is secured, monitored and supported, and that keeps running after the FDE leaves. A demo that works once on a laptop is not production.
Feedback loop. The habit of turning problems found in the field into bug reports, feature requests and reusable code that the product team can act on.

the key ideas: a product team builds for many customers, a forward deployed engineer is embedded in one customer's estate to get a working system into production, and field insight flows back to the product team

One everyday comparison helps. A building firm sends a site engineer to a client’s plot, where they work with that plot’s ground conditions and that client’s builders until the building stands. Mapped to our terms: the firm is the vendor, the plot is the customer’s estate, the finished building is the production system, and the site engineer’s notes back to head office are the feedback loop.

Where did the term come from?

The term is most closely associated with Palantir, the data and software company. In a 2019 post on its engineering blog, Dev versus Delta, Palantir explains its two biggest engineering roles. Software Engineers, called “Devs” internally, sit in Product Development and build the platforms. Forward Deployed Software Engineers, called “Deltas”, sit in Business Development and deploy those platforms to customers. The name “Delta” comes from the company’s early days, when each Business Development team was named after a letter of the NATO alphabet.

The post sums up the difference in one line: a Dev’s focus is “one capability, many customers”, while a Delta’s focus is “one customer, many capabilities”.

Palantir's two engineering roles: a Dev builds one capability that many customers use; a Delta, the forward deployed software engineer, brings many capabilities to one customer

The post also tackles the most common misunderstanding, that a Delta is a consultant. As one engineer quoted there puts it, consultants “generally create a one-time analysis, recommendation, or solution to a specific problem”, while Deltas build a long-term solution with the customer on existing software products, and often contribute code back to the core product.

What changed recently is the subject. AI vendors now deploy models, agent platforms and MCP servers (Model Context Protocol servers, which expose tools and data to AI agents in a standard way). Google’s posting names the problem directly: the FDE addresses “blockers to production including solving the integration complexities, data readiness issues, and state-management issues that prevent AI from reaching enterprise-grade maturity”. My view: that gap between a working demo and a production system on someone else’s estate is exactly where an embedded engineer earns their place, which is why AI vendors have adopted the title.

What do public job descriptions actually ask for?

I read the public FDE postings from Google Cloud (both the customer-facing role and the partner-facing one), Microsoft, OpenAI and Anthropic side by side. The wording differs, but six duties recur.

six duties that recur across public forward deployed engineer postings from Google Cloud, Microsoft, OpenAI and Anthropic, with the postings that name each one

Discover and scope. Google asks for “experience leading technical discovery sessions with customers”; Microsoft asks the FDE to “establish the problem statement, the baseline, the agreed success measures and the plan”. Part 2 covers this.
Build production systems. Google names “multi-agent systems, MCP servers”; Anthropic names “MCP servers, sub-agents, and agent skills”. Parts 4, 6 and 7 cover the build.
Integrate with the estate. Google calls this “the connective tissue between Google’s AI products and customer’s live infrastructure, including APIs, legacy data silos, and security perimeters”. Parts 3 and 5 cover it, and my post on wiring Gemini Enterprise to Databricks Genie is a worked example.
Evaluate and observe. Google asks for “evaluation pipelines and observability frameworks” and knowledge of LLM-native metrics (measures specific to large language models, such as tokens per second and cost per request). Part 9 covers the performance side.
Prove the outcome. Google ties the work to “measurable Return on Investment (ROI)”, and Microsoft asks for measurement the customer agrees with. Part 10 covers this.
Feed back to product. Every posting has a version of this. Google asks FDEs to turn “repeatable field patterns and friction points” into “formal product feature requests”. Part 8 covers how.

Two practical details also recur. Anthropic and OpenAI both mention frequent travel to customer sites (25 to 50 per cent, and up to 50 per cent). And Google’s partner FDE posting describes the same work done with “strategic AI partners and their own FDE teams”, so the role exists on the partner side as well.

How is an FDE different from the roles I already know?

The FDE overlaps with four familiar roles. I describe each one the same way, with a short example from the Acme engagement that runs through this series.

Solutions architect. Designs how a product should fit a customer’s systems, usually across several accounts at once, and mostly through diagrams, reviews and guidance. At Acme, a solutions architect would recommend federating BigQuery and Databricks instead of copying data. Choose this role when the customer’s own team will do the build.
Customer engineer. Google Cloud’s title for technical pre-sales engineers, who run evaluations, demos and proofs of concept while a deal is shaped. At Acme, a customer engineer might demo an agent answering a marketing question. Choose this before a commitment is made. Google also advertises an AI Outcome Customer Engineer role that “bridges the gap between pre-sales agreement shaping and post-sales execution” and is “aligned with our Forward Deployed Engineering (FDE) organization”, which shows how close the roles have become.
Consultant. Analyses a problem and recommends a solution, often time-boxed and often independent of any one vendor’s product. At Acme, a consultant might produce a report on why marketing and supply disagree about the campaign. Choose this when the customer mainly needs a decision made and will build later.
Software engineer (on a product team). Builds a capability that every customer uses. At Acme, this is the vendor engineer who fixes the bug the FDE reported. Choose this when the fix belongs in the product for everyone.

where the roles sit, in my view: consultants and FDEs serve one customer, product software engineers and customer engineers serve many; consultants and architects mostly advise, FDEs and software engineers ship production code

My view: the clearest test is the question “who owns the code that runs in this customer’s production, and who answers for the outcome?” If the answer is the FDE, with the customer’s own team alongside, you are looking at forward deployed work. If the answer is “the customer, following our advice”, it is architecture or consulting.

How does an engagement run?

Every posting describes the same arc, even if they name the steps differently. Microsoft’s posting uses Discover, Build and Validate. I split it into five stages because the middle of the arc, turning a prototype into something production-ready, is where most engagements stall.

how an engagement runs: embed, discover, build, harden and hand over, all inside the customer's estate; each finished use case can lead to the next, and field insight flows to the product team throughout

Embed. Get access to the systems, the data and the people. Learn who owns what. On day one, an FDE often has a laptop and no permissions, so this stage is mostly about requests, introductions and reading.
Discover. Turn a business problem into something buildable: a clear problem statement, a success metric (a number both sides agree will show whether it worked), a first use case and a list of things you are deliberately not doing yet.
Build. A prototype in days, on real data, built together with the customer’s engineers, who will own it later. The prototype exists to learn quickly and is often thrown away on purpose.
Harden. Add everything production needs: identity, guardrails, evaluations, tracing, cost controls and a deployment pipeline. This is usually the longest stage.
Hand over. Write the runbook (the document that tells the customer’s team how to operate and fix the system), name the owners, train the team and review the outcome against the baseline from discovery.

The weeks in the diagram are illustrative, for one first use case. Real engagements vary a lot, and a good hand-over often leads straight into the next use case.

What does this look like at Acme?

Here is the running example. Acme Consumer Brands (fictional) ran an advertising campaign. Marketing says it was a success, supply says it was a failure, and both are right. The advertising data lives in BigQuery (Google Cloud’s data warehouse) and the delivery data lives in Databricks (a separate data platform). Nobody has put the two side by side.

Imagine you are the FDE embedded with Acme. The Production-ready agents series is the build: three agents that answer questions across both sources without copying data.

the build from the production-ready agents series in one picture: a user asks in Gemini Enterprise, the router agent splits the question, the marketing agent reads BigQuery and the supply agent reads Databricks as the user, and one checked answer comes back

Part 5 of the agents series, The router builds the router, and the series introduction walks through the whole system.

This series is everything around that build, and each stage produces something concrete:

what each stage produces in the Acme engagement, and where this series and the production-ready agents series cover it

Notice how much of the engagement is not agent code. Before the first agent exists, you need access to two data platforms owned by two different teams, an agreed question, and a number that will show whether the answer helped. After the agents work, the engineering continues: per-user access to Databricks (agents Part 7), release gates (agents Part 10) and a staged rollout to real users (agents Part 12).

The feedback loop also shows up at Acme. Suppose, as an illustration, the router times out when a supply manager asks a long, multi-part question. That symptom has two possible causes, and the FDE’s job is to find out which.

the feedback loop in practice: a symptom at Acme is reproduced and isolated; a problem in Acme's estate is fixed there, while a product bug or gap becomes a report that the product team fixes and releases to every customer

If the cause is in Acme’s estate, such as a firewall rule or an undersized warehouse, you fix it there. If it is a product bug or a missing feature, the same small reproduction becomes a report the product team can act on. Part 8 covers this loop in detail, including a bug report template.

What skills does the job need?

The postings ask for a wide mix. Google’s minimum qualifications include software development in Python, building pipelines for structured and unstructured data with vector databases and retrieval-augmented generation (RAG: fetching relevant documents and giving them to the model with the question), taking AI solutions to production, architecting AI systems on a cloud platform and leading discovery sessions. Its preferred qualifications add multi-agent frameworks (it names LangGraph, CrewAI and ADK) and patterns such as ReAct (a loop in which the model reasons, calls a tool and reads the result). The AI Outcome Customer Engineer posting adds debugging code, enterprise integrations and “translating deep technical integration issues into business impact”.

I group these into five columns:

the skills mix that public postings ask for, in five groups, and the parts of this series and the agents series that cover each group

My view: few people arrive strong in all five. In my work with partners, I see people come to this work from two directions. Some are strong engineers learning to run discovery and talk to executives; others are strong customer-facing architects learning to ship production code. Both paths work, and this series is written so you can start from either. If you have never built an agent, read agents Part 1 alongside this one.

Try it: map a real job description to the engagement

The best way to understand the role is to read real postings closely. This short script sorts the lines of a job description into the five engagement stages, using simple keywords. It needs only Python 3, with no extra packages. Save it as map_posting.py:

import sys

STAGES = {
    "embed": ["embed", "on-site", "travel", "relationship"],
    "discover": ["discovery", "scope", "problem statement", "success measure", "feasibility"],
    "build": ["prototype", "build", "code", "ship", "integrat", "mcp"],
    "harden": ["production", "evaluation", "observability", "security", "latency", "tracing"],
    "hand over": ["best practice", "adoption", "long-term", "runbook", "train"],
}
FEEDBACK = ["feedback", "feature request", "roadmap", "product and engineering"]

text = sys.stdin.read().lower()
for line in [l.strip() for l in text.splitlines() if l.strip()]:
    hits = [s for s, words in STAGES.items() if any(w in line for w in words)]
    if any(w in line for w in FEEDBACK):
        hits.append("feedback loop")
    print(f"{', '.join(hits) or '(none)':<32} {line[:60]}")

Copy the responsibilities section of any public FDE posting into a file called posting.txt, one duty per line, and run python3 map_posting.py < posting.txt. With the five responsibilities from the Google Cloud FDE IV posting linked below, I got:

build, harden                    serve as a developer for complex ai applications, transition
build, harden                    architect and code the connective tissue between google’s ai
build, harden                    build high-performance evaluation pipelines and observabilit
feedback loop                    identify repeatable field patterns and friction points in go
build, hand over                 co-build with customer engineering teams to instill google-g

Look at the third line. The script tagged it “build” only because the sentence starts with the word “build”, although the duty is really about hardening. Keyword matching is crude, and that is the point of the exercise: the useful part is reading each duty yourself and deciding which stage of an engagement it belongs to. Notice also that no line in this posting maps to “embed” or “discover”; the posting puts discovery in its qualifications instead. Then try these:

Run it on postings from two different companies and compare which stages each one stresses.
Add a “prove” stage with keywords such as “roi”, “baseline” and “measur”.

What can go wrong

Drifting into consulting. If weeks pass with slides but no running code on the customer’s systems, the engagement has become advisory work. Get a prototype onto real data early.
Building in your own environment. A system that runs in the vendor’s test project but not behind the customer’s network and identity rules has not been deployed. Build where it will run as soon as access allows.
Becoming the system. If only the FDE can operate or fix what was built, the hand-over has failed. Pair with the customer’s engineers from the first week and write the runbook as you go.
Feedback as anecdote. “A customer was unhappy” does not change a roadmap, and neither does a workaround you quietly build twice. Microsoft’s posting asks FDEs to bring the pattern instead of the anecdote, backed by reproductions and measurements.
No agreed measure. If nobody wrote down the baseline and the success metric during discovery, you cannot prove the outcome at the end, however good the system is.

What did we learn?

A forward deployed engineer is a software engineer, employed by a vendor or partner, who works inside one customer’s estate, ships a production system there and feeds what they learn back to the product team.
The term is most closely associated with Palantir, where a forward deployed engineer’s focus was “one customer, many capabilities” and a product engineer’s was “one capability, many customers”.
Public postings from Google Cloud, Microsoft, OpenAI and Anthropic share six duties: discover and scope, build, integrate, evaluate and observe, prove the outcome, and feed back to product.
The clearest test that separates an FDE from an architect or a consultant is who owns the code running in the customer’s production and who answers for the outcome.
An engagement runs through embed, discover, build, harden and hand over, and hardening is usually the longest stage.
Few people arrive strong in all five skill groups, and people reach this work from either the engineering side or the customer-facing side.

What comes next?

An engagement succeeds or fails in its first two weeks. In Part 2, Discovery: from a business problem to something you can build, we sit down with Acme’s marketing and supply teams, write the problem statement and success metrics, choose the first use case, decide what to say no to, and produce a one-page engagement brief.

Sources

Google Careers: Forward Deployed Engineer IV, GenAI, Google Cloud (about the job, responsibilities and qualifications)
Google Careers: Forward Deployed Engineer, GenAI
Google Careers: Partner Forward Deployed Engineer V
Google Careers: AI Outcome Customer Engineer
Microsoft: Principal Forward Deployed Engineer (Microsoft posting as listed on Built In; the listing closed in October 2026)
OpenAI: Forward Deployed Software Engineer, San Francisco
Anthropic: Forward Deployed Engineer, London
Palantir: Dev versus Delta: Demystifying engineering roles at Palantir (8 April 2019)
Model Context Protocol: Introduction

Opinions are my own. Every fact in this post comes from the public documentation linked above. Acme Consumer Brands and its data are fictional, and job postings change or close over time; the quotes above were checked in October 2026.