A forward deployed engineer (FDE) builds and ships production software inside a customer's environment, and is measured on whether people there actually use it. It is real engineering; what makes it a different job is that the customer is inside the loop, not on the other side of a ticket.
Solid lines carry the work forward; dashed lines carry what it teaches back. Pans sideways on a phone.
The job, against the one you may have now
- Owns a component; users arrive through tickets
- Your stack, your CI, your conventions
- Done means merged and shipped
- Measured on the system's health
- Owns an outcome at a named customer
- Their cloud, their auth, their laptop policy
- Done means people there open it every day
- Measured on adoption, then renewal
Same craft, different week: a large share of it is with the customer, and that time is the work, not an interruption to it.
The title started at Palantir, whose deployment engineers were placed with a customer for months at a time. It is now a standard role at the frontier labs: Anthropic and OpenAI both post “Forward Deployed Engineer” jobs that work with their largest customers. Read the responsibilities, not the title; the same job also appears as applied AI engineer, deployment engineer or solutions engineer on an engineering track (Interview Loops).
The four jobs people confuse it with
Positions are qualitative, from job postings and the interview loop, not a survey.
| Role | Ships it? | Measured by |
|---|---|---|
| Sales engineer | No: the demo is the artifact | Deals influenced |
| Solutions architect | Rarely: someone else builds it | Designs accepted |
| Consultant | Sometimes, then hands it over | Billable delivery |
| Forward deployed | Yes, and carries the pager | Whether it is in use |
The last row is the whole distinction. If nobody at the customer uses what you built, a sales engineer can still have had a good quarter; an FDE did not. Candidates who answer the interview as the wrong role lose the offer.
Why every lab is hiring them now
- Models got good enoughWorth deploying inside a real workflow
- The gap movedFrom the model to the customer's data, auth and process
- Labs built teamsFDE roles at Anthropic, OpenAI and the agent startups
- A field formedIts own track at AI Engineer World's Fair 2026
The customer's data is messy and undocumented, their auth is bespoke, their definition of done lives in someone's head, and their edge cases are in nobody's eval set. A better model does not close that gap; an engineer sitting in their environment does. Latent Space's recap of the 2026 World's Fair lists forward deployed engineering among the themes of enterprise adoption. The case for moving now is in the last mile is hiring.
What the first six weeks look like
- Weeks 1–2Find the real problem, not the stated one
- Weeks 2–4Meet the data as it really is
- Weeks 4–6Ship one narrow workflow to production
Find the real problem. “We want a chatbot over our docs” often turns out to be “support answers the same forty questions and cannot find the answer fast enough”. Those are different systems, and the customer round of the interview tests exactly this (The Customer Round).
Meet the data. Scanned PDFs, a table nobody updated since a migration, three systems that disagree about who the customer is. Most of the engineering time and nearly all of the schedule risk live here (Document Processing, RAG FDE Scenarios).
Ship narrow. One workflow, used by real people, with an eval set drawn from their traffic. What “in production” must mean: Deployment & Rollout, failure modes and where a person stays in the loop.
The instinct that sinks a deployment
- Build the general framework first
- Handle every case before launch
- Six weeks in: a demo, nothing in production
- Pick one workflow and one team
- Ship it, watch it, fix what breaks
- Six weeks in: people use it every morning
Narrow and used beats broad and demoed. The general version gets built later, on the lab side, once three customers have needed it.
What makes someone good at it
- Speed to the real problem
- Spending the first days asking, and knowing when the stated ask is not the ask.
- Tolerance for other people's systems
- More time reading unfamiliar code and undocumented schemas than writing anything new.
- Writing
- A memo that makes a decision legible to people who were not in the room.
- Scope discipline
- “Not in v1, and here is why,” said to a stakeholder without losing them.
- Being the only engineer there
- Their constraints become yours, from tenant isolation to the security review.
The parts the job post leaves out
| Topic | Day to day | First call |
|---|---|---|
| Travel | From none to most weeks | The number, not “some” |
| Accounts | One to three at once | How many, and for how long |
| After go-live | Someone carries the pager | Who, and when it hands off |
| Pay | Bands often sit above the platform level | The band, directly |
| Exits | Into product, or staff platform work | Who left the team, and to what |
Compensation moves too fast to print; frontier-lab postings now state ranges, so read them. The two common exits follow from the job: you have watched real users, which product teams want, or you have rebuilt the same thing at three customers and know what the platform is missing.
How to move into it
- Needs one project where you met the users yourself
- Cut scope on purpose, and can say what you did not build
- Needs one production system you built and then operated
- On call, incidents, the boring parts
- Needs a tolerance for plumbing and scanned documents
- Ship something a non-expert uses
In every case the technical bar is a real bar: design an agentic system on a whiteboard, name its failure modes, and put numbers on the tradeoffs. Start with the free system design framework and your first agentic system.
“Why this role, and not platform engineering?” Answer with the measure: you want to be judged on whether a system is used at a named customer, and you can show a time you cut scope to get something narrow into production. The trap is describing the demo you built; interviewers hear sales engineering.
A posting says “Solutions Engineer” but the role ships code to customers' production and is on call for it. Which job is it?
Forward deployed, whatever the title. The test is whether you ship to production and own whether it is used, not the name on the posting.
Four weeks into a deployment you have a clean, general framework and no users. What went wrong, and what do you do this week?
The platform instinct: building the general thing before one narrow thing worked. Pick one workflow and one team, ship it to production, and let the next two customers show what to generalise.
Which row of the role table separates an FDE from a consultant?
Ships to production and carries the pager: a consultant often ships and hands over, and is measured on delivery. The FDE is measured on whether the system is in use.
- An FDE ships production software inside a customer's environment and is measured on adoption.
- It differs from sales engineering, solutions architecture and consulting on one row: shipping and running it.
- The role exists because models became deployable before customer environments did.
- Narrow and in production beats broad and demoed; the platform instinct is the trap.