Why AI labs are racing to hire forward deployed engineers
Forward deployed engineer roles are up 800% and the AI labs are pouring billions into "deployment companies." The people winning them aren’t prompt wizards. They’re translators who can read a legacy schema and survive a compliance review.

TL;DR
- Forward deployed engineer postings jumped ~800% in a year, and OpenAI and Anthropic are each funding multi-billion-dollar "deployment" arms, because frontier models still don’t run themselves inside real companies.
- MIT’s NANDA report found 95% of enterprise GenAI pilots delivered no measurable business impact. The bottleneck isn’t model quality; it’s integration.
- The labs are running Palantir’s decade-old playbook: stop selling licenses, embed engineers in the customer until the system actually works.
- The winners aren’t "AI whisperers." They’re translators who understand a specific industry’s plumbing: how a bank clears a transaction, how a hospital codes a claim.
- Want the role? Spend less time on prompts and more on learning how one messy, regulated domain really operates.
Open LinkedIn this week and somebody is telling you to become a forward deployed engineer. For once, the hype has receipts. Job postings are up something like 800% in a year. OpenAI stood up a $4 billion joint venture with the gloriously unsubtle name “the deployment company.” Anthropic is building a $1.5 billion version of the same idea.
So before you rewrite your headline to “FDE: shipping AI in the enterprise,” it’s worth asking what the job actually is, and why the most valuable AI labs on earth suddenly need armies of people to do it.
The quiet part: the models don’t work yet
Not in the lab. In your company.
A frontier model can pass the bar exam and still have no idea which of your seven Salesforce instances holds the real customer record. MIT’s NANDA initiative put a number on the gap this year: 95% of enterprise GenAI pilots showed no measurable business impact. Read that again. Not 95% were bad models. 95% never made it from demo to dollars.
That’s not a model problem. It’s an everything-else problem. The data lives in a schema someone designed in 2009 and then left the company. The workflow has a compliance step that only exists because of a lawsuit nobody talks about. The “obvious” automation falls over the first time it meets an edge case the people doing the job could have warned you about on day one.
The model is genuinely the easy part now. Getting it to survive contact with a real business is the hard part, and that part still wants a human in the room.
Palantir already ran this experiment
None of this is new. It’s just new to the labs.
Palantir worked it out more than a decade ago. Sell a software license to a Fortune 500 and walk away, and you mostly bought yourself some shelfware and an awkward renewal call. So they did the deliberately unscalable thing: they sent their own engineers to sit inside the customer (at the bank, the agency, the hospital) and refused to leave until the system actually ran. They called them forward deployed engineers. The Valley smirked at how un-SaaS it all was. It also worked.
OpenAI and Anthropic are now copying that homework, except the shelfware in question is a $20-a-seat model that dazzles for a week and then quietly gets abandoned. A “deployment company” is just Palantir’s old insight with a far bigger checkbook: stop selling access, start selling outcomes, and put a person on-site to make sure the outcome shows up.
The job is translation, not prompting
This is where the LinkedIn version gets it wrong.
The people winning these roles aren’t AI whisperers. Forty clever prompt tricks are table stakes, and frankly that’s the skill the model is quickest to absorb on its own. The scarce ability is translation: sitting between a system that speaks tokens and a business that speaks claims, transactions, tickets, and regulations, and getting the two to understand each other.
In practice that means reading a legacy schema without flinching. Sitting through a security review and knowing which answer ends the meeting and which one ends the deal. Watching how the work really gets done, not how the org chart says it gets done, and catching the undocumented step everyone on the floor takes for granted. A good FDE spends a strange amount of time just watching people work.
It’s less “AI researcher” and more “consultant who can also ship code and won’t get steamrolled by the client’s IT team.” And it’s worth saying plainly: it can be a grind. You’re on someone else’s turf, on their timeline, fixing problems that appear on no model card anywhere. The glamour mostly lives in the title.
So what do you actually go learn?
If you want one of these roles, the counterintuitive move is to spend less time on AI.
Go learn how a bank actually clears a transaction. How a hospital actually codes a claim and gets paid. How a refinery actually schedules maintenance without anything catching fire. Pick a messy, regulated, high-stakes domain and get fluent in its plumbing:
- the systems of record, and which one is quietly lying
- the constraints that look dumb until you learn the regulation behind them
- the words insiders use, and the words that mark you as an outsider
- the reasons things are slow that have nothing to do with incompetence
The model is a commodity now. Everyone’s renting the same handful of them. Domain fluency is not. The person who can walk into a logistics company already speaking their language is worth more than the person with an immaculate eval suite who has never heard the phrase “bill of lading.”
The frontier moved. The intelligence got cheap; the work of making it land somewhere real did not.
So if you’re betting the next few years of your career on AI, don’t bet on the model. Bet on the messy, human, deeply specific work of making it useful inside a real organization. That’s the part that’s still hiring. And if you want to talk about building in that space, come find us.
Frequently asked questions
- What is a forward deployed engineer (FDE)?
- A forward deployed engineer embeds inside a customer’s organization to make a software or AI product actually work in their real environment. Instead of shipping a license and leaving, the engineer learns the customer’s systems, data, and workflows on-site and stays until the product delivers a measurable result.
- Why are AI labs like OpenAI and Anthropic hiring so many FDEs right now?
- Because frontier models demo well but rarely survive contact with a real enterprise. MIT’s NANDA initiative found 95% of enterprise GenAI pilots produced no measurable business impact. The gap is integration, not intelligence, so the labs are sending engineers on-site to close it: OpenAI through a $4 billion "deployment company" joint venture and Anthropic through a $1.5 billion effort of its own.
- Do I need to be an AI or machine-learning expert to become a forward deployed engineer?
- No. Prompting and model knowledge are table stakes, and they’re the easiest part to pick up. The scarce, valuable skill is domain translation: understanding how a specific industry actually operates, reading legacy systems, and navigating compliance and security reviews well enough to ship something.
- Where did the forward deployed engineer model come from?
- Palantir popularized it more than a decade ago. Rather than selling software and walking away, Palantir embedded its own engineers inside banks, agencies, and hospitals until the systems ran. The current wave of AI "deployment companies" is essentially the same playbook with much larger budgets.
- How do I prepare for a forward deployed engineer role?
- Pick a messy, regulated, high-stakes industry and learn its plumbing: the systems of record, the regulations, the vocabulary insiders use, and why things move slowly. Concretely, learn how a bank clears a transaction, how a hospital codes a claim, or how a refinery schedules maintenance. Domain fluency is rarer and more durable than prompt skill.


