Forward Deployed Engineer is now used for at least five different jobs. They share a name, a posture toward the customer, and most of a skill list. They do not share an evidence standard, and a hiring team that treats them as one role will either over-qualify a builder or under-qualify a deployment lead.
This note reads the first-party record for the variants it actually supports, names what each variant owns, and states what a credible record for each should contain. It does not estimate how many people hold any variant, and it does not rank them. The differences are about scope of responsibility, not seniority.
Two meanings, then five seats
The popular account of the role, Ed Donner's explainer on why every tech company wants forward deployed engineers, draws the first line clearly. The title has a narrow meaning, an AI engineer employed by a model provider and placed at an external customer to own the implementation, and a broad meaning, any applied AI engineer using models and agents to produce a commercial result, inside their own company or at a client. Donner describes the work as five hats: software engineer, AI engineer, AI solutions architect, domain expert, and solutions consultant. The narrow job asks for all five; the broad job asks for the first three.
The first-party record is more granular than two meanings. Reading current role specifications, partner announcements, and onboarding reports, five distinct seats appear.
| Variant | Who defines it | What the seat owns | What the reviewed record says distinguishes it |
|---|---|---|---|
| Model-provider FDE | OpenAI's FDE specification and its deployment company | Discovery, technical scoping, system design, build, rollout, adoption, and measurable workflow impact at an external customer | End-to-end ownership plus a duty to feed evaluation-driven field learning back into product and model roadmaps |
| Forward-deployed software engineer | OpenAI's FDSE specification | Production-grade, full-stack building alongside FDEs and customers | Turning customer-specific lessons into reusable abstractions; the engineering half of the pair |
| Platform-company FDE | Palantir's originating model, described by The Pragmatic Engineer; Salesforce's six-week onboarding model | Deploying one company's platform inside one customer across many capabilities | A standing feedback loop into the product; Salesforce reports that a large share of its team moved over from engineering, professional services, and customer success |
| Services-firm forward-deployed engineer | Accenture's "reinvention deployed engineers"; Wipro's Applied AI Center of Excellence; Cognizant's "Frontier Certified" workforce | A certified bench delivering inside a prime's program, on the prime's paper | Business-process knowledge and model expertise inside client environments, with training and certification commitments announced at scale |
| In-house applied AI engineer using the title | Donner's broad meaning; TechCrunch's reporting on enterprises hiring in insurance, fintech, healthcare, and gaming | The same deployment obligations for an internal customer, without the commercial layer | Keeping proprietary process knowledge inside the company rather than with a vendor |
A sixth seat, the technical deployment lead or FDE manager, appears on OpenAI's team page but is a management variant of the first and is not treated separately here.
The layer that separates the seats
Donner's five hats are better read as layers, because each rests on the one below and they are acquired in order. Software engineering is the floor for every variant. AI engineering, meaning model choice, agents, retrieval, tool use, context and harness discipline, and evaluation, is the second layer and is also common to every variant.
The third layer, which Donner calls the AI solutions architect hat, is where the seats diverge. It contains discovery against a live operation, evaluation design from the customer's own cases, data curation, deployment under real controls, observability, adoption, and responsible AI. The model-provider FDE and the platform-company FDE are accountable for all of it. The forward-deployed software engineer contributes to it but is measured on the build. The services-firm engineer exercises it inside a program the prime governs, so the prime's controls and the engineer's own work have to be separated in the record. The in-house engineer exercises it without ever having to win a customer.
TechCrunch's reporting captures the practical consequence in one quotation from Chris Taylor, chief executive of Ode: many FDEs are well equipped to help a company roll a coding agent out, and very few are capable of building its flagship AI product feature. Both are legitimate forward-deployed work. They are not the same job, and a record that says "forward deployed" without saying which one tells a hiring team almost nothing.
The workloads change the evidence too
The variants cut one way; the workloads cut another. The reviewed records describe forward-deployed work across at least four workload families, and each produces a different kind of evidence.
- Rollout and enablement. Putting an approved model or coding agent in front of a workforce, with policy, training, and adoption measurement. Evidence is adoption and enablement, not a new system.
- A governed operational workflow. Prior authorization, claims, contract review, underwriting research, a contact-center path. Evidence is the control boundary, the evaluation set, the production record, and an attributable operating result.
- A flagship product capability. A customer-facing feature built on frontier models. Evidence is engineering depth, reliability under load, and a product decision that survived contact with users.
- Platform and integration substrate. Identity, data contracts, connectors, and evaluation primitives that later workflows inherit. Evidence is reuse: the second workflow shipping faster on the first one's assets.
A practitioner who has done only the first family and a practitioner who has done only the second both carry the title. The benchmark should be able to tell them apart from their artifacts, and a buyer should be able to ask which family a candidate's production record comes from.
LockedIn Benchmark implication
Three design consequences follow, all consistent with the earlier notes on the title, certification, and domain packs.
- Variant is routing metadata, like title. It selects which evidence a record is expected to carry and which capability families weigh most. It never awards credit.
- Evidence expectations are variant-aware, the core construct is not. One vendor-neutral core, with the third-layer families weighted by seat: full accountability for the model-provider and platform seats, build accountability for the software-engineer seat, separated accountability for the services seat, and internal-customer accountability for the in-house seat.
- Workload family is recorded on every production artifact. A rollout, a governed workflow, a flagship feature, and a substrate contribution are different claims. Preserving the distinction is what lets an outcome be read fairly later.
None of this requires a new number. It requires the record to say which job was done.
Where the family speaks in unison
The firm's field guide for engineers entering the role uses the same layers to describe the path in. The training platform forms the first two layers and rehearses the third against a published field standard, deliberately separate from this benchmark so completing a module never masquerades as proof. This note supplies the third leg: the evidence a record should carry, by variant and by workload, before anyone calls it forward-deployed.
Limitations
This note synthesizes a purposive set of first-party role descriptions, partner announcements, one vendor-reported onboarding account, one journalistic report, and one practitioner explainer. Those sources are self-authored or secondary and may be aspirational. No prevalence, workforce-size, growth-rate, compensation, or pass-rate estimate is supported or asserted. The five variants are a reading of the current record, not a validated taxonomy; the registered job analysis described in the benchmark formation protocol is the instrument for testing it.