The forward deployed engineering model puts an engineer who builds inside the customer next to a second person who owns scope, the success measure and adoption. It starts with short scoping on site, agrees success in writing, ships one use case and plans the handover. Palantir invented it. A mid-sized company can borrow most of it.
What follows is built only from what these companies have published: blog posts, job ads, interviews and, for Palantir, its stock-market filing. Their reported results are their own claims, so I leave them out. The structure is the part worth copying.
How does Palantir run forward deployed engineering?
Palantir pairs a builder with an owner, the Delta and the Echo described in what is a forward deployed engineer, and wraps the pair in a commercial model its 2020 filing calls Acquire, Expand and Scale. It runs pilots "generally at our own expense" and calls its field engineers "effectively an arm of our research and development" (Palantir S-1). What the engineers learn at one customer goes back into the product for the next.
One part does not travel: the free pilot. Palantir can fund it because a win turns into years of software licences. A company buying engineering services has no licence business behind the pilot to pay for it.
How does OpenAI run forward deployed engineering?
OpenAI's version is the best documented, through an interview its head of forward deployed engineering, Colin Jarvis, gave The Pragmatic Engineer. It has three phases. Scoping: "A couple of days onsite". Validation, where the success criteria and evaluations are set, ending with "a final report showing eval performance compared to the objectives". Then delivery, on site "typically for a few days per week" (The Pragmatic Engineer).
Two more habits are reported second-hand. Jarvis has described asking leaders to set AI aside and name the biggest levers in their business first, and has said OpenAI's forward deployed engineers have no financial incentive tied to usage, according to TNW's report of his talk at HumanX. Both point the same way: the engineer is there to move a business number, not to sell more of the product.
How does Wonderful run forward deployed engineering?
Wonderful, which builds AI agents for enterprises, publishes the clearest version of the pair. Its pod has a forward deployed engineer who "Makes it work" and a Deployment Strategist who "Makes it matter", owning use cases, metrics, the business case and adoption; the strategist is "measured on customer P&L outcomes" (Wonderful, careers).
Its phases are the most explicit about leaving. They sit under the line "From Wonderful-led to full client ownership, by design": first one use case into production, then builder enablement, then the client taking over production. The middle phase fits in one sentence: "We co-build with your teams and train them as we go, so the capacity to build stays after we leave." (Wonderful)
What do Anthropic, Salesforce and Sierra add?
Anthropic gives the owner a sharper job description. Its Technical Deployment Lead "won't write production code" and takes an engagement from a "signed SOW to a sequenced roadmap with clear milestones, dependencies, success criteria, and value hypotheses" (Anthropic). Salesforce sizes the pod for its Agentforce deployments at "a nimble team of two FDEs and one Deployment Strategist" (Salesforce).
Sierra opens each deployment with "a 90-minute design workshop" and, after launch, writes that "We continue to meet weekly with customer stakeholders" (Sierra). Decagon adds the economics of repetition: "each deployment makes the next agent easier to build" (Decagon).
What patterns do forward deployed engineering teams share?
Lay the companies side by side and seven patterns repeat.
| Pattern | What it means | Who does it |
|---|---|---|
| A builder and an owner | One person writes the code; another owns scope, the success measure and adoption | Palantir, Wonderful, Salesforce, Anthropic |
| Short scoping before any build | Days or hours with the customer, not months of discovery | OpenAI, Sierra, Wonderful |
| Success in writing first | Criteria and evaluations agreed before the build | OpenAI, Anthropic |
| One use case, then expand | Production first, the second use case after | Wonderful, Palantir |
| Judged on the business result | Not on usage, hours or licences sold | Palantir, OpenAI, Wonderful |
| A planned exit | Enablement and handover as named phases | Wonderful |
| Something reusable from each deployment | What one customer teaches goes into the next | Palantir, Decagon |
What can a mid-sized company borrow from the forward deployed model?
Most of it, at a much smaller scale. Here is how I would translate each pattern for a company of 50 to 1,000 people:
- One use case. Not a programme. One process, chosen because it costs something measurable every week.
- A builder and an owner. A senior engineer builds; a second person owns the scope, the success measure and adoption. Without the owner, the engineer slowly turns into someone who takes tickets.
- Scope on site. A morning in the building with the people who run the process, because what a process is called in a meeting is rarely what its data shows.
- Success criteria in writing. A baseline measured before the build, a production milestone and an adoption number, signed off by a named sponsor.
- Part of the week. About three days a week for one use case, close to OpenAI's "few days per week".
- A plan to leave. One of your own engineers pairs from the first week, and the handover leaves you the code, the documentation and the evaluation set.
- One reusable piece. Each engagement leaves a template, an integration recipe or an evaluation suite that the second use case can start from.
Two things are better left with the big vendors: the free pilot, which needs a licence business behind it, and the pod of three. A mid-sized company needs one engineer and one owner who answers for the result. Why it needs them more than another licence is in why AI projects fail without engineers on site.
At Sapio this is the shape we work in. It starts with the contact form on sapio.ro and a short call. Then I send a custom offer, sized to the project's complexity and needs: AI consulting, or the Tech Audit, one morning on site and a report in three working days. After that come a transformation roadmap with the success criteria written down and a senior engineer embedded about three days a week, owning one use case until it runs in production, with me as the owner on our side.
Palantir's shorthand for the Delta was "one customer, many capabilities". For a mid-sized company I would turn it round: one customer, one capability, and a date on which the engineer leaves. The leaving is the part that proves the rest worked.
If you are working out which use case to start with: vladtudor.com/consulting.