Why AI labs are hunting for Forward Deployed Engineers

OpenAI recently set up a new deployment company, and its first acquisition was neither a research lab nor a model startup. It was Tomoro, a British firm with 150 Forward Deployed Engineers. Anthropic has moved the same way, creating an external FDE consultancy backed by Blackstone and Goldman Sachs.

Both AI labs are spending money on more people, not more GPUs. Gergely Orosz, author of The Pragmatic Engineer newsletter, reports very strong demand for the role at Google, OpenAI and Anthropic. Lightcast data cited by Fortune show that FDE job postings from January to August 2026 were up more than 1,000% on the same period a year earlier.

If you are a developer with a few years of experience and wonder why this role is suddenly so hot, the answer lies in a less cheerful number.

The model is not the hard part. The customer is

A study by MIT NANDA examined 300 public enterprise AI deployments and found that 95% had no measurable impact on profit. Set beside the hiring numbers, that figure explains the demand. Models are now good enough to produce impressive demos, but the distance from a demo to something that works in real operations is as wide as it ever was.

Paraform, a recruiting company that tracks the role, sums up the business logic in two sentences: the demo wins the contract, and the production deployment keeps it. Paul Farnsworth, president of Dice, describes it from the enterprise side. Companies struggle to turn AI models into something that works inside their business, and FDEs fill that gap.

Take a typical case. A logistics company buys an AI platform to process shipping documents automatically. In the demo, the model reads clean sample invoices and extracts every field correctly. At deployment, the real documents turn out to be scattered across three different systems, half of them are photos taken on a phone, and the approval process needs sign-off from two departments that have never spoken to each other.

Nobody at the vendor’s headquarters can see any of this over Zoom. The person who can see it is the engineer sitting in the customer’s office. That engineer can open the customer’s database, ask the data-entry staff why they skip a particular field, and then write code so the system works with the data as it really is. That engineer is the FDE.

Leaving the Palo Alto office to sit beside the customer

Speaking to Fortune, Meline von Brentano of Palantir described how the company hires the best software engineers and pushes them out of the comfort of its Palo Alto office to work on site with customers. The word “comfort” matters most here. Real problems surface only in places engineers would usually rather avoid.

Paraform defines the role as sitting where hands-on customer problem-solving meets the deployment of AI systems. The two halves cannot be separated. Someone who is only good at talking to customers will promise things that cannot be built. Someone who is only good at coding will build things nobody uses. An FDE has to do both, often in the same week.

One objection deserves a hearing. A summary of The Pragmatic Engineer’s article puts forward the view that today’s FDE role is really closer to a consultant or a solutions architect. The point is useful because it gives you a question to ask of every job description. Does the role require you to write the code yourself and to own the outcome when the system fails at the customer? If not, it is consulting, not FDE work.

Here is a practical way to classify a role:

Question to ask of the JD	Consultant	Solutions architect	FDE
Who writes the final code?	The customer’s team	The vendor’s engineering team	You
When is the job done?	When the recommendations are handed over	When the design is approved	When the system runs for real on real data
Responsible when production breaks?	No	Indirectly	Directly

What you need to move into the role

FDE work exists to close the gap between demo and production, so the strongest evidence you can offer is that you have closed such a gap before. The first skill, then, is integrating with messy systems. Developers in Vietnam who work in outsourcing or on internal products often have an underrated advantage here. They are used to connecting to legacy systems, handling non-standard data and dealing with customers who change requirements halfway through a project.

The trouble is that your CV rarely tells that story.

Rewrite one project in the form an FDE recruiter wants to read. Describe the problem users had before you arrived, the systems you had to connect to, and the metric that changed after you shipped. One line like that says more than ten lines listing frameworks.

The second skill is customer discovery, and it can be learned. Instead of asking users which features they want, practise sitting beside them, watching how they actually work, and translating that process into a data flow yourself. If the role really sits where Paraform places it, between the customer and the system, this is the half that most developers rarely get to practise in their day jobs.

The third skill is harder to teach: tolerating ambiguity. Go back to the logistics example. Nobody writes you a ticket about three disconnected systems or two departments that never talk. You arrive at an unfamiliar office with an open question and have to work out what is worth building. If that sounds more exciting than frightening, you already have the most important trait.

On pay, Lightcast puts the median advertised salary for FDEs above $188,000, against about $145,000 for traditional software engineers. A separate analysis of 924 job postings by Recruiting From Scratch found a median of $195,000. That premium is the market’s price for the work that sits between demo and production.

Demos still win contracts, but the labs are spending real money on people who can keep them. The scarce asset now is the person who can make a model work inside a customer’s office, and over the next few years that person could be you.