A Forward Deployed Engineer is an engineer who embeds with the client, understands how the work really gets done, and turns that understanding into working software. The role was born at Palantir. Artificial intelligence has just made it one of the most sought-after jobs in the industry.
The reason fits in one sentence. Intelligence has become a commodity, knowing where to put it inside a company has not. Tandem does this job every day, and this article describes what it covers, the three steps it breaks down into, and a four-week roadmap to learn it.
Why intelligence can no longer be a competitive advantage
Everyone has access to the same frontier models, on the same day, at the same price. A capability your competitor can buy this afternoon does not create a durable advantage. Raw intelligence has become a commodity, in the strict sense of the word.
So the advantage has moved elsewhere. It plays out in the where, the how and the why. Which precise process you inject that intelligence into, and with what guarantees. Two companies can run exactly the same models and get returns that bear no resemblance to each other. The difference is not the model.
The figure documenting that gap is well known. The report “The GenAI Divide: State of AI in Business 2025”, published in July 2025 by MIT's Project NANDA, measures that 95 % of enterprise generative AI projects produce no measurable return. The study rests on 150 executive interviews, 350 employee surveys and an analysis of 300 public deployments. Its diagnosis is organisational, not technological.
We covered that gap from the return-on-investment angle in our article on companies that see no ROI on AI. This article takes the other end of the problem, the job that moves a project from the wrong side of that statistic to the right one.
What is a Forward Deployed Engineer?
Someone has to decide where intelligence belongs inside an organisation. That is the Forward Deployed Engineer, often shortened to FDE. Palantir invented the post to describe engineers sent directly to the client, tasked with solving that client's problem rather than building a generic feature.
The role demands two judgements that rarely coexist in the same person. Business judgement covers workflows, exceptions, costs, risk and adoption. Technical judgement covers models, APIs, data, reliability and what holds up in production. An FDE turns business understanding into software that works.
The market has already decided, and it put 4 billion dollars in
In May 2026, OpenAI launched a joint venture dedicated to deployment, the OpenAI Deployment Company, and acquired the consultancy Tomoro alongside it. The deal brings roughly 150 Forward Deployed Engineers and deployment specialists from day one. Initial capital exceeds 4 billion dollars, provided by a consortium of 19 investment firms, consultancies and system integrators led by TPG.
The intent is clear. This is not about selling more models, it is about going and installing them at customer sites. When the leading model vendor builds an entire structure for deployment, it is acknowledging that value no longer sits in the model alone.
Step 1, understand how the work really gets done
The documented process is almost never the real process. An email arrives, it is copied into a spreadsheet, checked in an internal tool, approved on a team messaging app, then re-entered into the ERP. Half the cases are exceptions, and their logic lives in one person's head.
That is why our AI audit starts in the field before costing anything. On a recent assignment in a network of health centres, several of the most expensive friction points appeared in no document. Two of them were solved by switching on features already present in the group's tools, without a line of code.
Step 2, decide where AI belongs and where it does not
On a ten-step workflow, two or three steps require judgement. The rest is settled with conditions and API calls. Whenever determinism is possible, use it, and reserve the language model for the judgement zones. That split is what separates a system that holds from a demo that impresses.
- Deterministic software when the rules are predictable. Cheaper, faster, testable, and it does not start improvising on a Monday morning.
- An agent when the goal is clear but the path varies. That is where the model adds something no written rule replaces.
- A human when the decision is irreversible. A refund, a cancellation or a coverage refusal is not delegated to a probabilistic system.
This reasoning overlaps the four levels of automation we detail in our articles on levels of automation and on the difference between agents and workflows. The most frequent mistake is jumping straight to the autonomous agent, when a configured assistant or a simple automation is enough in most cases.
Step 3, prove the system holds rather than promising it
As soon as there is judgement, there is non-determinism. Evals turn that non-determinism into proof. The principle is simple. You build a set of cases, you measure the success rate, and you sort the failures into categories.
- The normal case, the one the system will meet most often.
- The edge case, still within scope, but only just.
- Missing information, to check the system can say that it does not know.
- The ambiguous request, to check it asks for clarification instead of inventing.
- The risky action, to check it stops and hands over.
Colin Jarvis, head of forward deployed engineering at OpenAI, gives the sharpest illustration of this in his interview with Altimeter. On a deployment run at a wealth management firm, the main technical hurdle was cleared in six to eight weeks. It then took four more months of pilots, eval collection and iteration before advisers genuinely trusted the system. In the end, almost all of them adopted the tool.
The full loop, from audit to improvement
The three steps chain into a loop that never stops. Audit, build, evals, deployment, observation, improvement. Then the loop starts again, because a format changes, a product evolves and a model gets updated.
That is the logic Tandem applies on its assignments, and it is described step by step in our AI audit method. Diagnosing the real process always comes before a single line of code.
How to become a Forward Deployed Engineer in four weeks
The role is learnt by building, not by reading. Here is the roadmap I give to people who want to move into this job. It assumes you can code a little, and that you have a real process to automate, however small.
| Week | Goal | What must exist at the end |
|---|---|---|
| 1 | A loop that runs | An agent completing a real end-to-end workflow, two tools, guardrails, an audit log |
| 2 | A system that holds | Structured JSON outputs, schema validation, identified failure modes, restart from the last checkpoint |
| 3 | A measured cost | Retry with backoff, failure taxonomy, hand-annotated reference dataset, cost per request |
| 4 | A defensible system | The architecture, what v1 got wrong, the evals and the economics, explained to an engineer and to an executive alike |
Week four is the one that separates people. You must be able to explain the same system to an engineer and to a non-technical executive. The pain point, why AI belongs here, the architecture, what the first version got wrong, the evals, and what it costs. A candidate who can only defend the technical half is not yet an FDE.
Should you hire an in-house FDE or work with a partner?
Both work, and they serve different moments. An external partner brings the perspective of dozens of deployments and moves fast on the first use cases. An in-house FDE knows the company's own exceptions and holds the improvement loop over time.
The sequence that works is almost always the same. A partner scopes and ships the first two or three cases, training the person who will take the subject over along the way. Then the company brings it in-house. On an assignment at a digital health software vendor, the closing session was run by the internal team, and the support role was already internalised when Tandem left.
The counter-example to avoid is hiring a single FDE with no written process and no document foundation. They will spend their first six months doing archaeology rather than deployment. A clean document corpus conditions half the projects that follow.
Where to start if you want to deploy AI seriously?
Start with the real process, not with the model. Sit for a day next to the team doing the work, and write down what you see. That is the starting point of the carousel I published on the job of deploying AI, and it is also the starting point of every one of our assignments.
Then draw the line between what belongs to determinism and what belongs to judgement. Then build the evals before promising anything. Those three moves are enough to escape the 95 % of projects with no measurable return, and none of the three depends on the model you picked.
One last thing. If your system cannot say that it is unsure, it is not ready to touch a production process.
