What a Forward Deployed Engineer Actually Does

On this page

1. What the Role Actually Is
2. Why the Job Had to Be Invented
3. The Role Is Not New
4. The Test That Says Whether the Job Is Real
5. Why Anyone Pays for This
6. Or You Have Just Joined a Dev Shop
7. The Ratchet That Makes It Work
8. Why an Old Idea Is Suddenly Everywhere
9. How to Tell a Real One From a Dev Shop With a Better Title
10. The Case Against the Role
11. Glossary
12. The Bottom Line
13. References
14. Footnotes

Three years ago, almost nobody outside Palantir had the words on a business card.

Now “forward deployed engineer” sits on job postings at OpenAI, Anthropic and Salesforce, usually shortened to FDE. In May 2026 OpenAI launched a separate company built around the role, with more than four billion dollars behind it.¹

Few people have built one of these teams more times than Kevin Bai, who scaled Palantir’s forward deployed function, founded the same one at Rippling, and now works on Anthropic’s Applied AI team. The framework below is his, from his AI Engineer talk “Forward Deployed Engineering 101”.² Stranger still, he spends most of it talking you out of the model. What he delivers is not a recommendation but a test, and most companies fail it.

A real forward deployed role and an ordinary contract development job wearing a nicer title look identical from the outside. Only one is a good place to spend three years.

Not a consultant, not a sales engineer

What the Role Actually Is#

Asked at the end of his talk for the perfect profile, Bai gives the line he clearly wanted to leave the room with. A forward deployed engineer is nothing more than a customer facing software engineer. Someone you would hire onto your engineering team, who you would also trust in front of a customer. The rest, he says, you figure out as you go.

That definition is doing more work than it looks, mostly through what it excludes.

A pure consultant advises and then leaves, where this role stays and ships. The sales engineer demonstrates a product but never writes the production code behind it. And an ordinary product engineer may be excellent while never once meeting a customer. The forward deployed engineer is the overlap: someone who writes real code and sits in the room where the problem lives.

Day to day, the split is roughly a quarter to a half of the time on site. Palantir expects around 25 percent of a forward deployed engineer’s time with customers; Commure expects up to 50 percent.³ On site the work is monitoring, debugging, deploying and configuring. Back at the office it is writing code changes and reviewing pull requests, like any other engineer.

The hiring bar is genuinely unsettled. Palantir has hired people with as little as a year of experience after college. Other companies prefer five or more years for senior forward deployed roles. So if you are wondering whether you are experienced enough, the honest answer is that the industry has not agreed either.

A platform nobody can use

Why the Job Had to Be Invented#

To understand the role you have to understand the specific commercial problem that produced it.

Palantir sells a platform called Foundry. Foundry pulls a company’s data into one place and builds an ontology on top of it. An ontology means turning data into proper nouns. Instead of table one, table two and table three, a company that owns warehouses gets a single definition that is the source of truth for what a warehouse is, and applications get built on top of that.

Now try selling it. Bai’s point is that when you describe this to a business leader, the honest reaction is: you have made my data organised, so what? Organised data is not an outcome. It is an implementation detail.

There is a second problem, and it is worse. Foundry is a platform for building applications, so its value depends entirely on whether the customer can build with it. That means the customer pays twice. They pay for the platform, then they pay again in time and salary to train their people until those people are good enough to produce anything. Only after both payments does any value appear.

Bai’s verdict on the first row is blunt. Customers are paying to invest in the platform, and they also need to train their people to get effective on it, and then and only then can they build things. That, he says, is a terrible way to do business.

The fix was to stop selling either thing on its own. Not software alone, not consulting hours alone, but both fused into one thing. The customer is buying neither a licence nor a person’s time. They are buying a result.

In practice that means sending capable engineers into the customer’s business to learn how it actually works, then building the solution for them. Bai’s analogy is fine dining. The waiter is there to handle whatever you need, and you do not go into the kitchen. If you run a consumer packaged goods company, you care about shelf placement and units moved. You do not care how the data is modelled, and his view is that you should not have to.

Older than it looks

The Role Is Not New#

It is easy to assume this job was invented in 2026 alongside everything else with “AI” in the posting, but it was not.

Palantir was founded in 2003 and spent its early years selling its Gotham platform into intelligence agencies, where normal requirements gathering was close to impossible. Customers could not describe their own work, because the work was classified. You cannot write a specification from a conversation nobody is allowed to have. Sending engineers in was not a clever go-to-market play. It was the only way to build anything at all.

Exactly when the role was formalised is less settled than most coverage suggests, and this is worth flagging rather than papering over. The best-sourced account, based on interviews with people who have done the job, puts its creation in the early 2010s under the internal name “Delta”.⁴ Several widely-shared blog posts instead date it to around 2005, but those trace back to no primary source, and one of them contradicts itself within a few paragraphs. Bai himself hedges in the talk, guessing Palantir came to market “like 2004 or 2005”, which is close but a year or two late on the founding.

What is solid is the shape of it. Foundry, the platform Bai describes, did not launch until 2016. And up until roughly that same year, Palantir had more forward deployed engineers than ordinary software engineers.⁴ For over a decade, the field organisation was the larger half of the company.

Two axes, one square

The Test That Says Whether the Job Is Real#

This is the centre of the talk, and it is the thing worth carrying out of it. Bai lays the decision out as a grid, which he calls a Punnett square, with two questions: how technical is the thing you sell, and how technical is the person buying it.

Why was Palantir stuck in the top right? Because a platform for building applications is not very interesting to companies that already have strong engineers. Google and Meta build whatever internal tools they want. But a Fortune 500 oil and gas company has deep expertise in hydrocarbons, not in data pipelines. That customer will never extract full value on its own.

So Palantir offered the other path. We will lend you excellent engineers you do not have to recruit, hire, manage or retain, and they already know the platform cold.

The four million dollar number

Why Anyone Pays for This#

Bai’s argument that the model works is contract size. Average contract value is what a single customer spends with a vendor each year, and among large public software companies he ranks it like this.

He adds that no public software company he checked even reaches half a million, and notes that Palantir reached its valuation with only a few thousand employees. That last claim is not verifiable from public data at that precision, so take it as his impression rather than a finding.

The scale, though, is not in doubt. Palantir reported second quarter 2026 revenue of $1.935 billion, up 93 percent year over year, with US commercial revenue up 149 percent, and raised full-year guidance to a midpoint of $8.154 billion.⁵ Whatever you conclude about the model, it is not being run by a company that is struggling.

The difference that decides everything

Or You Have Just Joined a Dev Shop#

Here is the part that matters most if you are considering one of these jobs.

Bai frames forward deployed engineering as a design partnership at enterprise scale. Early stage startups already do this. You do not know what your product is, the customer does not know what they are buying, so you work alongside them, absorb their context, and build them something good. That is how most business software finds its footing. Palantir’s assertion was that there is no rule saying this has to stop after the early days.

The obvious objection is maintenance. Build something bespoke for every customer and you end up herding cats across fifty five repositories nobody wants to inherit. Bai agrees completely, and this is the sharpest line in the talk. If you implement a forward deployed function where each engineer is building entirely from scratch, he says, you do not have a forward deployed function. You have a dev shop.

He is careful to add that a dev shop is not a bad business. It is a different business, with different economics and a different valuation. The single thing separating the two is whether the engineers are assembling from shared building blocks or starting from an empty file.

What gets promoted

The Ratchet That Makes It Work#

Asked how you decide which work belongs to the platform and which stays with the customer, Bai’s rule is short. Anything bespoke and unique to one customer should exist only for that customer, while anything that can be generalised should be generalised over time.

He adds a point that is easy to miss. When you start, you will not have many building blocks, and that is fine, because the deployments themselves are how you find out which ones are worth building. Forward deployed work is a scouting mechanism for the product roadmap. The engineers in the field are not just delivering. They are discovering what the product should become.

Asked how granular a building block should be, Bai declined to give a universal answer, and the honest version is useful. In some industries you can ship pieces so robust that the application is 60 percent built before anyone arrives, and the customer work is the remaining 40 percent. Elsewhere the situations vary too much for that, so you need very fine-grained tooling instead.

His reference point is cloud infrastructure. You could buy server racks and run them yourself, but almost nobody has done that since the 1990s. AWS gives you a managed database so you never invent one from scratch. The granularity is set that low because AWS serves an extremely broad range of customers. Yours depends on how broad your own user base is.

Why now

Why an Old Idea Is Suddenly Everywhere#

Bai’s closing argument is his own hypothesis, and he labels it as such. The world has not collectively realised Palantir was right. What changed is the nature of software itself.

Nearly every platform is now agentic. Agentic means the software acts on its own behalf across your systems rather than waiting for a person to click through it. That makes nearly every platform deeply customisable, which reopens exactly the gap Palantir faced: a powerful, configurable product and a customer with no clear idea what it does or how to apply it to their business. Leave the outcome to their implementation skills and selling upmarket gets very hard.

You will recognise the practical version of this if you have worked on any AI project in the last two years. The demo is beautiful, the pilot is promising, and then the thing meets real data and stops.

That gap is what the hiring is for. OpenAI’s deployment entity describes the work as embedding engineers into organisations with complex problems, working with business leaders and frontline teams to find where AI helps, redesigning the workflows around it, and turning that into durable systems.¹ Anthropic runs its version under the Applied AI team, which is where Bai works. Salesforce runs pods that sit with a single enterprise customer for roughly three months at a time, building on Agentforce.

Questions to ask them

How to Tell a Real One From a Dev Shop With a Better Title#

Bai aims his two questions at founders deciding whether to build the function. They work just as well pointed the other way, at a company interviewing you. Same test, opposite direction.

Question one: do they have to sell something technically complicated to a non-technical buyer?

If the answer is no, ask what the role is really for. A technical buyer absorbs complexity themselves, and a company selling to one has better options in developer relations. Where the product is simple and the buyer is not technical, an ordinary sales motion serves better again. If neither condition holds and they are still hiring forward deployed engineers, the title may be doing marketing work rather than describing a function.

Question two: do they have a platform, or are they genuinely funding one?

This is the one to press on, because it is where the answer gets vague. Ask what the shared building blocks are, then ask for an example of something built for one customer last year that three of them use now. Finally, ask what fraction of a new deployment is assembled rather than written, and whether that fraction is going up.

If nobody can answer, you have the answer. Bai is blunt here: however tempting revenue-generating engineers look, without shared building blocks underneath them you are in for a very bad time. The maintenance burden is heavy even with a robust platform, and unmanageable without one. As a candidate, that burden lands on you.

That fourth signal deserves a moment, because it is a trap that no one designs on purpose. If a deployment team is measured on utilisation, they are economically punished for automating themselves out of work. Building the shared block that removes a task permanently lowers next quarter’s billable hours. So the incentive quietly favours doing it by hand again, which is precisely the opposite of the ratchet the whole model depends on. Commission-based pay for forward deployed engineers pushes the same way, toward short-term custom fixes.

Who disagrees

The Case Against the Role#

Bai gave an introductory talk, so he did not spend time on the case against. It exists, it is serious, and taking a job in this field without having read it would leave you with half the picture.

The most useful criticism comes with an actual number. F-Prime Capital argues that if more than 30 to 40 percent of deployments require significant forward deployed effort, the problem is no longer go-to-market, it is product design. Past that line you are not a software company with a services arm, you are becoming a services company. Their sharpest observation is that when “we’ll just throw an FDE at it” becomes an organizational reflex, product debt accumulates silently.⁶

The same piece makes a point that pairs badly with Bai’s contract-value evidence. Forward deployed engineers often make a company’s metrics look better externally and worse internally. Deployment work done before a sale inflates the real cost of acquiring a customer without being tracked as such, so a company can badly overestimate how efficient its selling actually is. Their recommendation is to force an honest split in the accounts between software margin and deployment margin.

Then there is the customer’s view. Anaplan chief executive Charlie Gottdiener accepts that forward deployed engineers are good at the early part. They do a very good job, he says, of showing up and doing a proof of concept. His objection is what happens next. The customer now has engineers they have to pay for and rely on in perpetuity, and if they want to make a change, they have to pay for that too. It is very hard to get off the platform. What gets delivered, in his view, is often visualisation and business intelligence rather than genuinely new capability. He expects the approach to run its course as buyers catch on. His summary: a good selling model, and not a great model for running the software.⁷

Andreessen Horowitz takes the opposite side, framing early margin damage as a price paid deliberately. Their evidence is that the enterprise software companies now worth the most went through exactly this. ServiceNow had a 63.2 percent gross margin at its initial public offering and Workday just 54.1 percent, both well below what investors expect from software. By 2024 those had reached 79 percent and 75 percent.⁸ Their phrase for why customers need this at all is the clearest sentence in the whole literature: enterprises buying AI are like your grandmother getting an iPhone, in that they want to use it but they need you to set it up.

Reference

Glossary#

Forward deployed engineer

A software engineer who works inside the customer’s business rather than at the vendor’s office, building the thing the customer actually needs on top of the vendor’s platform.

Ontology

A layer that turns raw tables into named business things. Instead of table one and table two, you get a single definition of what a warehouse is that everything else refers to.

Primitive

A reusable building block on the platform. Something an engineer assembles with instead of writing from scratch for each customer.

Dev shop

A business that builds custom software to order, starting fresh each time. A real business, but a different one, with different economics.

Average contract value

How much a single customer spends with a vendor per year. Often shortened to ACV.

Design partnership

An arrangement where a vendor builds closely alongside one customer to work out what the product should be. Normally an early-startup habit.

Gross margin

What is left of revenue after the direct cost of delivering the product. Software companies are expected to run high; services companies do not.

Proof of concept

A small working demonstration built to show that something is possible, usually before a contract is signed. Often shortened to POC.

Go-to-market

How a company actually reaches and sells to its customers. The sales motion, not the product.

Sales-led motion

Selling through a sales team rather than letting users find and adopt the product themselves.

Utilisation

The share of an employee’s hours billed to a customer. A standard services metric, and a hazardous one here.

Agentic

Software that acts across your systems on its own behalf rather than waiting for a person to click through it.

The takeaway

The Bottom Line#

A forward deployed engineer is a software engineer who works where the problem is. That is the whole job description, and it is a good one. You see how businesses actually run, which is knowledge most engineers never get, and you build things that visibly matter to someone within weeks rather than quarters.

What decides whether it is a good job is not the title, the travel or the salary band. It is whether the work you do for one customer makes the next customer cheaper to serve. That single loop separates a role where you compound into something valuable from a role where you maintain fifty five repositories that nobody else will ever touch.

The good news is that you can check. Ask what the shared building blocks are and ask for an example of one that came out of last year’s customer work. A company with a real platform will answer immediately, because that promotion is the thing they are proudest of.

Bai’s talk is worth watching in full: Forward Deployed Engineering 101.

Sources

References#

Figures and dates below are snapshots verified 2026-08-07 against the cited sources. Where a claim comes from the talk itself rather than an independent source, the body says so explicitly.

Footnotes#

1. OpenAI, “OpenAI launches the OpenAI Deployment Company,” May 2026. openai.com. ↩ ↩²

2. Kevin Bai, “Forward Deployed Engineering 101,” AI Engineer, 2026. youtube.com. ↩

3. Gergely Orosz, “What are Forward Deployed Engineers, and why are they so in demand?”, The Pragmatic Engineer. pragmaticengineer.com. ↩

4. The Pragmatic Engineer, as above, for the “early 2010s” origin, the internal name “Delta”, the 2016 Foundry launch, and the FDE-to-engineer ratio holding until circa 2016. pragmaticengineer.com. ↩ ↩²

5. Palantir Technologies, “Q2 2026 results,” 2 August 2026. sec.gov. ↩

6. Rocio Wu, “The Uncomfortable Truth About FDEs,” F-Prime Capital, 6 February 2026. fprimecapital.com. ↩ ↩²

7. Steve Banker, “Palantir And Forward Deployed Engineering: What Should We Believe?”, Forbes, 10 July 2026. forbes.com. ↩

8. Joe Schmidt, “Trading Margin for Moat,” Andreessen Horowitz, 4 June 2025. a16z.com. ↩