Forward Deployed from first principles: why AI companies hire the Palantir way

A general product meets a customer it has never seen. Why that gap creates a job, what the job costs, and what it should measure.

Thesis: A forward deployed team exists because a general product cannot see one customer’s data, workflow and politics from outside, and it earns its cost only while each deployment leaves the product able to do the next one with fewer people.

Start from zero

A company sells one product to many customers. Each arrives with data in its own systems, a workflow nobody wrote down, and people whose jobs change if the product works. For the product to create value there, five things must be true.

Someone finds the problem worth solving, tied to a number the customer already tracks.
Someone gets the data: negotiates access with its owners, cleans it and puts it where the product can reach it.
Someone proves the product works on this customer’s cases, not the demo’s.
People change how they work, and the team whose work moves agrees to it.
The vendor learns something the next customer does not have to pay for.

A sales call cannot do the first four, and a product team in another city cannot see them. So someone goes and sits with the customer. The fifth item separates that person from a consultant.

Artificial intelligence (AI) makes every step harder. A model knows nothing about a customer’s rules until someone connects them, and because its answers vary, “it works” must be shown on the customer’s own cases.

The primitives

Two kinds of engineer. Palantir’s 2019 post “Dev versus Delta” names its two largest engineering roles. Devs, software engineers in Product Development, own parts of its platforms. Deltas, Forward Deployed Software Engineers in Business Development, deploy those platforms for one customer and measure success by that customer’s goal. In the post’s words, a Dev’s focus is “one capability, many customers”, a Delta’s “one customer, many capabilities”.

Field work becomes product. Nabeel Qureshi, a Palantir forward deployed engineer (FDE) from 2015, describes FDEs on customer sites three to four days a week, writing fast, hacky code that product engineers then generalised. Much of the Foundry platform began as tools automating FDEs’ manual work.

A strategist beside the engineer. Palantir’s Deployment Strategists find the customer’s biggest problems and the data behind them, train users and carry field lessons back to product. The posting asks for experience with tools such as Python, R or Structured Query Language (SQL).

The copies. On 26 October 2026, AI companies’ job boards show the same split:

OpenAI lists Forward Deployed Engineers in more than a dozen cities and judges them by production adoption, workflow impact, and evaluation results that change product and model roadmaps.
Anthropic lists Forward Deployed Engineers in London, Paris and Munich, and a Staff Forward Deployed Engineer in the United States (US).
Scale AI hires Deployment Strategists and Forward Deployed Product Managers, who must tell whether the product is the bottleneck or the execution is.
Sierra hires strategists and product managers for Agent Development; Decagon hires Agent Product Managers and Agent Deployment Engineers.

Fortune, citing Lightcast data, reported forward deployed engineer postings up more than 1,000% in January to August 2026 on a year earlier, against 13% for tech postings overall.

Follow one deployment

A hypothetical, to show the order of work: an AI agent for a mid-sized insurer’s claims team.

Diagnose. Sit with claims handlers, then agree with leadership on one or two workflows, each tied to a tracked number such as days to settle a claim.
Get access. Policy documents, claim histories and the claims system each have an owner and a security review. Qureshi on Palantir’s deployments: “The obstacles were mostly political.”
Build the evaluation before the agent: several hundred past claims, each with the decision a good handler made, scored the same way every week.
Ship a thin version to a few handlers. Read every failure, fix it, rerun the evaluation.
Change the work. Train the team. Decide which outputs a person reviews and who answers when the agent is wrong.
Prove it against the baseline. Here a pilot becomes a contract or ends.
Hand back two things: a system the insurer can run alone, and a note to the product team separating what was custom from what the next insurer will need.
Expand to the next workflow. Palantir’s 2020 listing prospectus calls this arc Acquire, Expand and Scale.

Where the money is

Palantir has the longest public record of this model. Its prospectus sorted customers into Acquire (pilots at little or no cost, under $100,000 of revenue a year), Expand (over $100,000, losing money on the account) and Scale (over $100,000, making money). Contribution margin is revenue less cost of revenue and sales and marketing, excluding stock-based compensation.

Palantir customers in 2019	Revenue	Contribution margin
Acquire	$0.6 million	Loss of $65.4 million
Expand	$176.3 million	Minus 43%
Scale	$565.7 million	55%
All customers	$742.6 million	21%

Two lessons. First, pilot staff were booked under sales and marketing, so gross margin looked like software, 67% in 2019, in a year Palantir lost $579.6 million. Gross margin alone cannot show whether field work pays. Second, the same Expand customers reached plus 35% in the first half of 2020: the investment pays back only if the account grows.

For Palantir it did. Qureshi puts its 2023 gross margin at 80%, against 32% at Accenture; in the second quarter of 2026 it was 84.7%, on revenue of $1.935 billion, up 93%.

Andreessen Horowitz (a16z) argued in 2025 that AI application companies should accept the same early dip: ServiceNow’s gross margin at its initial public offering (IPO) was 63.2% and Workday’s 54.1%, and by 2024 they were 79% and 75%. Sell services at cost, it says, and grow gross profit rather than chase 80% margins in year one.

The labs have now split the bill. In May 2026 Anthropic formed a services company for mid-sized firms with Blackstone, Hellman & Friedman and Goldman Sachs, reported at $1.5 billion, and OpenAI raised $4 billion for a Deployment Company. Both keep their own FDEs and put extra delivery work in firms co-owned with private equity.

So when does field work become product? When a custom piece built twice gets absorbed by the product team, as Foundry’s tools were; when time to first value falls, as when Palantir in 2023 reorganised its selling around bootcamps of five days or less instead of pilots of one to three months; and when revenue grows faster than deployment headcount. It is a consulting trap when every contract needs the same team, field code lives in private copies, the roadmap follows the loudest customer, and renewal depends on the team staying.

What is hard, and what I would do in the first 90 days

The hard parts are not code: saying no without losing the account, getting data from an owner who gains nothing by sharing it, and getting people to change how they work.

I have not run a deployment. In revenue management at Air India Express, I measured what each fare and inventory change actually did to a route’s revenue, and turned that into decisions with Network Planning. A baseline, a number after, a cost per unit: that is the habit I would bring. In the first 90 days I would measure:

Days 1 to 30: baseline and time sheet. For each workflow, the customer’s own number before anything ships. For each account, the team’s hours across scoping, data access, building, evaluation and change management. Without the first, no result means anything; without the second, nobody can tell product from services.
Days 31 to 60: evaluation and adoption. A scored evaluation set from real cases, run weekly, and the share of intended users active each week. A model nobody uses has not been deployed.
Days 61 to 90: reuse and cost to serve. The share of what we built that went into the shared product or a playbook, and deployment hours per dollar of contract value. If the second customer takes as many hours as the first, it is consulting.

If by day 90 one workflow has moved against its baseline, the customer trusts the evaluation, and the next deployment is cheaper than the last, the role is doing what Palantir designed it to do.