An attorney called me into a meeting because her project showed thirty-something files. She had uploaded a hundred and fifty.
The cause was a stray period in a filter box. It was almost invisible if you didn't know the screen. The filter worked exactly as designed. I fixed it in the meeting in less than a minute. But if nobody had been in that room, she would have learned one thing: the system loses files.
No test would have caught that. The code was right. Her picture of the system was wrong, and that is what decides whether people use it.
Finding that gap is the whole job of a forward deployed engineer.
The short answer
A forward deployed engineer (FDE) is an engineer who sits with the client's team, learns how their work actually gets done, and builds the AI system into it. Half engineer, half consultant.
You are judged on whether their people use what you built. Not on whether it runs.
Where the name comes from
Palantir made the role up years before the current AI wave. Inside the company, engineers were split into "Devs" and "Deltas". Their own blog post, Dev versus Delta, puts the difference in two phrases: a Dev works on one capability for many customers, a Delta works for one customer across many capabilities. Deltas are the forward deployed software engineers. Each one supports one customer and measures success by that customer's goal.
Palantir still hires for it under that name. Its current FDE posting says engineers "embed themselves in the customer's reality until the problem is theirs", and asks them to own the work "from the first conversation with a customer" to shipping.
Why the AI labs want them now
The model companies found the same problem we did. A model that scores well in a demo still has to fit into a bank's ticket system or a law firm's review process. Somebody has to sit there and make it fit.
So they hire FDEs. On 22 October 2026, OpenAI's careers board listed 31 postings with "forward deployed" in the title, Anthropic's listed 7, and Palantir's listed 70. These counts include managers, interns and the same role in different cities, so read them as a sign of interest, not a headcount. Gergely Orosz's newsletter reported "massive demand for the role at Google, OpenAI, and Anthropic" in May 2026.
Read what the postings ask for and the shape is the same everywhere:
- OpenAI's FDE role in San Francisco covers "discovery, technical scoping, system design, build, and production rollout". Success is measured "through production adoption, measurable workflow impact".
- OpenAI's legal FDE role has you work closely with senior legal practitioners to "identify the right first use case".
- Anthropic's FDE role in London is about building production applications inside customer systems, including MCP servers, sub-agents and agent skills.
Notice the order. Discovery comes first. Code comes in the middle. Adoption is the finish line.
The domain is the hard part
I learned this on a production AI platform for U.S. legal documents. The model was the easy part. The hard part was knowing whether an extracted value was correct, because that depends on rules I didn't know existed. I had to learn how the specialists work, what they check first, and what a mistake costs them.
One attorney told me that before computers, they drew ownership charts by hand with coloured pens, one colour per type of document. That one sentence taught me more about what our screens had to show than any spec did.
This isn't only my experience. Eugene Yan and his co-authors, in their report on a year of building with LLMs, write about which roles an AI product needs. They say a team needs a domain expert at every stage. An FDE is the engineer who becomes part of that domain expertise, or at least learns to speak with it.
What the first two weeks look like
Mostly listening and watching. Very little code.
- Sit with the people who do the work. Watch a real task from start to end.
- Map what they do, step by step. Where do they copy, check, wait or redo?
- Collect real examples: real documents, real tickets, the messy ones too.
- Agree on what success looks like in their numbers. Hours saved, errors caught, cases closed. Not "accuracy" in the abstract.
If you skip this, you get what we once got: a policy chatbot that answered from an old version of a policy, because nothing in it knew that only the latest version counts. It worked in the demo and failed on real questions. I wrote about that one in what AI engineering is.
Who it suits, and who it doesn't
It suits developers who like talking to people and can live with things being unclear. The postings say this openly. Palantir's asks you to "make decisions with incomplete information". Anthropic's asks you to "thrive under ambiguity". Expect travel too: these postings mention 25 to 50%.
If you want a clear ticket and quiet time to work on it, this job will frustrate you. That is a fair reason to say no. Not every good engineer should be an FDE.
Be careful with the hype as well. One CTO's guide to AI job titles calls the role "hot and potentially oversold", and warns that some developers quit once they find it is close to consulting.
On experience: OpenAI's postings ask for 5+ years and Anthropic's for 4+. Palantir is different. It runs new grad FDE roles, and its general posting asks for 6+ months of work after college. So there is a door for people early in their career, but it is a narrow one.
If you enjoy figuring out someone else's business, it is the most interesting job in software right now. You see the whole thing: the person, the problem, the system, and the moment it starts to help.
One thing to do this week
Pick one person who uses software you built, at work or outside it. Watch them use it for thirty minutes. Don't help and don't explain. Write down every moment they stop, frown or go back.
That list is the first page of an FDE's notebook. The model was the easy part. The list is the job.