Where the role comes from and why AI companies revived it
Explain why a company selling one general model puts an engineer in a customer's building, using the filing that named the role and Moore's whole product.
On this page
An AI company sells one model through one API, the same for every customer, and then hires engineers to spend eight weeks in a single customer's building. The arithmetic looks wrong until you see what the customer is actually buying. The role has a documented origin in a public filing, a reason it went out of fashion for a decade, and a 1991 marketing book that explains the economics of its return.
The embedded engineer, in the filing's own words
The name comes from Palantir, and the clearest description of the job is in the company's 2020 registration statement, Palantir Technologies Inc., Form S-1 (opens in a new tab). The filing describes forward-deployed engineers embedded with users, on site or remotely, deploying the software against each institution's own data and systems, and presents the field as where the product improves: the problems are specific to each institution, the engineers see them first-hand, and what they learn is built into the platforms rather than into one-off applications. It is also candid about the cost: many pilots run at the company's expense, and the improvement in its results is credited mainly to cutting the time and the number of engineers each deployment needs.
Three things carry over: the engineer is measured on the customer's working deployment, not on a feature; the work is done where the data is; and the first deployment at a customer is bought, not built once and sold many times. That last point is why the role went out of fashion. The software economics of the 2010s were product-led — build once, sell to thousands, let the customer integrate through an API — and an engineer-week at one customer is sold once and never again. For a decade the sensible answer was to remove the person.
The model is general; the customer's data and workflow are not
The person came back because of a property of the product. A hosted model API will read any claim, contract or ticket you give it. What it has never seen is the claims floor from a week in the role: 340 pages of policy wording in PDFs, a 40-column export with three date formats, a policy number reused across policy years, a high-value rule that lives in the head of underwriting, and 28 handlers running a workflow nobody wrote down. None of that is in the model, and none of it can be, because it belongs to one customer.
The gap between "the model can read a claim" and "median triage fell from 11 minutes to 7.7" is integration, data, an eval against the customer's definition of good, and a rollout the customer's own on-call can run. Those are engineer-days, and they fall where the diagram shows.
The figures are an assumption and your deployment will differ; the shape is the point. The only work that touches the model directly is the prompt and its context, about four days in forty. Everything else is the customer's data, reviewers and operations, which no product team at headquarters can do for a customer it has never visited.
The failure that proves it is the demo on sample data: thirty hand-picked claims the model reads beautifully, then a pilot that fails on the real export because 30% of claims cite a policy year whose wording changed and the sample had none. The three-day prototype runs on their data for exactly this reason, and failure modes on real data lists what the real export does to a prompt that passed the demo.
The last mile is the product
Geoffrey Moore's Crossing the Chasm gives the economics a name. The generic product is what ships in the box. The whole product is everything the customer needs to get the outcome they bought for: integration, data, training, support. Early adopters buy the generic product and build the rest themselves; the pragmatist majority buys only the whole product, with references, and the chasm between the two markets is where products die.
For an AI deployment the generic product is the model, and the rings are the bars in the first diagram. An insurer or a bank is a pragmatist buyer: it will not build the rings itself, and it will not buy until the whole product works on its own 200 cases. The forward-deployed engineer builds the whole product for one customer, by hand, so that the pragmatist can buy. Three mechanisms sit behind the revival.
First, the generic product became general. One API serves claims, contracts and support tickets, so what all of a vendor's customers have in common is the inner box and nothing else; every ring is customer-specific by construction. Second, the buyer changed: the early adopters built their own rings, and the customers now signing eight-week pilots are the majority. Third, there is no spec until someone writes one in the customer's building. An eval is not a benchmark: the public score measures the inner box, and the only test that predicts whether the pragmatist renews is agreement with their reviewers on their cases, which exists only after discovery.
Why the margin still works
The S-1 economics did not go away; the role manages them. The first deployment on a policy system is bought: forty days, most of them rings. The field note from week 3 — the policy number is reused across policy years on this vendor's system — goes back to product, and the second customer on the same system does not pay for that discovery again. Over customers the rings shrink toward the box. What the deal depends on is the commercial side of the same fact: the pilot fee pays for the rings, the annual contract pays for the box, and the renewal case is written from the pilot's numbers.
This is also how the role is measured. A solutions engineer hands over after the proof of concept; a consultant is measured on the deliverable. The forward-deployed engineer is measured on whether the customer is live, using it, and renews — the "Success" row of the table in FDE and its five neighbours — and, secondarily, on whether the next deployment is shorter because of what this one wrote down.
In an interview
"Why does this role exist at a company that sells an API?" is asked in the hiring-manager conversation, and "what is the difference between you and a solutions engineer?" in the behavioural round. What is being tested is whether you understand that you are the whole product for one customer, that the model-facing work is about four days in forty, and that part of the job is to make yourself unnecessary — here through the handover, at the next customer through the field note. In the role, the customer watches where your days go: a pilot that spends week 3 on the prompt and week 7 on the export has the rings in the wrong order.
The mistake that loses points is describing the role as an engineer who travels, or as pre-sales with a laptop: that answer makes the model the product and the customer's data a detail, and it is the reverse. The strong answer names the rings, says which one takes the most days, and says which one the field note shrinks next time.
Check yourself
1. A prospect says a competitor's model scores two points higher on a public benchmark and asks why they should take a pilot with an engineer attached rather than the cheaper API. What do you say, and when would the benchmark be the right basis?
The benchmark measures the inner box; the pilot's gate is 95% agreement on their 200 cases, which neither model has been measured on, so a two-point gap on a public set says nothing about their cases. Offer the eval as the decision: both models, same cases, their labellers, one week. The benchmark is the right basis when the task is the benchmark's task — general, no customer data, no workflow — and then they should buy the API, not a pilot, and you should say so.
2. The first insurer's deployment took 40 engineer-days. The second insurer runs the same policy system. Estimate the second deployment, and name the bars that shrink.
Data plumbing shrinks most: the export shape, the policy-number reuse and the date formats are in the field note, so 10 days becomes about 4; security questions reuse last time's answers, 3 to 1; the runbook starts from the last one, so rollout goes from 8 to 6. Discovery and the eval do not shrink — their floor, their 200 cases, their reviewers. Roughly 40 becomes 30: 40 − 6 − 2 − 2. If the eval shrank, someone reused the first customer's gold labels, which measures the wrong customer.
3. After five deployments, the product team asks whether to build the export ETL into the product. It took about 6 engineer-days at each customer. Build it?
5 × 6 = 30 days already spent; if the next five customers look like the last five, building once at roughly 15 days saves 15 and every later deployment is 6 cheaper. So build it if the five exports share a shape, and the field notes are the evidence: four of five on the same policy system means build; five different exports means the "ETL" was five programs, and what belongs in the product is the canonical schema, not a pipeline.
Source: Palantir Technologies Inc., Form S-1 (SEC EDGAR, August 2020); Geoffrey Moore, Crossing the Chasm (1991).