know.2nth.ai People ai-roles Forward Deployed Engineer
people/ai-roles · Forward Deployed Engineer · Skill Leaf

The role Palantir built in 2005, now everywhere.

A consultant writes a deck and leaves. A forward deployed engineer joins after the contract is signed, writes production code against the customer's data, and is still the person who gets paged when it breaks six months later. Same room, opposite job. The role is twenty years old — Palantir built it for classified government accounts in the mid-2000s — and generative AI made it necessary again everywhere, because the products demo brilliantly and deploy unevenly.

Live Palantir, 2005 Post-sale, not pre-sale Ships code Enterprise AI

An engineer embedded in the customer, accountable end to end.

A Forward Deployed Engineer (FDE) is an engineer embedded inside the customer's organisation who writes production code against the customer's data, stays on it after it ships, and routes what they learn back into the product. The definitional trait across every source is end-to-end accountability: the person who maps the problem in week one is the person who gets paged when it breaks in month six. That single fact is what separates the role from the three jobs it is most often confused with.

RoleTimingShips production code?Owns it after go-live?
ConsultantAnyNo — produces a deliverable, then exitsNo
Solutions engineerPre-saleDemos the product against the buyer's context to close the dealNo
Forward deployed engineerPost-saleYes — writes it, runs it, in the customer's stackYes — accountable in month six

Some organisations blur the solutions-engineer / FDE line — Palantir did early on — but the modern labs keep them distinct, because pre-sale demo work and post-sale production ownership select for different people and different incentives.

The discriminator is not the title. It's whether they're still accountable in six months.

A two-sided knowledge gap that nothing else bridges.

The customer's engineers know the data schemas, the compliance constraints, the legacy architecture, and the edge cases. The lab's engineers know how models behave in production — retrieval strategies, eval design, the failure modes that only appear at scale. Neither side has the other's knowledge, and you need both to ship. A customer success manager cannot bridge that gap. Documentation cannot bridge it. Closing it in person, in the customer's repo, is the entire reason the role exists.

On the "95% of pilots fail" number

The widely-cited claim that most enterprise generative-AI pilots show no measurable business impact — the MIT NANDA figure of roughly 95% — is the demand-side argument every FDE article reaches for. Treat it as contested, not settled: it has been heavily criticised on methodology since publication and is one of the most over-quoted numbers in enterprise AI. The structural point holds without it — enterprise AI work has historically died in the gap between a working demo and a production deployment, and the FDE exists to close that gap.

The same five-verb loop, in five vocabularies.

Every posting across Anthropic, OpenAI, Google, Palantir, Scale, and ServiceNow describes the same loop in different words. Strip the vocabulary and it is five verbs, run in order and then repeated.

1 · Scope

Learn the domain before shipping anything. Palantir-lineage FDEs front-load a domain model — the Foundry ontology pattern — before any LLM-grounded application; the same shape shows up as tool-calling schema design in the modern labs. Get the problem right first.

2 · Build

Production code in the customer's stack, behind their auth, their logging, their incident response, with evals configured. In Anthropic's posting language, that means shipping MCP servers, subagents, and integrations into the customer's environment (Anthropic job postings, 2026).

3 · Deploy

Move from notebook to production — the step where most enterprise AI work has historically died. The FDE owns the crossing, not just the prototype.

4 · Codify

Turn the bespoke thing into a reusable pattern. OpenAI calls it "durable productization," Anthropic "repeatable deployment patterns," ServiceNow "reusable AI-native patterns" — the same mandate in three vocabularies (collation: Carlson, close-reading of job postings, May 2026).

5 · Feed back

Route field learning into the product and research roadmap. At Palantir the FDE was the primary product-management input channel — which is half the value of the role, and the half most organisations forget to wire up.

Palantir's own framing

Palantir describes the FDE's responsibilities as looking like a hands-on startup CTO's — small teams, end-to-end execution of high-stakes projects. That is the cleanest one-line definition of the seat: not a specialist in a lane, but an owner of an outcome.

Who hires under the label — and who wears it wrongly.

The title has spread fast across the frontier labs and beyond. It has also been applied to jobs that are not this job. Both tables matter; the second one more.

OrgLabelNote
PalantirForward Deployed Software Engineer (FDSE); AI variant, Forward Deployed AI EngineerOriginated the role in the mid-2000s on classified US government accounts. Early FDEs were internally called "Deltas"; until 2016 Palantir had more FDEs than software engineers (Pragmatic Engineer, with ex-Palantir input).
AnthropicApplied AI Engineer / Forward Deployed EngineerSits under Applied AI; postings emphasise safety-aware deployment and Claude-specific integration (Anthropic job postings, 2026).
OpenAIForward Deployed EngineerFunction established 2025 under Colin Jarvis, deliberately distinguished from the Solutions Architect (professional-services) track (Pragmatic Engineer, Jarvis as named source).
Google CloudForward Deployed EngineerFramed as bridging frontier AI products with production-grade reality.
Scale, Cohere, Databricks, Anduril, ServiceNow, Ramp, CursorVariousAnduril runs a security-cleared variant; Ramp runs FDEs in pods (Pragmatic Engineer, with Ramp's FDE lead as named source).

The adjacent titles below are not the same job, however the req is worded. The discriminating question is the same every time: do they write production code in the customer's repo, and are they still accountable in six months?

Adjacent titleTimingWhy it isn't an FDE
Solutions ArchitectPre-saleDesigns and advises; hands off the code.
Sales EngineerPre-saleDemos to close; doesn't own production.
Technical Account ManagerPost-saleManages the relationship; writes no code.
Implementation ConsultantDeliveryProduces a deliverable and exits.
Agent EngineerAnyBuilds the agent; not embedded in the customer, not accountable on their data.

When the model earns its place.

The FDE model is expensive and specific. It earns its keep in a recognisable set of conditions:

  • The workflow is custom enough that off-the-shelf doesn't fit — the value is in the integration, not the product's defaults.
  • The system must run in production with accountability, not ship as a one-time deliverable.
  • In-house AI hiring is too slow or too expensive for the timeline, so the capability is borrowed embedded rather than built.
  • The vendor needs field signal to improve the product, and this customer is a good source of it — the feedback loop pays for the engagement a second time.

A twenty-year-old role that AI made necessary again.

This is not a new role. It is an old one that a new technology re-created the demand for.

EraWhat happened
~2005Palantir builds the role for Gotham on government and intel accounts, because consultants couldn't write production code and solutions architects couldn't change the product. (Sources broadly agree on the mid-2000s; some say 2005, one says "around 2010.")
2010sDefence and intelligence contractors adopt variants of the embedded-engineer model.
2023–24Generative AI re-creates the same problem — products demo brilliantly and deploy unevenly — and the gap between pilot and production becomes the industry's defining failure.
2025OpenAI formalises the Forward Deployed Engineer function under Colin Jarvis, explicitly distinct from Solutions Architecture.
2026The label is standard across the frontier labs and has spread to Scale, Ramp, Cursor, ServiceNow, and the consultancies — along with the title inflation that follows any hot label.

When to engage one. When not to.

The disqualifying cases matter more than the qualifying ones. If any of the "skip it when" conditions hold, the model will underperform or the person will leave — usually both.

Use when

  • The workflow is custom enough that off-the-shelf configuration doesn't fit.
  • The system must run in production with accountability, not ship as a deliverable.
  • In-house AI hiring is too slow or costly for the timeline.
  • The vendor needs field signal, and this customer is a good source of it.
  • The customer will grant real repo and production-data access.

Where the role bites.

The title is being applied to jobs that aren't this job

Solutions architects, sales engineers, and implementation consultants are all now posted under the FDE label. The discriminator is production code and durable accountability — nothing else.

It is a retention problem by design

High travel, high stakes, unfamiliar codebases, customer politics. Organisations that run it well have a defined exit path back into product engineering. Those that don't lose the person and the field knowledge together.

Compensation data is a mess

Ranges reported for the same role and level differ by more than 2× across sources, all US-centric and largely recruiter-published. Treat any published band as directional at best; the honest signal is that the frontier labs budget these as product-engineering roles, not consulting roles.

The role is a product-management input channel most orgs never wire up

If field learning has no route into the roadmap, you have expensive contractors, not FDEs. The feedback loop is not optional plumbing; it's half the economic case.

"Embedded" has a security perimeter

Anduril's cleared variant exists because the standard model doesn't survive contact with classified environments. The same applies to any regulated customer — the access model is the first thing to design, not the last.

Well-suited to SA delivery, at odds with how SA prices it.

The FDE model is a description of what good South African delivery already looks like when it's done well: a strong engineer, embedded, writing production code in the customer's repo, accountable after go-live. The constraint is not talent — it's the commercial model. Time-and-materials integration work and fixed-scope deliverables both incentivise exit-at-handover, which is the exact behaviour the FDE role exists to prevent. Adopting the role means changing how the engagement is priced, not just what the engineer is called.

The feedback-loop condition

The FDE model pays for itself twice — once on the engagement, once when field learning improves the product. A firm with no product of its own collects only the first payoff, which makes the model worse value for a pure services shop than for a platform vendor. Any SA firm adopting the label should be honest about which of those it is.

Data residency and access is a week-zero problem

The role requires repo and production-data access inside the customer's environment. Under POPIA that is a processing arrangement that must be papered before week one, not after. For financial-services customers the access model has to survive an FSCA review. The upside is the one the orchestrating-agents leaf names: the PR trail and the versioned spec the engineer produces is the change-control record the reviewer wants.

How this node connects in the tree.

The FDE is the person; the software branch is the practice they work inside. This leaf defines the role; the practice leaves define how the work gets done.

Primary and near-primary only.

Job postings are the primary source for what the role actually is. Recruiter content is used only to corroborate, never as the sole source of a claim — and the salary figures it leads with are omitted here by design.