The Forward Deployed Engineer, Explained: The Role Quietly Reshaping Enterprise AI
While most of the enterprise AI conversation was still about benchmarks and model releases, OpenAI and Anthropic put $5.5 billion behind a job title that did not exist in most companies a year ago.
Last week, while most of the enterprise AI conversation was still about benchmarks and model releases, OpenAI and Anthropic together put $5.5 billion behind a job title that did not exist in most companies a year ago.
On May 11, OpenAI announced the OpenAI Deployment Company, a joint venture with TPG, Goldman Sachs, Bain Capital, McKinsey, and a list of fifteen other partners. The vehicle starts with $4 billion in committed capital. The first move was an acquisition: Tomoro, an applied AI consulting firm, with roughly 150 Forward Deployed Engineers and Deployment Specialists who join the new entity on day one. A few days earlier, Anthropic announced a parallel venture with Blackstone and Hellman & Friedman, valued at $1.5 billion, structured around three founding investors of $300 million each.
Two AI labs. The same week. $5.5 billion. Both vehicles separate from the core licensing business. Both built around the same role.
The question worth asking is what those two companies have understood about their own product that justifies five and a half billion dollars in a unit that does not write models, train models, or sell model access.
The answer is that the model is not what creates value at the customer. The model is the easy part. What creates value is the person who sits next to the customer and turns the model into something that runs.
That person now has a name. It is the Forward Deployed Engineer.
Two AI labs spent $5.5 billion last week on a job title Palantir coined in 2010. They did it because the model is the easy part. The hard part is the person who turns it into something that runs at the customer.
The role is not new. Palantir invented it more than fifteen years ago, internally calling it “Delta” in the company’s NATO-alphabet convention for teams. Until recently, it was a curiosity outside Palantir. In 2026, it has become the bottleneck of enterprise AI.
This post is about why.
A quadrant no one was occupying
I want to lay out the model the way it now sits in my head, after months of watching this role appear in conversations and a week ago, in San Francisco at Propel26, listening to a session on the topic by Kevin Bai, founding FDE at Rippling.
The model is a 2x2. One axis is product complexity, from simple to technical-deep. The other is buyer profile, from technical to non-technical.
The matrix has four quadrants. Three of them have well-known answers.
A technical buyer buying a simple product is self-serve. They read the docs, they implement, they move on.
A technical buyer buying a deep technical product is standard engineering. Both sides speak the same language. APIs, documentation, and support are enough.
A non-technical buyer buying a simple product is classical Professional Services. There is a known playbook: configure, train, hand off. Workday, SAP, Salesforce CRM, generations of enterprise software have lived in this quadrant and built the consultancy industry around it.
The fourth quadrant is the one that was empty until recently. A non-technical buyer trying to acquire a technical-deep product. The buyer cannot self-implement. The playbook does not exist because the product is too new and too custom. Standard engineering does not apply because the buyer cannot specify what they want. Professional Services does not apply because there is nothing to configure yet.
This quadrant has no native model of delivery. And this quadrant, in 2026, is exactly where enterprise AI lives.
The Forward Deployed Engineer is the role that fills it.
The buyer is genuinely non-technical, and there is now data
The framing “non-technical buyer” can sound like rhetorical convenience. It is not. The numbers are unambiguous.
According to a Stanford and MIT survey of 6,000 senior executives across four countries, nearly 70% of CEOs, CFOs and senior executives use AI at work less than an hour a week. 28% never use it at all. These are the same people who are mandating AI adoption to their employees and signing the contracts for enterprise AI deployments.
A separate Foundry 2026 State of the CIO survey finds that 40% of IT leaders cite “lack of in-house talent” as their top challenge in executing AI strategy. The Deloitte 2026 Global Technology Leadership Study, surveying 660 senior IT executives, reports that 81% of CIOs declare confidence in deploying and governing AI, but 75% of the same respondents say “operating models must change in the next 12 to 18 months.” Confidence is performative. Readiness is not.
The bottom-line picture is that the person signing the AI contract personally cannot specify the system they are buying. The person inside the organization who would normally translate the contract into reality does not exist or is overwhelmed. And the system being purchased changes faster than any procurement cycle that the buyer has ever managed.
This is the structural condition of enterprise AI in 2026. Almost every other category of enterprise software, at the same stage of adoption, had a higher buyer fluency. The buyer of an early CRM understood sales. The buyer of an early ERP understood finance. The buyer of an early data warehouse understood reporting. The buyer of an early agentic system does not understand agents, retrieval, evals, or guardrails. They understand they need outcomes.
The CEO who signs the AI contract uses AI less than one hour a week. The CIO who owns delivery says they have no in-house talent. The system is changing faster than they can specify it.
This is the gap no one was occupying.
The four roles that should have covered this gap, and did not
The deeper structural question is why this quadrant has been empty for so long. The enterprise software ecosystem has four well-established roles that, on paper, should each be candidates to fill it. None of them does.
Internal teams avoid ambiguous work. This is rational. Internal engineers are measured on shipping features that scale. Bespoke work for one customer of their own employer rarely shows up well in performance reviews. So they avoid it.
Consultants advise but do not build. The classic Big Four or Big Three model produces strategy, target operating models, transformation roadmaps. None of these is a running agent. The deliverable is a deck. The deck might be useful. It does not encode a process into software.
Product teams at the vendor will not prioritize one-off needs. The economics of product engineering require that every line of code shipped serves more than one customer. A capability that only one customer needs is a tax on every other customer’s roadmap. So product teams say no, and they are right to say no.
Solutions engineers configure but do not create. They wire up integrations, set parameters, run demos. They are trained to operate within what the product already does. When the customer needs something the product does not yet do, the Solutions Engineer files a feature request and goes back to the next demo.
The Forward Deployed Engineer is defined by what they are not as much as by what they are. The contrast is sharp enough that it deserves to be made explicit, because the word is already being abused in the market.
An FDE is NOT running demos.Writing tickets for someone else to build. Acting as a middleman between the customer and the product team.
An FDE IS discovering the real problem the customer is paying to solve. Building the solution end to end. Owning the outcome with the customer, not just the milestone in the project plan.
The distinction is not cosmetic. A vendor that calls a Solutions Engineer “Forward Deployed” without changing the underlying authority and accountability is selling you a relabel, not a different model.
The highest-ROI work in enterprise AI sits in the gaps between four roles, none of which has the right incentives to occupy it.
This is the underrated insight of the entire trend. The Forward Deployed Engineer is not a new function. It is the person who is willing to live in the structural blind spot of four older functions, and to take economic accountability for what happens there.
Three hats, one person, one customer
The mechanics of how the role works are unusual.
The Forward Deployed Engineer wears three hats at the same time, in front of the same customer. They are a consultant when they have to find the real problem inside an organization that has been told to “do AI” without specifics. They are a Product Manager when they have to decide what to build first, given that the customer cannot prioritize between three plausible candidates. They are a Software Engineer when they sit down to actually build and ship it. Most people in software can do one of these three things well, and a few can do two. The Forward Deployed Engineer does all three at once, in front of the same customer, in the same week.
The economic structure of the role is even more unusual. In a classical software delivery model, the work is fragmented across functions and accounts. A Project Manager coordinates a team of three to ten people. Each person on the team serves multiple customers in parallel. Value comes from a long planning cycle. Kickoff, requirements gathering, design phase, build phase, test phase, rollout. The model assumes that the building is the long part.
In the Forward Deployed model, none of that is true. One engineer, dedicated to one customer, sometimes full-time, sometimes part-time, builds and ships in weeks. There is no Project Manager. There is no Business Analyst. There is no separate design phase. The engineer sits inside the customer, understands the politics, picks a problem that matters, writes the code, deploys it, iterates with real users, and moves to the next problem.
This works because, with AI, the building is no longer the long part. A capable engineer with the right tools can stand up a working agent in days. What takes months is figuring out which agent to stand up. The political map of the customer. The decision rights. The data sources. The acceptable failure modes. The handoff to humans. None of these can be specified in a requirements document.
Joe Lonsdale, co-founder of Palantir, captured the asymmetry bluntly:
“A couple of FDEs performing in days what would otherwise require months of labor for hundreds of IT service professionals.”
The classical software delivery model exists because the original constraint was building. Now the constraint is understanding what to build. The model has to change.
The numbers behind the hiring trend reflect this shift. According to The Pragmatic Engineer, job postings for Forward Deployed Engineers on Indeed grew more than tenfold in 2025 compared with 2024. Public company earnings calls mentioning the role jumped from 8 to 50 in the same period. Bloomberry’s analysis of 1,000 FDE job postings found a median base salary of $173,816, with 70% of postings offering equity. Total compensation at top labs ranges from $350,000 to $550,000 for mid-to-senior roles, with staff-level FDEs at Palantir clearing $630,000.
The role is the highest-paid customer-facing role in software today.
What an FDE actually does (and when)
Three hats is the profile. What does the role do in practice?
Forward Deployed Engineers build three distinct kinds of things, and the difference is worth understanding because it changes what you should expect from one.
The first is analytical work. The FDE walks into a customer that is sitting on data across half a dozen disconnected systems, and turns that data into reporting that someone in operations can actually act on. Salesforce numbers in one place, support tickets in another, a finance system that nobody fully trusts, exports from an industrial sensor. The FDE unifies them and builds the layer that turns raw data into an answer to a real question. It is not a dashboard project. It is the resolution of an organizational blind spot.
The second is operational work. The FDE encodes a business process that today lives in someone’s head, or in a fragile Excel file, into working software. This is exactly the Operational AI territory I described last week, and it is where most of the enterprise AI value lives. A monthly business review that today takes twenty hours of someone’s time becomes a workflow the agent runs every first of the month. A customer onboarding process that requires four handoffs across three teams becomes a deterministic pipeline. The output is not a deliverable, it is a system that runs.
The third, and most valuable, is hybrid work. Analytical understanding combined with process automation. The agent that reads the data, draws the inference, takes the action, and reports back. This is where the FDE earns the salary. It is also the work that no other role in the enterprise software ecosystem is structured to produce.
A concrete example of how this looks in practice comes from a recent piece by Gergely Orosz on the FDE function inside OpenAI. The team’s Head of Forward Deployed Engineering, Colin Jarvis, took an FDE to a farm in Iowa to work directly with farmers on a project for John Deere. The previous process involved John Deere making manual phone calls to farmers, one at a time, to advise them on weed control. The customer wanted to scale that advice into personalized insights that maximized the use of a new low-pesticide control technology, in time for the next growing season.
The FDE didn’t write a strategy document. They sat in the field, mapped the workflow, built the system, deployed it, and got it live before crop planting. And in the process, the work fed back into OpenAI’s Realtime API, which improved the product for every other customer. One customer paid for the deployment. Every customer benefited from what was learned.
This is the loop that makes the role economically defensible: the FDE is dedicated to one customer, but the lessons travel back to the product. Palantir captured this asymmetry in their own description of how the role differs from a regular product engineer:
“A Dev’s focus is one capability, many customers. A Delta’s focus is one customer, many capabilities.”
The Dev optimizes a single capability across every customer that buys the product. The FDE (originally called “Delta” at Palantir) does the opposite: many capabilities, one customer. The system works when those many capabilities, over time, become reusable patterns that flow back into the Dev side of the company. Without that feedback loop, the FDE is a high-paid consultant. With it, the FDE is the bridge between the customer’s reality and the product roadmap.
The role also has a clear lifecycle inside a customer relationship. The FDE is not just a delivery engineer who shows up after a deal closes. They are present before, during, and after.
Before the deal closes, the FDE joins pre-sales conversations. They help the customer define what is actually possible. They scope the engagement and remove the surprises that would normally surface only after the contract is signed. This alone is a competitive advantage: a vendor who can put a real builder in the room during evaluation closes deals that competitors lose to “we’ll have to check with engineering.”
During the deal, the FDE owns the work from discovery to delivery. They co-build with the customer, ship working systems, and stay accountable for the outcome that was promised at the start.
After go-live, the FDE doesn’t disappear. They identify expansion opportunities inside the same account, feed observed patterns back to the core product, and drive long-term stickiness by keeping the deployment evolving with the customer’s reality. Inside OpenAI, this loop is formalized: bi-weekly knowledge sharing with the Research team, fortnightly readouts with the Head of Product, an internal “FDE Field notes” Slack channel that every FDE contributes to. The role does not just generate revenue. It generates intelligence.
A Palantir job ad describes the seniority required to do all of this with a phrase worth memorizing:
“FDE responsibilities look similar to those of a startup CTO: small teams, end-to-end execution of high-stakes projects.”
This is not an entry-level role. The compensation reflects it. The shortage of qualified candidates does too.
The dependency the buyer is now paying for
Six weeks ago, CIO Magazine published an article with a headline that, on its own, captures the shift. The title was “Anthropic’s financial agents expose forward-deployed engineers as new AI limiting factor.”
The piece’s core observation:
“Enterprise CIOs are increasingly paying for the services of AI vendors’ FDEs, given their own data quality issues and the complexity of working with AI models.”
The wording matters. The FDE has stopped being a hidden cost absorbed into the license. It has become a line item. The customer knows they are paying for the engineer. The vendor knows they are charging for the engineer. The relationship is now a hybrid of software license and services, in which the services portion has stopped being marginal.
This is what OpenAI and Anthropic just made explicit with $5.5 billion. The Deployment Company is not a Professional Services arm. It is a separate vehicle, co-financed with consulting firms and private equity, designed to scale a role that does not fit inside the original margin structure of an AI lab. The signal is unambiguous: model access does not create enterprise value by itself, and the labs are now willing to acknowledge that publicly, with capital.
The doubt that has to be in this article
It would be dishonest to write about the Forward Deployed Engineer in 2026 without including the most serious public critique of the role.
Flybridge, the venture firm, published an article titled “Why 95% of Startups Get the Forward Deployed Engineer Role Completely Wrong.” The argument is precise. Most startups hire FDEs as a crutch for weak product-market fit, fragile platforms, or low-value deployments. Two failure modes, both quantitative:
“Fully loaded, an FDE hire often runs $220k to $400k per year. If that person spends most of their time on sub-$100k accounts, the unit economics collapse almost immediately.”
And:
“Don’t forward deploy for sub-$1M ACV deals unless it is an investment which credibly leads to $1M+ outcome.”
The pattern of failure that Flybridge describes is real. An expensive engineer, deployed to small accounts, builds brittle bespoke systems. The bespoke systems do not generalize. The vendor accumulates technical debt. The customer gets a working pilot that no one can extend. The vendor drifts from a software business into a services business with worse margins than a consulting firm.
And when you simply don’t need one
The buyer side of this problem mirrors the vendor side. Not every deployment benefits from a Forward Deployed Engineer, and asking for one when the situation does not require it is its own kind of mistake. Three patterns identify the cases in which a different role is the right answer.
If what you need is a well-defined feature request, the right team to talk to is the vendor’s product team. A feature request is by definition a piece of work that has been specified, prioritized, and scheduled. It is not the work of discovery. It is the work of execution against a known scope, and the product team is the function that is structured to deliver it.
If what you need is pure implementation work, where the playbook already exists and the variables are known, the right team is classical Professional Services. Configuring a CRM, integrating a known data source, training users on a feature the product already supports. None of this requires a builder. It requires a configurer. The unit economics of a Professional Services engagement assume a known playbook, which is why they work at lower ACVs.
If what you need is a long-term scalable system that will be reused across many customers in the same vertical, the right team is the vendor’s engineering function. Bespoke deployment by an FDE is the opposite of what you want here. You want code that ships into the platform and serves the entire customer base for the next five years.
There is a fourth distinction worth understanding, because it cuts deeper into the AI vendor landscape. Both OpenAI and Anthropic now run a Solutions Architect function alongside their Forward Deployed Engineering function. Orosz describes the difference precisely: the Solutions Architect is advisory. They rarely write code on the customer’s infrastructure. They build minimum viable products or proofs of concept, often on anonymized or synthetic data. The Forward Deployed Engineer is hands-on. They write code on the customer’s actual infrastructure, with the customer’s actual data, in production.
If your goal is to evaluate whether an AI vendor’s product can solve your problem at all, a Solutions Architect is enough. If your goal is to actually solve the problem in production, you need an FDE. Confusing the two is one of the most expensive misallocations of enterprise AI budget in 2026, and it is happening at scale.
a16z made the same point in a piece titled “The Palantirization of Everything”:
“Companies that over-rotate into forward deployment without a strong product spine may fail to generate increasing returns to scale and durable moats.”
Both warnings are correct. The Forward Deployed Engineer is not a universal model. It is a structural answer to a specific quadrant. It works when two conditions hold: the underlying product has a real spine that the bespoke deployments feed into, and the bespoke deployments have an explicit feedback loop back to the product roadmap.
Palantir’s “Foundry moment” in 2016 is the canonical example. Until 2016, Palantir had more “Delta” engineers, the original name for FDEs, than “Dev” engineers, the ones building product. With Foundry, the company crossed the inflection point. The lessons from years of forward deployment crystallized into a product platform. The bespoke work became reusable. The role inverted from majority to minority of headcount.
Without that inflection, an FDE-heavy organization is a consultancy with software pretensions. With it, it is the most defensible kind of platform business. ServiceNow currently runs a 79% gross margin. Workday 75%. Both companies got there by absorbing what their early forward-deployed engineers learned.
The doubt is not whether the role exists. It is whether each individual organization adopting it has the spine and the feedback loop to make it scale.
What this means for the buyer, not the vendor
Most coverage of the Forward Deployed Engineer is written for vendors deciding whether to build a team. The more useful question, for the reader of this newsletter, is what it means for the buyer.
If you are a non-technical executive responsible for deploying AI in your organization in the next twelve months, three diagnostic questions are worth running with your vendor.
1. Who is sitting on the other side of the table?
If the person you talk to is a Solutions Engineer who can demo the product but who cannot build a missing capability, you are in the classical Professional Services quadrant of the matrix. That may be enough if your problem is well-scoped and the product already covers it. It is not enough if your problem requires translation from business intent into working software. The signal to watch for: when you describe a specific edge case, does the person across the table take notes for a feature request, or do they reach for a laptop?
2. Does your vendor have an FDE function, or a Professional Services function?
The two words are increasingly used interchangeably, and they should not be. A Professional Services team configures within what the product already does. A Forward Deployed Engineer is allowed to build what the product cannot yet do, and to push that capability back into the product roadmap. The first is implementation. The second is co-creation. Ask explicitly: “Does the person you would assign to my deployment have authority to write code that ships into your platform?” The answer separates the two functions instantly.
3. What are you actually paying for?
If your contract is structured as license plus hourly services, you are still buying the old model. If your contract is structured around an outcome, with embedded engineers absorbed into the price, the vendor has accepted delivery accountability in a way they would not have a year ago. The asymmetry of who bears delivery risk is the cleanest signal of where in the matrix your deal actually sits. License-plus-hours puts the risk on you. Outcome-with-embedded-engineers puts it on them.
These three questions will not answer themselves through marketing material. They will answer themselves through the structure of the conversation, the people the vendor brings into the room, and the way the contract is written. The Forward Deployed Engineer is not, fundamentally, a hiring trend. It is the cleanest available test of whether a vendor is selling you software, or whether they are selling you something that will actually run inside your organization.
What to take home
If you read only one section of this piece, read this one.
The market signal of the past two weeks is visible. OpenAI put $4 billion into a Deployment Company. Anthropic put $1.5 billion into a parallel venture. Salesforce is hiring 1,000 new graduates explicitly into Forward Deployed roles. Indeed job postings are up tenfold year over year. The role has crossed from Palantir curiosity to enterprise category in under twenty-four months.
The structural reason is not better models. Models will keep getting better, and the better they get, the more obvious it becomes that the bottleneck has moved.
The bottleneck is the translation between a non-technical buyer with a real problem and a deeply technical product that has the latent capability to solve it. That translation cannot be done by a deck. It cannot be done by an internal team that has no incentive to take on ambiguous work. It cannot be done by a Solutions Engineer who is trained only to configure what already exists. It can only be done by a person who sits inside the customer, owns the outcome, and writes the code.
Kevin Bai, when I heard him speak last week, said it bluntly:
“The future isn’t just better models. It’s better deployment. And FDEs are how you get there.”
The future of enterprise AI in 2026 is not who has the best model. It is who can sit next to the customer and turn the model into something that runs. The bottleneck has moved, the labs have admitted it with $5.5 billion of capital, and the role that fills the gap has finally been named.
The empty quadrant has its native species.