The most important enterprise AI job right now may be the one that looks least like a normal software job.
A Forward Deployed Engineer is an engineer who leaves the clean center of the product org and works inside the customer’s operating reality. They sit with the team that owns the workflow, trace the approvals and exceptions across email, SaaS tools, spreadsheets, internal systems, and the person who still knows why the odd case exists, then write the code, evals, integrations, and guardrails that make an AI system useful in that environment.
The role has suddenly become interesting because the model is no longer the scarce input. The scarce input is knowing where to put the model, what context it needs, what it should be allowed to do, and how to prove to a skeptical business owner that it is safe enough to trust with work that matters.
a16z called the broader company pattern the Palantirization of everything: founders pitching themselves as Palantir for a vertical, embedding engineers with customers, building custom workflows, and using high-touch deployment to land large enterprise contracts. The phrase works because Palantir is the origin story: in 2010, Palantir engineers embedded with US Special Forces in Afghanistan, soldiers came back from missions with feedback, and engineers changed the software against what the soldiers had just run into.
The same model is now showing up in AI companies. The Pragmatic Engineer’s deep dive traces the modern FDE role back to Palantir’s Deltas, notes that Palantir had more FDEs than regular software engineers until around 2016, and reports that OpenAI built an FDE team that grew from two people to more than ten across eight cities and three continents. Pave’s market data keeps the hype in check: as of September 2025, only 1.24 percent of roughly 9,000 companies in its dataset had an FDE or similar title. The job is still rare, but the companies closest to frontier AI are hiring for it early.
Why now?
Enterprise AI has moved from a capability problem to a deployment problem.
Why the role appeared now
For the last few years, the market’s attention went to the models. Could they reason better, write code, hold longer context, call tools, use a computer, or stop hallucinating quite as often. That made sense when the models were changing visibly every few months and most enterprise use cases were still demos.
Now the market is in a different place: a capable model is one API call away for almost every company, and the delta between “impressive demo” and “trusted production system” has become the hard part. Sierra’s write-up on agent engineers describes the gap cleanly: an engineer can build a demo in an hour, but making agents operate consistently across millions of conversations is much harder. That sentence is more or less the FDE job description.
In the pitch meeting, the demo usually looks clean: a model reads a document, answers a question, drafts a response, or completes a workflow while the buyer watches. The demo is usually the happy path: clean data, known permissions, and no argument yet about who owns the risk when the agent is wrong. The buyer leaves thinking one workflow can be automated, and then the implementation has to work inside the company’s actual systems.
The hard parts are usually the parts the demo did not need to handle: customer-specific permissions, stale records, undocumented exceptions, handoffs between systems with different owners, and the simple question of who gets to approve an automated decision when the model is confident and the business is still exposed. The data lives in five systems, and the rules are part policy, part exception, part “ask the person who has handled this customer since 2021.” The version described in procurement is often cleaner than the version operators actually run. The agent works on the first ten cases and then fails on the eleventh in a way that looks small to the vendor and serious to the customer.
That gap is where FDEs come in. They are the bridge between model capability and business adoption, and the bridge has to be technical because the problem is not only discovery. It is also data access, permissions, evals, latency, cost, logs, tool calls, rollback, and the long tail of systems a real company already bought years ago.
This is also why the role sits close to the emerging vertical AI moat. In Joe Schmidt’s “Rest of Oz” framing inside the vault, vertical AI companies become durable when they own the system of work: operational memory, model routing, governance, and the loop between action and feedback. The FDE is one way that ownership gets created. They go into the customer’s workflow and make the unwritten part legible enough for software to act on it.
The Pragmatic Engineer piece frames the Palantir split as Dev versus Delta. Dev builds reusable product capability for many customers. Delta, the ancestor of the modern FDE, starts inside one customer’s reality and builds the capability that account needs, ideally in a way the platform can absorb later. That matters.
That is the founder case for FDEs. If every competitor can access the same model, the company that understands the workflow better can still win. But that advantage has to turn into reusable product over time. Otherwise the company is simply putting engineers on planes and calling it software, especially in enterprise accounts where every custom deployment leaves behind another thing that has to be explained, maintained, renewed, and owned.
The work is audit, evals, and deployment
The cleanest operating model I found comes from Vas’s public FDE guide, which breaks the job into three phases: audit, evals, and deployment. Read it as an operator’s playbook rather than neutral market data, since Vas runs a company selling this kind of work. Even with that caveat, the shape is useful because it describes what happens between the first demo and the first production workflow.
The audit is where the FDE learns the business as it runs, not as the org chart says it runs. They sit with rev ops, procurement, finance, support, or whichever team owns the workflow. The goal is to find the places where AI creates enough value to justify the cost of deployment, and the discipline is knowing when AI should be left out.
Some work should become an agent when the inputs vary, the rules are stable enough, and the work involves calling tools or moving across systems. A procurement request that arrives as an email, a PDF, a form entry, or a scanned quote may fit this pattern if the approval logic is knowable.
Some work should stay deterministic code when the inputs are predictable, the rules are predictable, and a normal program will be cheaper, faster, and easier to verify than an LLM. A lot of “AI transformation” work quietly becomes good integration engineering once someone looks closely.
Some work should stay human, at least for now, when the task requires taste, judgment, negotiation, or domain pattern recognition that nobody can specify cleanly enough. Saying this plainly is part of how an FDE earns trust. The customer learns that the engineer is not trying to pour a model over every workflow just because the model is available.
The eval phase is where the system earns the right to move from promise to trust. In a normal software rollout, the buyer can often inspect the workflow directly. In an AI rollout, the buyer is being asked to trust a probabilistic system inside a process that may affect customers, money, compliance, or employee decisions. A demo is not enough.
The FDE has to build a golden set with the domain expert. That means taking real historical cases, writing down what good looks like, and grading the agent against intermediate checkpoints rather than only the final answer. If the agent reaches the right refund decision for the wrong reason, or picks the right customer response after reading the wrong policy, that is still a deployment risk. The eval has to catch the mistake before the customer does.
This is where the role becomes more than technical consulting, because the FDE is turning tacit knowledge into a measurable artifact. The expert who has carried the workflow in their head now has to make judgment explicit: which facts matter, which exceptions override the normal rule, which errors are tolerable, which ones are not. That eval set becomes the first version of the company’s machine-readable operating memory.
Deployment is mostly about restraint. The tempting version is to clean everything up first: migrate the data, redesign the process, rebuild the permissions model, and install the perfect system. That is how AI projects become multi-year transformation decks.
The FDE version is thinner and more practical: build APIs over the data where it already lives, put the model over the existing systems as an orchestrator, and start in a sandbox inside the customer’s infrastructure. Give the agent the smallest unit of autonomy: read, summarize, flag, draft, recommend. Only after that works repeatedly should it write, approve, push, or transact.
The best version of this loop has a product feedback path. Palantir’s Delta learns what one customer needs and feeds that back into the platform. OpenAI’s FDE work, according to the Pragmatic Engineer piece, also connects customer deployments back to product and research work. That loop is the difference between forward deployment as scaffolding and forward deployment as the business itself.
The question is what compounds after the engineer leaves
The strongest case against FDEs is the one a16z raises in its Palantirization essay: the model can degrade into consulting disguised as software. It is an uncomfortable objection because it is probably true for a lot of companies copying the shape.
Software businesses compound because the next customer should become cheaper to serve: the product absorbs repeated work, the documentation improves, the implementation path shortens, and the margins get better. An FDE-heavy company can go the other way if every customer creates a custom deployment that only the assigned engineer understands. Revenue grows, but so does the human work required to keep it alive.
The mistake is copying the embedded engineer without copying the platform spine. Palantir worked because the field teams had Foundry, Gotham, Apollo, Ontology, and later AIP underneath them. The FDE could customize, but the customization sat on opinionated primitives. A startup that sends smart engineers into every account without a reusable product boundary is building a services firm with software language around it.
The work has to leave behind something the next account can use: a connector, an eval pattern, a permissions primitive, a workflow object, a data model, a sales proof point, or a clearer boundary between what the platform handles and what remains customer-specific, because without that residue every new deployment starts from zero again.
That does not make the role a fad, but it does make it a pressure test.
For founders, the question is whether forward deployment is discovering reusable primitives or hiding missing product. After each customer, what becomes easier for the next one? Which customer-specific workflow turned into a configuration option, an eval suite, a permissioning pattern, a connector, or a reusable object model? Where does the shared product end and customer-specific code begin? If that boundary is not moving in the right direction, the company is accumulating obligations rather than product.
For operators buying AI, the question is what you own after the engagement. A successful deployment should leave behind more than an agent. It should leave behind a living context layer: documented workflows, eval sets your own experts trust, logs, ownership paths, governance rules, and internal people who know how to maintain the system when the business changes. If the FDE leaves and only the vendor understands the logic, you bought dependency.
For engineers considering the role, the question is whether the work sounds energizing after the glamour is stripped out. The job rewards range. You need to write production code, read a room, talk to a product head in business language, sit with a domain expert long enough to build a useful eval set, and explain why the agent should not be allowed to take an action yet. A lot of the hard moments are human and institutional. The code matters because it is the medium, but the job is getting the organization to trust a new way of doing work.
This is also why the supply will stay thin for a while. The person who can write code in an unfamiliar environment, map a workflow accurately, explain risk without hiding behind jargon, and turn one customer’s mess into product learning is rare. You can rename solution engineers as FDEs, and many companies will, but the title will not create the operating muscle.
My read is that FDEs are transitional in one sense and durable in another. Some of the current work will get easier as tooling improves. Agent builders will get better, eval tooling will become more standard, integrations will be less painful, and customers will learn what good deployment looks like. The specific role may normalize into product engineering, solutions architecture, customer engineering, or something with a less fashionable title.
But the underlying function is not going away. Companies still need someone to turn messy operating reality into systems that machines can act on. As long as the valuable work lives in undocumented exceptions, half-adopted tools, compliance constraints, and human judgment, the last mile of AI will need builders who can work inside the mess without mistaking the mess for the moat.
The simplest way to judge an FDE motion is to look six months after handover. Are the evals still current? Did the workflow documentation change when the business changed? Did the product team absorb what the field team learned? Did the next deployment get faster because of this one?
If the answer is yes, forward deployment was the way the company learned. If the answer is no, it was expensive implementation work with better branding.