What Is a Forward Deployed Engineer? What FDEs Actually Own

A Forward Deployed Engineer works directly with the people using a system and takes technical responsibility for getting a solution into production. The role brings discovery, architecture, implementation, integration and post-launch learning into one delivery function.

That proximity matters when the delivery path is unclear. In a conventional product organisation, discovery, architecture, implementation, customer success and operations may sit in different teams. An FDE works across those boundaries to understand where the workflow breaks and change the systems around it.

That is why the role has become especially visible in enterprise AI. Access to a capable model is increasingly the easy part. The difficult work begins when the model has to operate inside real permissions, legacy systems, data boundaries, latency targets, review processes and user behaviour.

From Enable FDE’s own production work: MyEscapePlan is a travel-intelligence platform spanning AI decisioning, live supplier integrations, data pipelines, and consumer and advisor workflows. Read the case study.

What actually changes when an engineer is forward deployed?

The word forward matters because the engineer is moved closer to the environment where the outcome must work.

That does not necessarily mean sitting permanently in a customer office. It means reducing the organisational distance between the people discovering the problem and the people capable of changing the system.

A strong FDE engagement therefore tends to combine work that would otherwise be separated:

• observing the current workflow and identifying the real bottleneck;
• defining a measurable outcome rather than simply accepting a ticket list;
• deciding which parts require software, data, AI or process change;
• working directly in the relevant repositories, cloud accounts, APIs and data systems;
• building production code;
• creating evaluation and regression mechanisms;
• dealing with identity, security, exceptions and operational fallbacks;
• launching with real users;
• measuring whether the workflow actually improved;
• leaving the client able to operate what was built.

OpenAI’s current FDE description is unusually explicit: its engineers own discovery, technical scoping, system design, build and production rollout, while success is measured through production adoption, workflow impact and eval-driven feedback. OpenAI’s Madrid role description is useful because it moves the definition beyond “technical and customer-facing”.

Why FDE became much bigger than a job title in 2026

Forward-deployed engineering is not new. Palantir is closely associated with the model, particularly the idea of deploying technical teams close to difficult customer problems and feeding what they learn back into a reusable platform.

What changed is the scale at which the AI industry has adopted the pattern.

In May 2026, OpenAI announced the OpenAI Deployment Company, with more than $4 billion of initial investment and an agreement to acquire Tomoro, bringing approximately 150 experienced Forward Deployed Engineers and Deployment Specialists into the organisation. The stated model is to identify high-value workflows and then build inside the customer’s real data, tools, controls and business processes. OpenAI’s announcement is strong evidence that deployment itself has become part of the commercial infrastructure around frontier AI.

Other companies are converging on related models. Anthropic’s current Applied AI organisation includes Forward Deployed Engineers in London, Paris and Munich, while its DXC alliance is training tens of thousands of Claude-certified FDEs inside an established systems integrator. Salesforce has created an FDE Partner Network spanning more than 30 consulting firms, and EY now recruits FDEs specifically to design, build, integrate and operationalise AI in live client environments.

The important shift is this:

Forward deployment is becoming a distribution model for complex technology, not simply a title on an engineering org chart.

The FDE lifecycle: what should actually be owned?

A useful engagement can be described as a lifecycle rather than a list of skills:

Problem → Discovery → Evidence → Architecture → Build → Integrate → Evaluate → Production → Adoption → Handover

Each stage should leave something concrete behind.

Problem

Start with the operating problem. Choose the technology once its requirements are clear.

Start with the work that takes time: “Support staff spend much of the morning pulling information from several systems before they can answer a customer.” Measure how often the delay happens and what it costs before choosing a technical approach.

Discovery

Discovery means observing the workflow closely enough to understand exceptions, permissions, data ownership, latency expectations, existing tooling and the people who must use the result.

The output is not a generic requirements document. It is a working model of what the system has to change.

Evidence

Before committing to a large build, the team needs evidence that the intended intervention can work. In an AI project this might mean a representative evaluation set, baseline accuracy, latency and cost measurements, or a prototype tested against historical cases.

Architecture

The architecture should follow the constraints discovered earlier: model choice, deployment region, data access, identity, system boundaries, human approval and failure modes.

Build and integrate

This is where forward deployment diverges most clearly from strategy-only advisory work. The same delivery team that understands the operating problem is expected to write and integrate the production system.

Evaluate

For AI systems in particular, “the demo looked good” is not a release criterion. Evaluation needs to cover the behaviour that matters to the workflow: task success, factual accuracy, unsafe actions, escalation rate, cost, latency or whatever failure modes would make the system unusable.

Production and adoption

A technically live system with no users is not a successful deployment. Production means the surrounding workflow works too: access, monitoring, support, fallbacks, training and ownership.

Handover

A good FDE engagement should reduce dependency rather than manufacture it. Source code, infrastructure, tests, evaluation assets, operating documentation and known limitations should remain understandable and operable by the customer.

The FDE ownership test

A practical way to decide whether a problem is “FDE-shaped” is to ask:

Who owns the problem when the demo works but the real workflow does not?

Imagine an AI prototype that produces impressive answers on a laptop. Then production work begins.

The identity system blocks service-to-service access. Historical data contains inconsistent identifiers. One API has a hard rate limit. The output needs human approval in regulated cases. Latency is acceptable in testing but not during the morning peak. Nobody has defined what should happen when a tool call partially succeeds. Users copy results into another system because the integration stops one step too early.

None of those failures is solved by a better prompt alone.

If responsibility for them is scattered between a vendor, internal platform team, business owner, consultant and application team, the project can stall despite every individual component “working”. Forward deployment is valuable when one technical delivery function can stay close enough to the outcome to move across those boundaries.

Production AI is mostly a systems problem around the model

Current FDE role descriptions make this increasingly explicit.

OpenAI’s current Madrid FDE role makes the same production boundary explicit: the engineer owns delivery from first prototype to stable production, contributes directly in code, guides adoption and turns working patterns into reusable tools or playbooks. In practice, that means the difficult work after a convincing proof of concept is usually around integration, data, permissions, evaluation, observability, failure handling, latency and operating ownership rather than model access alone.

For many production AI systems, the surrounding work includes:

• authentication and authorisation;
• data retrieval and quality;
• tool/API contracts;
• state and memory;
• model routing and fallbacks;
• deterministic business rules;
• evaluation and regression testing;
• tracing and observability;
• cost and latency controls;
• human review;
• exception handling;
• change management.

The model matters. But the value normally appears only when all of those pieces cooperate inside a real operating process.

FDE is becoming a team, not a single title

Another reason to avoid an overly narrow definition is that organisations are already splitting deployment responsibility across related roles.

OpenAI advertises Forward Deployed Engineers, Forward Deployed Software Engineers, Technical Deployment Leads and domain-specific deployment roles. Anthropic’s Applied AI organisation similarly combines FDEs with applied AI engineers, architects, strategists and technical deployment leadership.

That suggests a more useful mental model:

FDE is a deployment capability. The exact team composition depends on the size and risk of the problem.

A small deployment may be led by one senior engineer. A regulated enterprise programme may need engineering, architecture, domain, security and change-management capability around the same outcome.

Three FDE models are emerging

1. Vendor-owned FDE

The engineer is close to a particular product or platform: OpenAI, Anthropic, Palantir or another technology provider.

The advantage is deep product access and a powerful feedback loop into the vendor’s own roadmap. The constraint is that the engagement naturally starts from that vendor’s stack.

2. Partner or integrator FDE

The deployment capability sits in a consultancy or implementation partner certified around one or more platforms.

Anthropic’s partner strategy and Salesforce’s FDE Partner Network are clear examples. This model can offer more delivery capacity and industry expertise than a single vendor team.

3. Independent or model-neutral FDE

The engagement starts from the customer’s workflow and chooses products, models and infrastructure around the constraints.

This is the model most relevant when the answer may span internal applications, several vendors, legacy systems and customer-owned code rather than deployment of one platform.

The reuse problem: when does FDE turn into bespoke agency work?

Every forward-deployed model has to manage a tension between custom delivery and reusable engineering.

Too much custom code and the provider becomes an ordinary software agency. Too little adaptation and the provider becomes a standard SaaS implementation team.

A useful framework is:

Core → Configuration → Connective tissue → Customer-specific workflow

Core is the stable product or reusable technical foundation.

Configuration adapts supported behaviour without changing architecture.

Connective tissue is the integration layer: identity, APIs, data mappings, orchestration, evaluation and observability.

Customer-specific workflow is the part that encodes how this organisation actually operates.

The strongest forward-deployed systems try to keep the first three increasingly reusable while allowing the final layer to reflect the customer’s real process. Field learning then feeds back into the core.

That loop can be written as:

Deploy → Measure → Learn → Generalise → Productise → Deploy again

OpenAI explicitly asks FDEs to codify successful field patterns into reusable tools, playbooks or building blocks and feed deployment learning back into Product and Research. That feedback loop is one of the most meaningful differences between forward deployment and one-off bespoke development.

When should you use a Forward Deployed Engineer?

FDE is strongest when several of these are true:

• the business outcome is clear but the technical route is not;
• the project crosses product, data, infrastructure and operations;
• a prototype exists but production has stalled;
• requirements will change as the real workflow is observed;
• customer-specific integration work is blocking adoption;
• a senior engineer needs direct access to operators and decision-makers;
• success can be measured operationally, not only by completed tickets.

It is often a poor fit when the task is a stable commodity build, the requirements are already clear, or an internal engineering team has the context and capacity to deliver without another ownership layer.

A hypothetical four-week example

An internal AI assistant for complex service requests performs well on curated examples but has never handled the live workflow.

A forward-deployed first month might look like this:

Week 1: observe how requests are handled; identify the systems used; sample historical cases; define success and failure categories; establish security and data boundaries.

Week 2: create the evaluation harness; connect the first production data source; implement identity and permissions; test model/tool behaviour against representative cases.

Week 3: integrate the remaining workflow; add deterministic rules, escalation and failure handling; instrument latency, cost and quality; release to a limited user cohort.

Week 4: analyse production traces and user behaviour; fix high-value failure modes; document operation and handover; decide whether to expand, stop or start the next workflow.

Treat this as one possible sequence. Timing depends on data access, system dependencies, risk and how quickly the customer can review decisions. The example shows how discovery and production engineering can overlap during the first month.

For a buyer, ask who will understand the workflow, make the technical changes and support the production launch. That delivery responsibility is the defining feature of an FDE engagement.