What is a forward deployed engineer? A buyer's definition

Forward deployed describes where the work happens and who owns the outcome, not how senior the person is.

Day to day, a forward deployed engineer sits close to the people who will use the thing, learns a domain that is not their own, and writes code in the client's repositories against the client's data. A product engineer optimizes for generality, because their code has to serve every customer. A forward deployed engineer optimizes for specificity: this company's data model, its exceptions, the spreadsheet that quietly runs the finance team, the integration nobody documented.

The role is a hybrid, and all three parts have to be present. Enough product judgment to decide what is worth building, enough engineering to build it to production standard, and enough customer-facing ability to run the conversation without a translation layer in the middle. Remove any one of the three and the role collapses back into something more familiar: a solutions architect who cannot ship, a contractor who cannot scope, or a sales engineer who demos rather than deploys.

Two things separate it from consulting. The deliverable is running software rather than a recommendation, and the feedback loop runs in both directions: what the engineer learns in the field is supposed to change what gets built next. Palantir made that loop explicit in how it describes the role, and OpenAI's own forward deployed postings describe the same thing, with production adoption and eval-driven feedback from real deployments feeding back into product and model roadmaps.

Frontier models are available to everyone on the same terms. Turning one into a system that survives your edge cases is not.

The gap between companies is no longer access to capable models. It is the ability to wire one into a real workflow: the actual data with its actual gaps, the evaluation harness that says whether the thing works, the guardrails, the cost ceiling, and the non-AI fallback for the day it misbehaves. None of that generalizes cleanly into a product, because the mess is specific to each business. Someone has to go and sit in the mess.

That is why the label spread from Palantir to the frontier labs. On 11 May 2026 OpenAI launched a dedicated deployment company and agreed to acquire Tomoro, bringing roughly 150 experienced forward deployed engineers and deployment specialists across on day one. When the organization with the best models concludes that deployment needs its own company, that is a statement about where the remaining difficulty actually lives.

For a buyer this has one practical consequence. Demand for the role has outrun the supply of people who can genuinely do it, so the label is now being attached to work that is nothing like it. The rest of this page is about telling the difference before you sign, because the proposals look almost identical.

The difference is what you are actually buying, and contracts tend to be written in a way that blurs it.

A consultant sells judgment. The deliverable is a recommendation, and the good ones genuinely change what you decide. What none of them leave behind is a running system. A forward deployed engagement is the opposite commitment: the deliverable is software in production, operated and handed over. A simple filter is to ask whether the engagement could end with a document and still be called a success. If it could, you are buying consulting, which may well be the right purchase, just not this one.

An agency sells effort against a backlog you own. Agencies are strong at commodity throughput and at specialist disciplines a small senior team never staffs, and they struggle when the work needs architectural judgment the client cannot supply. A forward deployed engagement assumes the reverse: the judgment is the main thing you are paying for, which is also why it is a poor fit for work you could specify yourself.

Staff augmentation is the closest twin and by far the most common relabel. Both models put senior engineers inside your environment, so from the outside they look the same. What is being bought is not. Staff augmentation buys capacity against a backlog you own, billed by the hour, ending when you stop paying. Forward deployed engineering buys an outcome: the engineers own the architecture while they are deployed, the scope is a production milestone rather than a backlog, and the engagement ends on a named transfer date when your team takes ownership.

In-house hiring is the right answer for the core product, when leadership has the bandwidth to hire and keep senior engineers and the work is permanent rather than project-shaped. Most companies end up hybrid: in-house for the core, a forward deployed partner for the parts that need senior judgment now and a permanent team never.

If a vendor calls itself forward deployed and cannot tell you when the engagement ends and what you own that day, it is selling you staff augmentation.

The question costs nothing to ask and is very hard to answer dishonestly. A real answer names a date, names what transfers on it (the repositories, the evaluation harness running in your CI, the runbooks, the monitoring, the on-call playbook), and names the person on your side who will hold it. A vendor that works this way has the answer ready, because the date is how they plan the engagement.

Three failure modes show up immediately. There is no date, and the engagement is an open-ended retainer with a better name. There is a date but nothing attached to it, so the work stops and the operational knowledge leaves with it. Or there is a date with a renewal already attached, which is a dependency being described as a partnership. None of these are necessarily bad purchases, but none of them are what forward deployed is supposed to mean.

Two follow-up questions finish the job. Who writes the code, specifically: if the person who scoped the work is not the person building it, there is a translation layer and you will pay for it twice, once in fees and once in the requirements that get lost crossing it. And where does the code live from day one: if it sits in the vendor's repositories until the end, what you have bought is a handover event, which fails far more often than a handover process does.

The measure of a forward deployed engagement is not what shipped. It is what your team can safely change six months later.

On the transfer date your team should be able to answer three questions without calling anyone: where the code lives, how we know it still works, and what we do when it breaks. Those map to the repositories, the evaluation harness in your CI, and the runbooks. If any of the three needs a phone call, the handover has not happened yet, whatever the contract says.

The common failure is subtler than an outright failed project. The system works, and nobody inside the company understands it, so the people who built it are the only ones who can change it. That is a functioning product and a strategic liability at the same time, and it is usually discovered at the worst moment, when a rate goes up or a key person moves on.

The role is worth buying when the work is specific enough that no product will ever cover it, and important enough that it has to keep running after the engagement ends. When only the first is true, you are buying a contractor. When only the second is true, buy the product. When both are true, insist on the transfer date.