← All essays·August 4, 2026·7 min read
Forward deployed engineering is a bet on the adoption gap
The forward deployed engineer is the fastest-growing title in enterprise AI, and most of the coverage argues about what to call it. Here is the informed version instead: why the role is emerging now, the one condition where it actually fits, what the work is when it does, and the single thing that survives every rename. The short answer is that adoption, not intelligence, is the 2026 bottleneck, and this is the role that closes it.
Listen to this page
The forward deployed engineer is the fastest-growing title in enterprise AI. There are over a hundred YC startups hiring for it, up from roughly zero three years ago, and most of the coverage spends its energy arguing about what to call it. That is the least useful question you can ask. Here is the informed version instead: why the role is emerging now, the one condition where it actually fits, what the work is when it does, and the single thing that survives every rename.
The frame that makes it make sense is a profit-pool argument I keep coming back to: when a capability commoditizes, the margin does not vanish, it slides to the adjacent layer that stays scarce. Every company can now rent the same frontier model, so intelligence is no longer the edge. The scarce layer is adoption, the work of turning a general model into one business's working system, and the forward deployed engineer is the person who does it. That is why deployment is the moat, and it is the whole reason the role exists.
Why the role is emerging now
Every operator who has actually run this function lands in the same place from a different direction. Bob McGrew, who ran product and engineering at Palantir while the model was invented and later led research at OpenAI, frames it as a market condition: AI agents have no incumbent product to copy, so no one yet knows what to build, and the only place to find out is inside the enterprise. Colin Jarvis, who runs the function at OpenAI, frames it as a trust problem: on the Morgan Stanley deployment the technical build took six to eight weeks and earning enough trust to change how advisors worked took another four months. Kevin Bai, who built forward deployed functions at Palantir and Rippling, frames it as a fit problem: you only need it when the product is too technical for the buyer to operate. Three angles, one underlying fact. The models can already do far more than any enterprise has actually put to work, and that gap, not raw capability, is the binding constraint of this cycle.
Put simply: the role appeared now because AI capability sprinted ahead of adoption. Renting a frontier model is easy and universal; turning it into a working system inside a messy enterprise is neither, and that gap is where the money and the work are.
Where and when it actually fits
The role is not for everyone selling AI, and the operators are unusually precise about the boundary. Bai draws it on two questions: how technical is what you sell, and can the buyer operate it themselves. You need a forward deployed engineer in exactly one cell. If you sell something simple, the buyer just configures it and you are a normal software company, the way Slack and Jira are. If you sell something deeply technical to a technical buyer, the users absorb the complexity themselves, the way GitHub and Datadog let them. It is only when you sell something deeply technical to a buyer who cannot operate it, the Palantir case, that someone has to go into the field and make it work. That someone is the forward deployed engineer, and outside that cell the role is a solution looking for a problem.
Put simply: you need a forward deployed engineer only when what you sell is too technical for the person buying it to run themselves. Sell a simple tool, or sell to engineers who can absorb the complexity, and you do not. It is one cell of the grid, not a strategy for every AI company.
What the work actually is
When the fit holds, the work is remarkably consistent across the operators, and it is the part worth keeping. You are not selling software, you are selling an outcome, the fact that a problem got solved. You go deep on one customer and carry back a reusable primitive rather than a bespoke build, which is how, in Jarvis's account, a Klarna engagement became Swarm, became the Agents SDK, became AgentKit. You build on a platform, not from scratch, or, as McGrew puts it, you have a dev shop whose maintenance bill compounds until it kills you. And the honest tell that you are running a software business and not a consultancy is the margin curve on a single customer: it starts negative, because you need a large team on site, and crosses into the black as the product absorbs what you learned and you earn harder problems. Consulting never makes that crossing.
Put simply: the work is a concrete software playbook, sell the outcome, carry back a reusable primitive, and build on a platform. The tell that it worked is the single-customer margin curve crossing from red into the black, which a consulting business never does.
The one thing that never changes
The title will change again. It has been the sales engineer and the solutions architect; it is the forward deployed engineer now; in a few years it will be the AI architect or something not yet coined. Natalie Meurer, a Palantir forward deployed engineer from the origin years, makes the sharpest version of the point: strip away every skill and every rename and one thing has always been constant, across DevOps and integration and enablement and agents. You are accountable for whether the customer's outcome actually happens. That is the invariant. It is what the role has always been under every name, and it is the thing worth building a career on, precisely because it outlives the label.
Put simply: do not attach yourself to the title, attach yourself to the invariant. Own whether the customer actually succeeds. That is what survives every rename, and it is the whole job.
What to do about it
So the informed take, in one breath: the forward deployed engineer is the person who closes the gap between what AI can do and what a specific business has actually adopted. The role is emerging because that gap, not raw capability, is the binding constraint of this cycle. It fits exactly one case, a technical product sold to a buyer who cannot operate it. The work is a real software playbook, not a consulting engagement, and it lives or dies on whether it generalizes into a platform. And underneath every future rename sits one constant: accountability for the customer's outcome. Build the capability to do that, understand a real business problem, turn it into a working system, deploy it into the mess, and own the result, and you are valuable in this cycle no matter what the job board calls it next quarter.
Put simply: adoption is the bottleneck, closing it is the job, the fit is narrow, and owning the outcome is the invariant. That is the role, minus the argument about what to call it.
The show notes behind this
This take is grounded in seven source writeups, the operators who built the function and the skeptics who pressure-tested it. If you want the raw material:
Malcolm Angus
I build 0 to 1 data products: I turn the data a company already has into a decision it wouldn't otherwise make, shipped end to end. I also write about how markets really work, moats, flywheels, and the loops that make companies harder to catch.
The charts in this essay are free to reuse with credit.