For three years the debate about why AI doesn't land inside companies got answered by staring at the model. The context window, the hallucinations, the next one will be the good one. And the next one arrived, and then another, and your company's process is still done by hand. In 2026 the market stopped pretending the problem was the model and put a name on what was missing: a person.
The thesis in one sentence: you don't need to hire a forward deployed engineer. You need the function that role stands for, bought in fractions and tied to one concrete workflow instead of to a platform. That distinction sounds like a nuance. It is the difference between burning an annual budget and having a process running in six weeks.
What a forward deployed engineer is, and why the title shows up right now
A forward deployed engineer is an engineer who works inside the client: understands the real process, builds the solution against the systems that already exist, and doesn't leave until the thing runs in production. Half engineer, half field consultant. Palantir has run the figure for two decades; the canonical definition —responsibilities, skills, and when NOT to hire one— lives in the forward deployed AI engineer entry of our role catalogue, and we're not repeating it here.
What does need explaining is why the title exploded now, and the answer has a date. On May 11, 2026, OpenAI announced the OpenAI Deployment Company, a standalone business unit created, in its words, to develop the operating model, the pace and the customer focus this work demands. Its stated job is to embed forward deployed engineers in organizations solving complex problems in demanding environments. And to avoid starting from zero, the same announcement included the acquisition of Tomoro, an applied AI consultancy that brings around 150 FDEs and deployment specialists from day one. Source: OpenAI launches the OpenAI Deployment Company, OpenAI, May 11, 2026.
Read that again, because it is a confession. The company that makes the best-selling model in the world decided that for its product to work inside a business you have to stand up another company and buy a hundred and fifty people. The bottleneck stopped being intelligence. It's the landing.
What the role is not, and why the confusion costs you money
Three profiles get sold today with the same pitch and do different jobs. Telling them apart is what stops you buying the wrong one:
- It's not a consultant. The consultant hands you a document with what you should do. The FDE hands you the process, done. If what you're left with at the end of the engagement is a deck, you bought consulting with a new name.
- It's not an AI engineer. The AI engineer builds the system; the FDE builds the system and works out what the problem actually was, which is the part nobody has written down anywhere and the part that eats 70% of the calendar.
- It's not customer success. Customer success makes sure you use what you bought. The FDE changes what you bought until it fits how your people actually work, not how the manual says they work.
The acid test is a single question: is this person going to write code against my systems, or write about my systems? Everything else is job titles.
The problem: the enterprise shape wasn't built for you
Here comes the uncomfortable part. The role is real, it is the one that works, and the way it gets sold is designed for the other end of the market. The enterprise version is a dedicated team for months, embedded in the organization, on a multi-year commitment and —almost always— tied to the platform of whoever deploys it. It works. And a company of 50 to 500 people can't buy it, for two different reasons worth keeping separate.
The first is obvious: the price. The second is less obvious and worse. Even if you could pay for it, you don't have enough work for a full-time position, and an FDE without a queue of problems turns into an expensive employee waiting. Your company's need isn't continuous: it's intense for six or eight weeks per process, and then it drops to maintenance. Putting a demand shaped like that on the payroll is exactly the mistake you've been making for years with other profiles.
And there is a third reason, a silent one, that only shows up the following year: platform lock-in. If whoever embeds in your operation gets paid on consumption of their own product, the solution they design will run on their product. Not out of bad faith —out of gravity. It's the same trap explained in platforms for building AI agents: the exit cost isn't paid when you sign, it's paid in month 7.
You don't need the position, you need the function
The way out isn't giving up the role. It's buying it in another shape: in fractions, by workflow, with an ending written down. Instead of an engineer embedded indefinitely, an engagement scoped to one process —the one that hurts most— with a date on which that process runs by itself and a person on your side who stays on as its owner.
The practical difference is that what you're buying stops being a person's time and becomes a process in production. It changes who carries the risk. If the project runs long, on the hours model you pay more; on the outcome model, you don't. It's the same logic we apply when we build AI agents for enterprise, and the reason the first conversation is always about the process and never about the model.
The real work, besides, looks very little like the demo promises. Most of the calendar goes into connecting AI to the systems you already have —the 2011 ERP, the CRM with fields nobody remembers the purpose of, the spreadsheet that is in fact the company database— and into discovering that the documented process and the real process look nothing alike. A better model doesn't fix that. Somebody sitting there does.
The three things to demand in writing before you sign
It doesn't matter who you hire —big vendor, boutique, freelancer, us—. If these three aren't written down before you start, what you bought is time, not outcome:
- Which process ends up in production, named. Not "AI capabilities in the commercial area". The name of the process, with its trigger and its output: "the classification and first reply for the emails landing in support". If it doesn't fit in one sentence, it isn't scoped.
- How it gets measured, with today's number. The indicator and its current value, taken before you start. Without the baseline, in three months the discussion about whether it worked is a discussion of opinions, and that one is always won by whoever invoices.
- Who operates it when the person who came leaves. A first and last name on your side, trained during the engagement and not in the final week. This is the one most often skipped and the only one that decides whether the system is still alive next year.
The third deserves its own paragraph, because it's where most technically successful deployments die. An automated process without an internal owner doesn't fail in month one: it fails the day a business rule changes and nobody knows where to touch it. That is the entire problem of who maintains AI agents, and documentation doesn't solve it: a person who was standing there while it was built does.
What this new title confirms
A market inventing a job title and standing up a business unit to hold it isn't a naming fad: it's the public admission that software alone doesn't get implanted. If the maker of the model needs a hundred and fifty people embedded in its customers for its product to perform, the question for your AI vendor stops being which model they use and becomes who sits with you, and until when.
We've run that model from the start, without the title: AI employees that deliver a working process, with an internal owner and with the metric written down before we start. If you want the vocabulary in order before that conversation, it's in the AI Operations glossary. AI doesn't pitch. It ships —and somebody has to be there the day it breaks.