Part 6 of 8 in The Last Mile of Enterprise AI. Last week: custom experts, a mixture of experts for your own business.
The previous five posts described work. This one is about who does it, and the industry has settled on a name for them.
What an FDE is
One consultancy's definition: forward deployed engineering is a delivery model in which engineers work embedded in a client's business instead of at a distance from it. The engineer learns the customer's process first-hand, builds against real data, and owns whether the thing works in production. Palantir built its business on the model. In 2026 it became the default way to sell enterprise AI.
The scale of the shift
- OpenAI launched a dedicated deployment company in May 2026 with more than $4 billion in backing and acquired a consultancy with about 150 such engineers.
- Amazon announced a billion-dollar investment in a forward deployed engineering organization.
When the largest AI firms spend billions on people whose job is to sit with customers, the technology is clearly not the bottleneck.
Why the model exists
Enterprises get stuck in the same places. Camunda's 2026 study found only 11% of agent use cases reaching production in the prior year. Another survey put the median time from funding to production at 11.4 months.
The causes are ordinary: nobody owns the result end to end, the people who know the process cannot build and the builders do not know the process, good enough is undefined, security arrives late, and internal engineers are fully committed. One analyst adds that buyers of enterprise AI tend to be less fluent in the product than buyers of earlier software were. The embedded engineer fills that gap.
The limits of vendor FDEs
The model has two catches when it comes from a model company or a platform vendor. Their engineers are there to deploy that vendor's product, so the answer to which model? is settled before the question is asked. And they go where the largest contracts are. A mid-sized company with one painful workflow is not who a billion-dollar FDE organization is built for.
The independent pod
A small senior pod fills that space. It is forward deployed in the sense that matters: it owns one outcome, works inside the client's process, and stays until the workflow is in production. It is also neutral. It can use a frontier API, an open model on the client's hardware, or both, and switch when prices or models change.
A workable pod is a tech lead and two or three senior engineers, plus a counterpart on the client side with authority over the process. Without that person the pod is building in a vacuum.
Why senior
Agents amplify judgment more than they replace it. An Anthropic study of more than 1,000 agentic coding sessions measured a 31% higher verified success rate for senior engineers than for juniors, a gap that held after controlling for task difficulty. Insight Enterprises estimates about 30% time savings for its senior engineers against 12% to 15% for juniors.
The evidence is not uniform: a METR trial found experienced developers 19% slower with AI tools on mature codebases. The gains are strongest on new builds and well-scoped work, which describes most of what a deployment pod does.
Can it be done remotely?
Mostly yes, with some things done deliberately. Forward deployed has traditionally meant on site. What it requires in practice is closeness to the work, and most of that is now reachable from anywhere.
- The work is digital. Document workflows, the client's systems and the review queue are all accessed through a screen whether the engineer is in the building or not.
- Embedding is a matter of channels. A remote pod joins the client's chat workspace, attends its stand-ups, and has named counterparts. The test is whether a processor with a problem can reach an engineer the same day.
- Discovery can be recorded. Screen-shared walkthroughs of real cases, with the expert narrating, capture the process better than notes from a conference room, and they can be replayed.
- Time zones can help. One outsourcing firm reports that most of its clients find three to four hours of daily overlap sufficient. Beyond the overlap, a pod several time zones away can fix overnight what the client reported at the end of its day.
Where remote is weaker, and what to do about it
- Trust and discovery are slower at a distance. A short on-site kickoff, or a lead in the client's time zone who attends in person, covers most of this.
- Unwritten rules surface in hallway conversation. Remote teams have to ask for them explicitly and schedule time with the people who hold them.
- Some data cannot be accessed from abroad. Regulated data may have to stay in-country. The answer is architectural: the system runs on the client's infrastructure, and the pod works through controlled access or on synthetic and masked data.
Stated plainly to a buyer: a remote forward deployed pod gives up some of the informal contact an on-site team gets, and in exchange costs far less and can start next week.
Questions for any FDE team, remote or not
Show me the eval suite and review tooling from a past project. Who is my named lead, and how many hours a day do we overlap? What do we own if we part ways? A team that cannot answer the first is selling prompts.
Next week: The economics: why three engineers can now do the work of a department.