What Forward Deployed Engineers Actually Do, and Why Companies Embed Operators Instead

"Forward deployed engineer" went from a title almost nobody used to one that OpenAI, Anthropic and Google are all hiring for. If you have seen it and were not sure whether it means consultant, solutions architect, or something genuinely new, here is the plain answer.

The short version

A forward deployed engineer is a software engineer who works inside one customer's business instead of on a product used by many customers. They write real production code. They just write it against that customer's systems, that customer's data, and that customer's constraints, usually while sitting with them.

The cleanest way to see the difference is this. A normal software engineer builds one capability for many customers. A forward deployed engineer builds many capabilities for one customer.

Everything else about the role follows from that one swap.

Where the role came from

Palantir created it in the early 2010s under the internal codename "Delta". It worked well enough that until around 2016, Palantir had more forward deployed engineers than it had regular software engineers. When Foundry launched that year, many of them moved back into traditional engineering roles.

That history tells you what the role is actually for. Palantir sold software into organisations with messy data, strict security rules and no appetite for a six month integration project. Putting an engineer inside the building was simply faster than writing documentation and hoping.

What they actually do all day

Less glamorous than the title suggests, and more varied than most engineering jobs.

• Customer project work. The bulk of it. Building and shipping workflows that run on the customer's own infrastructure.
• Product work back at base. When a deployment hits a gap in the core product, the forward deployed engineer is the one who found it, so they often fix it.
• Scoping and translation. Working out what the customer actually needs, which is rarely what they asked for.

Palantir engineers describe weeks that look nothing alike. One week is mostly code review, like any engineering job. The next is mostly sitting with a client working out where a project goes next. Expect roughly a quarter to half the time on the customer's site, sometimes in genuinely awkward environments: airgapped systems, factory floors, places with no internet.

Why the AI labs suddenly want them

OpenAI went from two forward deployed engineers to more than ten across eight cities. Ramp runs about fifteen, organised in pods. Salesforce, John Deere, Commure, Gecko Robotics and Lindy are all hiring for the same shape of role.

The reason is not that models became harder to use. It is that the distance between "the model can do this" and "this runs in our company" turned out to be enormous, and that distance is filled with legacy software, compliance rules, and workflows nobody designed with AI in mind.

A model demo takes an afternoon. Making it work against a twelve year old ERP system, with a security team asking reasonable questions, takes somebody in the room.

There is a second benefit the labs care about. At OpenAI, forward deployed engineers built the evaluation criteria for voice models while deploying them, which improved the product for everyone. The engineer sent to make one customer succeed comes back knowing exactly what is broken.

What it pays

Recruiting analyses put OpenAI's forward deployed engineer range at roughly $350,000 to $550,000. Treat that as reported rather than confirmed, since the labs do not publish it. The direction is not in doubt though: it is priced like senior engineering, not like consulting.

When you actually want one

Worth being honest about, because the role is not a universal answer.

A forward deployed engineer is the right call when a vendor's product is central to what you are building and the integration is the genuinely hard part. You have bought the thing. It needs to work inside systems the vendor has never seen. Someone who knows that product deeply, sitting with your team, is the fastest path.

It is the wrong call when the hard part is your own people. If your teams are not using the tools they already have, if nobody owns the workflow, if last year's pilot is still a pilot, then an engineer from a vendor cannot fix that. They will ship something excellent that gets used by four people.

The part nobody says out loud

A forward deployed engineer is sent by a vendor. Their job, in the end, is to make that vendor's product succeed inside your company.

That is not an accusation. It is just the arrangement, and it is a good arrangement when the product is genuinely what you need. But it shapes every decision they make. When there is a choice between the answer that uses more of the product and the answer that uses less, you can guess which one gets built.

It also means the capability leaves when they do. The systems stay. The ability to build the next one does not.

The idea behind forward deployment is right. Shipping the product is not the same as the customer succeeding with it. The incentive is what needs fixing.

The version we run: Operator in Residence

We took the same idea and changed who the embedded person works for.

An Operator in Residence is a senior builder who embeds with your team one to two days a week and turns the AI prototypes your people have already built into systems the company actually runs. Not a vendor's product specialist. Not a contractor you rent by the hour.

Three differences that matter:

• No product to sell. We are not trying to increase your usage of anything. Whatever tooling fits your team is the tooling that gets used.
• Your people built the backlog. We only offer it after an Accelerator or an Audit, because the work is getting your team's own prototypes into production. Without that backlog there is nothing to embed around.
• The capability stays. Your team built the thing. They can build the next one when we leave.

It is $18,000 per month with a three month minimum, which is $54,000 for a 90 day cycle. That is deliberately the same as what a fractional Chief AI Officer commands. The difference is the deliverable: governance and sequencing authority in one case, shipped production systems in the other.

Frequently Asked Questions

What is a forward deployed engineer?

A forward deployed engineer is a software engineer embedded with one customer to build and ship production software inside that customer's systems. The role was created at Palantir in the early 2010s and is now common at OpenAI, Anthropic, Ramp and Salesforce. Unlike a normal engineer who builds one capability for many customers, a forward deployed engineer builds many capabilities for one.

Is a forward deployed engineer just a consultant?

No. A consultant recommends, a forward deployed engineer writes and ships production code. The confusion is fair though, because both are customer facing and both are sent in from outside. The test is simple: at the end of the engagement, did software get deployed, or did a document get delivered?

How much does a forward deployed engineer get paid?

Recruiting analyses report roughly $350,000 to $550,000 at OpenAI. The AI labs do not publish official ranges, so treat that as an estimate. It is benchmarked against senior software engineering rather than consulting.

Which companies hire forward deployed engineers?

Palantir remains the largest employer. OpenAI has more than ten across eight cities, up from two. Ramp runs about fifteen. Salesforce, John Deere, Commure, Matta, Gecko Robotics and Lindy also hire for the role.

What is the difference between a forward deployed engineer and an Operator in Residence?

A forward deployed engineer is sent by a software vendor to make that vendor's product succeed inside your company. An Operator in Residence is embedded to make your team succeed with whatever tooling fits, and ships the backlog your own people already built. The first leaves you with the vendor's systems running. The second leaves you with your team able to build the next one.

Do I need to hire one?

Only if the hard part is integration. If the hard part is that your teams are not using AI in their actual work, an embedded engineer from a vendor will not change that. Start by working out which problem you have.

If your team has built things in a training programme and none of it reached production, that is the gap we were built for. Book a call and tell us what is sitting in the demo folder.