What a forward deployed engineer is responsible for

Two people can carry the same title and do different jobs. One spends the week inside the customer's group chats, reads their tables, sits in the Monday operations meeting, and is the person called at two in the morning when the pipeline that sets next week's dispatch stops. The other produces slides, attends the quarterly review, and has never deployed anything. Both are called forward deployed engineers. Only one of them is.

The title is not the definition. What separates the role is what it is accountable for when the work ends, and there are three such accountabilities. They have to hold together; any one of them alone describes a different job.

Three responsibilities, not three activities

Embedded in the customer's environment. Not visiting it — working inside its context. That means being in the customer's channels, reading their data, sitting in their meetings, and knowing the person who can explain why the process is shaped the way it is. The distinction matters because travel is a logistics fact and embedding is an information fact. An engineer who flies in for a week and leaves with a requirements document was never embedded; they were briefed.

Personally owns the production result. The system has to run, and the person who built it answers for it running. This is the line between a recommendation and a deployment, and it is why the role resists being split into a sales team, an implementation team, and a support desk: once ownership is divided, nobody answers for the whole. The test is not whether the service returns a healthy status code. It is whether the system is being used.

Feeds what was learned back into the product. Every deployment should leave behind something the next one does not have to rediscover: a connector, an evaluation set, a pattern that generalises. If each customer starts from a blank page, the work is outsourcing with better branding. The only measurable form of this responsibility is that the customisation required for each new customer declines.

Remove any one and the role collapses into a neighbour. Advice without a system is consulting. A system without an owner is a handover. A system with an owner but no feedback is a project that will be rebuilt at the next customer at full price. The white paper reaches the same conclusion from a different direction: the boundary is drawn by the scope of responsibility, not by the name on the org chart.

Where the shape came from

The pattern is older than the current wave. Palantir had field engineers, known internally as Deltas, by around 2008, and its S-1 treats field engineering as part of research and development rather than as a services line. The early deployments look like the job description: an engineer embedded with a patrol unit finds that what the unit wants is not an intelligence dashboard but a way to mark a road as suspect on a map, and builds it where they are standing. That tool later became a standard platform feature. Field problem, on-site build, product absorption — the loop was the company's research method well before it was anyone's job title.

2026 is when the shape became an institution. Within roughly two weeks in May, OpenAI stood up a deployment company with about 150 FDEs and deployment specialists, Anthropic formed a partnership with Blackstone, H&F and Goldman, and ServiceNow, SAP, AWS and Microsoft announced comparable structures with consultancies and integrators. The dollar figures attached to those announcements move as deals are restated; the direction does not. Model vendors concluded that shipping capability and installing capability are different businesses.

Why "missing responsibility owner" beats "engineer who travels"

The travel definition is intuitive and wrong, because it describes the cheapest part of the job. Flights are a cost line; anyone can book them. A role justified by travel gets cut in the first efficiency pass, and deserves to be.

The better definition comes from what the white paper calls the missing responsibility subject. Once agents read customer data, write back into business systems and trigger approvals, someone has to be authorised, accountable and able to roll it back. An org chart built for tools — a seller, an implementer, a support queue — has no seat for that. The FDE is the seat.

This also settles the usual objection that the role is presales with a laptop. Presales ends at signature: its goal is winning the deal, its artefact is a deck. The FDE's hardest work begins after signature, and its artefact is a system in production. One person can do both jobs across a career. They cannot be the same job.

The test

Three questions, asked of any person or team carrying the title:

1. When the system breaks at an unreasonable hour, whose name is on the fix?
2. Has this person changed a production system in the last thirty days, or only described one?
3. Did anything from the last deployment — a component, an evaluation set, a written judgement — get reused by the next one?

Three yeses is a forward deployed engineer. Any no tells you which neighbouring role you actually have.

Continue with why the role appeared now, or go straight to the five-stage delivery method.