How is the practice different from the individual role?

The role describes what one person does inside one account. The practice describes how the work is organized, staffed, and repeated across many accounts. The practice adds three things the role alone does not: a division of labor between the engineer who builds and a counterpart who owns the engagement, a repeatable engagement shape that turns each deployment into reusable product, and a way to scale delivery past the number of engineers a company can hire directly. Reading a posting, a title built on the practice form is usually about building or leading the capability; a title built on the person is usually about doing the work in an account.

How is a forward deployed engineering team structured?

The recurring structure pairs a builder with a coordinator. At Palantir the pairing was a Delta, the engineer who wrote production code, and an Echo, the deployment strategist who owned adoption and stakeholder reality. The same split reappears at the frontier labs under different names: Anthropic pairs Forward Deployed Engineers with Engagement Managers who own delivery logistics and stakeholder management, and OpenAI runs a Technical Deployment Lead who owns the delivery plan across FDEs, researchers, and customer engineers. The two functions are constant across companies; the title for the coordinator half is not yet settled.

How does a forward deployed engagement work?

A typical engagement embeds a small team, scopes one or two high-value problems against the customer's real data and constraints, builds in production rather than in a demo environment, and then codifies what worked into playbooks, templates, and reusable components before handing toward long-term ownership. The practice is defined less by any single engagement than by the loop between them: the discipline exists to make the next deployment cheaper than the last by abstracting the last one into product.

How does forward deployed engineering scale?

Three patterns are visible. A company can hire engineers directly, which is how the model started but is hard to scale against enterprise demand. It can stand up a separately-capitalized delivery company, which is what OpenAI did with the OpenAI Deployment Company and Anthropic did with its enterprise-services firm, both announced within a week of each other in May 2026. Or it can credential outside partners to run the same motion under a shared production bar, which is the approach AWS took with its Partner-Led Forward Deployed Engineering motion. The three answers trade control against reach differently.

Which companies run a forward deployed engineering practice?

Palantir originated it. Among the AI platforms, OpenAI and Anthropic both run named Forward Deployed Engineering functions, and Amazon has stood up a Forward Deployed Engineering organization at AWS. The practice has spread fast enough that the naming, the team structure, and the scaling model are now observable across several companies at once rather than at any single originator.

Does forward deployed engineering specialize by industry?

Yes, increasingly. OpenAI staffs separate Forward Deployed Engineering teams for distinct verticals, including semiconductor, financial services, and government, each hiring for the domain knowledge and compliance surface that sector requires. The operating model stays constant across verticals; what changes is the domain the embedded team has to learn and the environment it deploys into, which for regulated data often means running inside customer-controlled infrastructure rather than a public endpoint.

Is the forward deployed model proven, or is it contested?

Both are true and worth stating plainly. Supporters point to it as the mechanism that turns a capable platform into adopted production systems, and the leading AI labs are investing heavily in it. Critics argue it is a strong model for landing and proving a deployment but a weaker one for running software long-term, citing ongoing cost, lock-in, and the risk of shipping visualization rather than new capability. The fault lines in that debate are execution quality and domain depth, not whether embedding works at all.

The practice

What is Forward Deployed Engineering?

Definition PRACTICE

Forward deployed engineering is the practice of a platform company embedding its own engineers inside a customer to build, ship, and operate a production system, then routing what that work teaches back into the product. A forward deployed engineer is the person. Forward deployed engineering is the discipline, the team, and the way the work is organized to repeat.

Person Forward deployed engineer - the individual who embeds and builds

Practice Forward deployed engineering - the team and discipline, named with the gerund

Test Platform-employed, embedded, accountable for production, feeding learning back

Companies use the two forms deliberately. Anthropic hires a Manager, Forward Deployed Engineering to run its practice; OpenAI names a Forward Deployed Engineering team that partners with customers and turns early deployments into reusable patterns. The gerund is not a coinage this page is inventing. It is the settled team-level form at the companies defining the field.

This page is an independent reference. It is not affiliated with any company named on it, and it synthesizes public job listings and primary company announcements on the forward deployed model.

Practice vs role

What the practice adds to the role

The forward deployed engineer page covers what one person does inside one account. The practice is a different unit of analysis: how that work is staffed, structured, and repeated across many accounts. Three things belong to the practice and not to any single engineer. There is a division of labor between the person who builds and a counterpart who owns the engagement. There is a repeatable engagement shape that exists to turn each deployment into reusable product. And there is a scaling model for delivering past the number of engineers a company can hire directly.

The distinction is practical when reading a posting. A title built on the practice form, Manager or Head of Forward Deployed Engineering, is usually about building or leading the capability. A title built on the person is usually about doing the work in an account. The vocabulary tells you which job is on offer.

Team structure

The team pairs a builder with a coordinator

The defining structural feature of the practice is that its unit is not one person. It is a pairing: the engineer who writes production code, and a counterpart who owns the engagement itself, its sequencing, its stakeholders, and whether the work actually gets adopted. Palantir ran this as two named roles, a Delta who built and an Echo who managed institutional reality. The pairing survives the move to the AI labs, under new names.

At Anthropic, forward deployed engineers work hand in hand with Engagement Managers who own delivery logistics and stakeholder management, while the engineers ship the code. At OpenAI, a Technical Deployment Lead owns the delivery plan and runs day-to-day execution across forward deployed engineers, researchers, and customer engineers. The builder and the coordinator are constant across all three companies. What is not constant is the coordinator's title, which changes at every company that runs the model.

The coordinator role has no settled name

Deployment Strategist at Palantir, Engagement Manager at Anthropic, Technical Deployment Lead at OpenAI. These are the same function, keeping the engagement aligned to the customer's outcome while the engineer builds, and the market has not converged on a single word for it. That the builder half is uniformly "forward deployed engineer" while the coordinator half fragments across titles is itself the signal: the industry has agreed on what to call the person who writes the code and is still deciding what to call the person who owns the room.

Engagement model

How an engagement runs

1
Embed a small team

A small builder-plus-coordinator team places itself inside the customer's environment rather than working from the vendor's office, close enough to see the workflows and constraints that never make it into a requirements document.
2
Scope against real data

The team picks one or two high-value problems and works them against the customer's actual data and systems, not a demo environment. Palantir's version of this was a prototyping sprint that produced working applications on the customer's own data within days.
3
Build in production

The system is built where it will run, under the customer's security, governance, and operational reality, because the gap the practice exists to close is precisely the one between a capable platform and a working deployment inside a specific organization.
4
Codify and hand off

What worked is abstracted into playbooks, templates, evals, and reusable components, and the engagement moves toward long-term ownership. The output is more than software: durable scaffolding, from knowledge graphs to runbooks to architectural documentation, is part of what a mature engagement is designed to leave behind so the customer can operate on its own.

The practice is defined less by any one engagement than by the loop between them. The discipline is organized to make deployment N+1 cheaper than deployment N, by turning the last one into product. That loop is the reason the three defining traits of the forward deployed model, platform employment, two-way knowledge flow, and productization, read at the team level as an operating principle rather than a description of one person's job.

How the practice scales

Moving fast, May 2026

Embedded delivery is expensive and hard to scale, and enterprise demand has outrun the supply of engineers who can do it. Three answers to that ceiling are now visible, and they trade control against reach differently.

Hire in-house

The original answer, and the one that hits the ceiling first. Palantir built the model by hiring top-tier engineers directly as forward deployed engineers. It works, and it is where every company starts, but the hiring bar and the cost structure make it hard to scale against a market this size.

Stand up an owned delivery company

Within one week of each other in May 2026, both leading AI labs externalized forward deployed delivery into separately-capitalized companies while keeping their own engineers embedded inside them. OpenAI launched the OpenAI Deployment Company, a standalone entity majority-owned by OpenAI, and acquired the consultancy Tomoro to bring roughly 150 experienced forward deployed engineers and deployment specialists in from day one. Anthropic announced a standalone AI-native enterprise services firm with Blackstone, Hellman & Friedman, and Goldman Sachs, with its own Applied AI engineers working alongside the firm's team. Neither lab chose to simply hire more or hand the work to consultancies. Both built owned delivery companies, a bet that the deployment layer is strategically load-bearing enough to keep close even while scaling it out.

Credential partners

The third answer pushes the practice outward. AWS pairs its own Forward Deployed Engineering organization with a Partner-Led motion that extends the same methodology, and the same production bar, into credentialed consulting partners. It reaches more customers than an owned team can, at the cost of running the motion through partners rather than inside the house.

Specialization

The practice specializes by industry

Verticalization is a property of the practice, not a one-off. OpenAI staffs separate forward deployed engineering teams for distinct sectors, with publicly posted teams for semiconductor, financial services, and government among them. Each hires for the domain knowledge and the compliance surface that sector demands.

The operating model does not change from vertical to vertical. What changes is the domain the embedded team has to learn and the environment it deploys into. In regulated sectors, that environment often means running inside customer-controlled infrastructure rather than against a public endpoint, which is why financial services, government, and healthcare deployments look heavier on governance and data residency than the model itself requires. The vertical sets the constraints; the embedded, outcome-owning structure stays the same underneath.

Interfaces

Where the practice touches the rest of the company

A forward deployed engineering practice sits at three seams. Upward, it is a conduit to product and research: field signal from deployments is meant to shift the roadmap, which is why these teams are repeatedly described as the voice of the customer in internal planning. Inward, at least at larger practices, it has its own leverage layer, a platform team whose customers are the other forward deployed engineers and whose job is to turn cross-customer patterns into reusable primitives. Sideways, it meets sales and go-to-market at the pre-sale line: account teams and engagement leads qualify and scope the work, and the practice delivers it post-sale. The same pre-sale-versus-post-sale boundary that separates a forward deployed engineer from a sales engineer separates the practice from the sales motion around it.

Is it proven

The practice is contested, and here is the shape of the debate

A neutral reference should say plainly that the model is debated. Supporters treat it as the mechanism that converts a capable platform into adopted production systems, and the leading AI labs are backing that view with serious capital. Skeptics argue it is a strong way to land and prove a deployment but a weaker way to run software over the long term, pointing to ongoing cost, the risk of lock-in, and deployments that deliver visualization rather than genuinely new capability.

The useful read is where the fault lines actually sit. The critique is rarely that embedding fails outright. It is that execution quality and domain depth decide whether an engagement produces durable value or an expensive dashboard, and that a practice staffed without domain judgment tends toward the latter. That is a question about how the practice is run, not whether the model works, and it is the question worth asking of any team that claims to do this.

Common questions

Frequently asked questions

What is forward deployed engineering?: Forward deployed engineering is the practice of a platform company embedding its own engineers inside a customer to build, ship, and operate a production system, then feeding what that work teaches back into the product. A forward deployed engineer is the person; forward deployed engineering is the discipline and the team. Companies use the gerund form deliberately when they name the function rather than the individual, as in Anthropic's Manager, Forward Deployed Engineering and OpenAI's Forward Deployed Engineering team.
How is the practice different from the individual role?: The role describes what one person does inside one account. The practice describes how the work is organized, staffed, and repeated across many accounts. The practice adds three things the role alone does not: a division of labor between the engineer who builds and a counterpart who owns the engagement, a repeatable engagement shape that turns each deployment into reusable product, and a way to scale delivery past the number of engineers a company can hire directly. Reading a posting, a title built on the practice form is usually about building or leading the capability; a title built on the person is usually about doing the work in an account.
How is a forward deployed engineering team structured?: The recurring structure pairs a builder with a coordinator. At Palantir the pairing was a Delta, the engineer who wrote production code, and an Echo, the deployment strategist who owned adoption and stakeholder reality. The same split reappears at the frontier labs under different names: Anthropic pairs Forward Deployed Engineers with Engagement Managers who own delivery logistics and stakeholder management, and OpenAI runs a Technical Deployment Lead who owns the delivery plan across FDEs, researchers, and customer engineers. The two functions are constant across companies; the title for the coordinator half is not yet settled.
How does a forward deployed engagement work?: A typical engagement embeds a small team, scopes one or two high-value problems against the customer's real data and constraints, builds in production rather than in a demo environment, and then codifies what worked into playbooks, templates, and reusable components before handing toward long-term ownership. The practice is defined less by any single engagement than by the loop between them: the discipline exists to make the next deployment cheaper than the last by abstracting the last one into product.
How does forward deployed engineering scale?: Three patterns are visible. A company can hire engineers directly, which is how the model started but is hard to scale against enterprise demand. It can stand up a separately-capitalized delivery company, which is what OpenAI did with the OpenAI Deployment Company and Anthropic did with its enterprise-services firm, both announced within a week of each other in May 2026. Or it can credential outside partners to run the same motion under a shared production bar, which is the approach AWS took with its Partner-Led Forward Deployed Engineering motion. The three answers trade control against reach differently.
Which companies run a forward deployed engineering practice?: Palantir originated it. Among the AI platforms, OpenAI and Anthropic both run named Forward Deployed Engineering functions, and Amazon has stood up a Forward Deployed Engineering organization at AWS. The practice has spread fast enough that the naming, the team structure, and the scaling model are now observable across several companies at once rather than at any single originator.
Does forward deployed engineering specialize by industry?: Yes, increasingly. OpenAI staffs separate Forward Deployed Engineering teams for distinct verticals, including semiconductor, financial services, and government, each hiring for the domain knowledge and compliance surface that sector requires. The operating model stays constant across verticals; what changes is the domain the embedded team has to learn and the environment it deploys into, which for regulated data often means running inside customer-controlled infrastructure rather than a public endpoint.
Is the forward deployed model proven, or is it contested?: Both are true and worth stating plainly. Supporters point to it as the mechanism that turns a capable platform into adopted production systems, and the leading AI labs are investing heavily in it. Critics argue it is a strong model for landing and proving a deployment but a weaker one for running software long-term, citing ongoing cost, lock-in, and the risk of shipping visualization rather than new capability. The fault lines in that debate are execution quality and domain depth, not whether embedding works at all.

Methodology and sources

How this reference is compiled

This is an independent resource. The account of the practice is synthesized from public job listings and primary company announcements, and every structural claim rests on more than one company's own material rather than on any single commentator's framing. Where a figure or a pattern comes from a single source, or is reported rather than published by the company itself, this reference states it as such or leaves it out.

Structure · Anthropic and OpenAI forward deployed engineering postings; Palantir team model
Scaling · OpenAI and Anthropic May 2026 delivery-company announcements; AWS partner motion
Role · the forward deployed engineer reference on this site