Forward Deployed Engineer: definition and role in AI

What is a Forward Deployed Engineer?

The Forward Deployed Engineer lies at the intersection of software engineering, architecture, business understanding, and client delivery.

Unlike a software engineer who primarily works on a product or platform, the FDE directly faces the environment in which the technology must operate: legacy data, processes, existing software, users, and internal constraints.

Their role is therefore not just about developing a feature.

They must understand the problem well enough to decide what to build, and then be technical enough to directly participate in its construction and deployment.

OpenAI, for example, describes its FDEs as being responsible for discovery, technical scoping, system design, construction, and production deployment. Their success is also evaluated based on adoption and impact on workflows.

What does "forward deployed" actually mean?

The term comes from the military concept of being deployed as close to the field as possible.

Instead of escalating a problem through multiple layers — sales, product, consulting, engineering — a portion of the technical capability is placed directly next to the need.

This does not necessarily mean working physically at the client's office.

The key is operational proximity: talking to users, understanding constraints, observing available data, and quickly testing hypotheses in the real system.

The FDE thus shortens the loop:

problem → decision → construction → field feedback.

Why Palantir is associated with Forward Deployed Engineering

The model is historically associated with Palantir, whose software is deployed in complex environments: large organizations, defense, intelligence, or systems combining many data sources.

In these contexts, simply installing software and letting the client adapt it on their own was not enough.

It was necessary to understand how the organization operated, connect existing systems, adapt the solution, and sometimes build directly around the product.

The term has since spread beyond Palantir. AI companies like OpenAI and Anthropic are now hiring their own Forward Deployed Engineers.

What does a Forward Deployed Engineer actually do?

There is no perfectly standardized job description.

An FDE at Palantir, OpenAI, Anthropic, or a startup may have different responsibilities.

However, the common framework can be summarized as follows:

business problem → discovery → architecture → construction → deployment → adoption → iteration

Understanding the problem before building

A request expressed by a company rarely perfectly describes the problem to be solved.

A sales team might, for example, ask:

"We want an AI agent that automatically qualifies our leads."

Building this agent immediately would be a mistake.

First, one must understand:

• how leads come in;

• where their information is stored;

• how qualification works today;

• which data is reliable;

• which decisions can be automated;

• which actions must remain under human control.

The diagnosis might reveal that the main problem is not the absence of AI, but a poorly structured CRM or qualification criteria that have never actually been defined.

The FDE must be able to make this distinction before coding.

Designing and building the solution

Once the problem is understood, the FDE does not simply hand off a specification document to another team.

They can design the architecture, prototype, develop integrations, work on data, and contribute directly to the code needed for deployment.

At OpenAI, the role explicitly includes building systems and directly contributing to code when it accelerates delivery.

This continuity between understanding the problem and building is one of the most important characteristics of the model.

Deploying with users and observing real-world usage

A solution can be technically correct and yet fail.

An AI agent can work in a demo but never actually be used.

A CRM can contain all the right data but be bypassed by the sales team.

An automation can save a few minutes while creating an unmaintainable system.

Therefore, the work does not stop when the solution is functional.

The FDE remains close enough to the field to observe its use, identify bottlenecks, and modify the system.

The loop becomes:

build → use → observe → fix.

Forward Deployed Engineer vs Consultant, Software Engineer, and Solutions Engineer

The FDE borrows characteristics from several existing roles. The boundaries remain fluid depending on the company.

This table remains intentionally simplified.

A technical consultant might code daily. A Software Engineer might be extremely close to users. A Solutions Engineer might also support a project all the way into production.

The interesting difference is therefore less the title and more the combination of responsibilities.

FDE vs Software Engineer

A Software Engineer generally builds a product or a platform designed to serve many users.

The Forward Deployed Engineer starts more from a problem encountered in a specific client context.

This creates a useful tension.

The FDE seeks to quickly resolve the actual problem. The product team must prevent every request from turning the platform into a series of custom developments.

A good Forward Deployed organization must therefore feed recurring patterns back to the product team.

FDE vs Solutions Engineer

The distinction is more subtle.

A Solutions Engineer may already perform technical discovery, design architecture, build demos, and work directly with client teams.

In some companies, the two roles overlap heavily.

The FDE is generally distinguished by having greater responsibility for construction and taking systems into production, whereas the Solutions Engineer often focuses more on evaluation, pre-sales, or solution architecture.

However, titles remain highly variable depending on the company.

FDE vs Consultant

Portraying the FDE as "the one who builds, unlike the consultant who makes slides" would be a caricature.

Many technical consultants actually design, implement, and deploy systems.

The interesting difference lies in the sought-after continuity between:

understanding the problem → architecture → construction → production → field feedback.

In some organizations, these responsibilities are divided among several profiles.

Forward Deployed Engineering seeks precisely to shorten this chain.

And the GTM Engineer?

The GTM Engineer also belongs to this new generation of hybrid roles.

They generally work on the Go-to-Market system: CRM, commercial data, enrichment, automation, integrations, and sometimes AI agents.

The similarity to the FDE lies in the ability to understand a business process and then build directly.

The difference is primarily in the scope of application.

The GTM Engineer specializes in Revenue and Go-to-Market workflows. The FDE is historically linked to deploying a technology product at client sites and can intervene in much broader issues.

Why Forward Deployed Engineers are making a strong comeback with AI

The concept existed long before generative AI.

But current conditions give it a particular relevance.

AI rarely works like software you just install

A company can access the exact same models as thousands of other organizations.

This does not mean they will know how to build a useful system with them.

The value depends largely on:

• the chosen workflow;

• accessible data;

• the context provided to the model;

• integrations;

• permissions;

• evaluations;

• authorized actions;

• how users actually work.

Two companies using the same model may therefore need very different systems.

The problem is no longer just technical

The question is often no longer:

"Can we use AI to do this task?"

But rather:

Where does AI actually add value?

Which part of the workflow must remain deterministic?

What data can we feed it?

How far can it act autonomously?

How do we control its outputs?

What happens when it makes a mistake?

This is why deploying AI often requires profiles capable of speaking both with business teams and technical teams.

The architecture of an enterprise AI agent is not decided solely based on the model's capabilities. It depends primarily on the system in which this agent must function.

The field can improve the product

The Forward Deployed model is not just about customizing a solution for each client.

Deployments also make it possible to identify recurring problems.

OpenAI notably expects its FDEs to turn observed patterns into reusable tools, playbooks, or components, and to feed field learnings back to the product and research teams.

The loop then becomes:

product → client → real problem → solution → learning → product.

This dimension distinguishes Forward Deployed Engineering from a simple integration service.

Can the Forward Deployed model apply beyond software engineering?

We must distinguish here between the job of a Forward Deployed Engineer and the Forward Deployed work model.

A CRM consultant or an Ops specialist is not automatically an FDE.

The roles offered today by OpenAI or Anthropic remain demanding engineering functions, responsible for technical systems deployed in production.

On the other hand, the principle of bridging business understanding, architecture, construction, and adoption can be applied much more broadly.

From Forward Deployed Engineering to operations

Let's take a SMB that wants to rebuild its CRM.

A highly fragmented organization might operate like this:

management → consultant → specifications → integrator → configuration → training → support

With each handoff, a portion of the context can be lost.

A more integrated approach looks more like:

observe the process → identify the real problem → design the data model → configure the CRM → automate → test with users → fix

The profile guiding the company must then understand operations well enough to challenge requirements, and technology well enough to directly implement a major part of the solution.

This person is not necessarily a Forward Deployed Engineer.

But the delivery logic is similar.

CRM, business tools, and Ops: the same fundamental question

Let's take a company that uses Attio for its CRM and Airtable for its delivery.

The difficult topic is not whether the two tools can be connected.

It is determining:

• which data actually belongs in the CRM;

• which data should live in the operational tool;

• what information actually needs to be synchronized;

• at what point a delivery event becomes a sales signal;

• where a classic automation is sufficient;

• where AI actually adds value.

It is the same logic as when designing a CRM truly adapted to the business process: starting from how the company operates before choosing the architecture.

Adding more technology is not necessarily an improvement.

Sometimes, the best architecture actually consists of removing a synchronization or keeping a workflow within a single tool.

The value of the hybrid profile is therefore not their ability to stack technologies.

It is their ability to understand the problem, make trade-offs, and then build the corresponding system.

Does the Forward Deployed Engineer signal an evolution in consulting?

The title "Forward Deployed Engineer" may perhaps remain primarily associated with tech companies.

But the model reveals a broader evolution.

As tools become more accessible and AI accelerates the ability to build, the boundary between the person who advises and the person who executes is blurring.

This does not mean a single profile must know how to do everything.

Complex systems will continue to require specialists.

But on many projects, reducing the distance between business understanding, architecture, and construction significantly accelerates the delivery loop.

Ultimately, Forward Deployed Engineering promotes a simple idea:

the people who build systems benefit from directly understanding the field where those systems will be used.

And those who recommend an architecture benefit from remaining close enough to its construction and usage to verify that their decisions actually work.

Whether for CRMs, business tools, operations, or AI, this logic is probably more interesting than the new title that brought it back to the forefront.

Frequently Asked Questions about the Forward Deployed Engineer