History / Three eras of the forward deployed engineer
A short history of the forward deployed engineer.
The role has three eras, and most guides only describe the first two. Palantir invented it in the early 2010s under the codename Delta. The model labs revived it in 2024 to 2025 to win the application layer. A third era, vendor neutral studios, splits off in 2025 over a single structural question: what survives after the engineer leaves.
Direct answer (verified 2026-05-02)
The forward deployed engineer role was invented at Palantir in the early 2010s under the internal codename Delta, named after the NATO alphabet letter for the Business Development team it grew out of. By 2009 Palantir had 120 of them; up until roughly 2016, the company had more forward deployed engineers than traditional software engineers. The role crossed into the model labs in 2024 to 2025 (Anthropic hired explicitly under the title "Forward Deployed Engineer, Applied AI" through 2024, and Colin Jarvis launched OpenAI's dedicated FDE team at the start of 2025). A third generation, vendor neutral studios that leave the eval harness and runbook in the client's repo, splits off from the model lab pattern in 2025.
Sources reviewed: The Pragmatic Engineer (Colin Jarvis interview), Anthropic Applied AI FDE job posting, a16z, Trading Margin for Moat.
The timeline, in five entries
Three eras and the two events that bookend them. The dates are the public record. The framing of three eras is mine: every guide on this topic stops at the model labs adopting the role in 2024 to 2025, and misses the structural split that followed.
2003. Palantir founded.
Peter Thiel, Alex Karp, Stephen Cohen, Joe Lonsdale and Nathan Gettings start Palantir to sell software to intelligence agencies. The customers cannot openly describe what they need. There is no normal product discovery loop. The role does not exist yet.
Early 2010s. The role gets a name: Delta.
Palantir formalizes the embedded engineer pattern. The internal name is Delta, after the NATO alphabet letter for the Business Development team that birthed it. The bet is that an engineer sitting inside the customer for months can solve a problem that a remote product team cannot.
2009 to 2016. The platform era peaks.
By 2009 there are already 120 forward deployed engineers at Palantir. Up until ~2016 there are more FDEs at the company than traditional software engineers. The role exists to land Palantir's platform: Gotham first, then Foundry. The engineer is the bridge from the platform to the customer outcome.
2024 to 2025. The model labs rediscover it.
Anthropic builds out an Applied AI team and explicitly hires "Forward Deployed Engineer, Applied AI" across San Francisco, New York, London, Paris, Boston, Chicago, Seattle and Washington DC. Colin Jarvis, then a Solutions Architect at OpenAI, presents the business case for an OpenAI FDE team at the start of 2025. The team launches with two engineers and grows past ten across eight cities.
2025 onward. The vendor neutral studio era.
A third shape appears: small studios that send named senior engineers into a client's repo for two to six weeks, with an explicit no-platform-license, no-vendor-runtime contract. The leave behind is the eval harness, the runbook, the rubric, and the CI/CD workflow in the client's repo. The model layer is whatever the client wants. fde10x is one of these.
Era 1. Palantir, 2010 to 2016. The platform era.
Palantir was founded in 2003 to sell software to intelligence agencies. Conventional product discovery did not work; the customers could not openly describe what they were trying to do. The fix was structural: put engineers directly inside customer environments and let them learn by observing, experimenting, and building.
By the early 2010s the embedded-engineer pattern had a name. Delta (after the NATO alphabet letter for the Business Development team it came out of) was both the internal title and the cultural identity of the people doing the work. The external title became Forward Deployed Software Engineer. By 2009, the company had already grown the role to 120 people. Up until roughly 2016, Palantir had more forward deployed engineers than traditional software engineers, which is the most important sentence in the history of the role: Palantir bet the company on the pattern.
The 2016 inflection was Foundry, Palantir's integrated data platform. With a real product to ship, more FDEs rotated back to core software engineering, bringing field experience into the platform. The role did not shrink, but it was no longer the company's center of gravity.
“By 2009, Palantir had 120 forward deployed engineers; up until circa 2016, more FDEs than traditional software engineers.”
Palantir history, summarized in The Pragmatic Engineer (2025)
The era 1 contract is implicit: Palantir wins by selling its platform and uses Deltas to land it. The work the FDE writes for a customer is encoded as Foundry pipelines, ontologies, and operational workflows. The artifacts need the platform to keep running. The customer keeps paying for the seat.
Era 2. The model labs, 2024 to 2025. The application layer race.
Foundation models commoditized faster than the application layer that uses them. By 2024, choosing between Claude, GPT, Gemini, or an open weight model on Bedrock was a swap, not a strategy. The lab that won the seat in the customer's roadmap won the inference. The cheapest way to win the seat was an engineer.
Anthropic moved first under the title. Through 2024 and into 2025 the company was hiring "Forward Deployed Engineer, Applied AI" across San Francisco, New York, London, Paris, Boston, Chicago, Seattle and Washington DC. The job description names the work explicitly: embed with strategic customers, ship MCP servers and sub-agents, deliver white glove deployment support for Claude in production.
OpenAI's version of the team launched at the start of 2025 after Colin Jarvis (then a Solutions Architect who had joined in 2022) presented an internal business case. The team started at two engineers and grew past ten across eight cities. Other model and tooling companies (Cohere, Surge AI, the larger AI consultancies) followed within months.
The macro framing was a16z's "Trading Margin for Moat" piece in 2025: enterprises buying AI "want to use it, but they need you to set it up." The argument was that PLG was the wrong default; the right default looked like Salesforce, ServiceNow and Workday, who all built implementation services into their growth motion and let gross margins climb later. ServiceNow went from 63.2 percent gross margin at IPO to 79 percent by 2024. Workday went from 54.1 percent to 75 percent. The moat paid for the margin compression.
“Enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up.”
a16z, Trading Margin for Moat (2025)
The era 2 contract is also implicit, and structurally different from era 1. The vendor wins by binding the customer to its model family. The FDE is the binding agent. The artifacts are portable as code, but they hard code an SDK boundary that runs through one company's API. Switching vendors after the engagement is rewriting agent code, re-running evals, and re-doing the production cutover. The customer keeps paying for inference on one vendor's family.
Era 3. Vendor neutral studios, 2025 onward.
A third shape appears in 2025, in response to the structural problem with era 2. A small number of studios send named senior engineers into a client's repo for two to six weeks under a contract that says out loud: no platform license, no vendor attached runtime, the IP is yours. The leave behind is what makes the engagement different.
The leave behind is four artifacts in the client's repo. An agent code base, with the orchestration framework chosen for the problem and committed to the repo, not pinned to a vendor's hosted graph. An eval harness with cases drawn from real production traces, with per-axis ground truth and stakes tags. A rubric file (we use rubric.yaml on main, scored on five axes) that is the gate the model has to clear to ship. A workflow file (.github/workflows/pilot-gate.yml) that runs the rubric on every PR and on a weekly cron. Plus a runbook for the on call team that owns the system after the studio leaves.
The model layer is whichever the client picks. Anthropic, OpenAI, Bedrock, Vertex, Azure OpenAI, or an open weight model running on the client's GPUs. The orchestration is open source (LangGraph, Pydantic AI, a custom DAG) so the team that owns the system after handoff can swap pieces without calling the studio back. The runtime is the client's cloud, behind the client's keys.
The era 3 contract is the explicit one. The studio's revenue is the fixed fee for the engagement; nothing has to keep being paid after handoff for the system to keep running. fde10x is one of these studios. The reason this page exists is that nobody else was framing the role as three eras with a structural split in the third.
What survives the SOW, by era
The history of the forward deployed engineer is a history of which artifacts the customer owns when the engineer leaves. Era by era, the answer changed. This is the question worth asking in every 2026 buying conversation that involves an embedded engineer.
| Feature | Era 1 (Palantir) and Era 2 (model labs) | Era 3 (vendor neutral studio) |
|---|---|---|
| Who writes the code in your repo | Era 1 (Palantir): platform engineers configuring Gotham or Foundry inside the customer environment. Era 2 (model labs): an Applied AI engineer building on Claude, GPT, or the lab's own SDK. | Era 3 (vendor neutral studio): a named senior engineer from the scoping call, on the SOW, writing PRs in the client's GitHub on day one. |
| What survives after the engineer leaves | Era 1: a Palantir platform contract; the work is encoded as Foundry pipelines and ontologies that need the platform to run. Era 2: production traffic against the lab's API; switching the model means rewriting agent code and re-running evals. | Era 3: the agent code, the rubric.yaml, the .github/workflows/pilot-gate.yml, the eval cases, the runbook. All four artifacts in the client repo. Model swappable at the SDK boundary. |
| What you keep paying for | Era 1: a per-seat platform license that has to keep being paid for the work to keep running. Era 2: per-token API spend on one vendor's family, plus the implicit cost of staying on it. | Era 3: nothing tied to the studio. Inference goes to whichever provider the client picks. There is no recurring license, no vendor runtime, no seat fee that has to keep flowing. |
| Where the agent runs after handoff | Era 1: the platform's runtime, often the platform's cloud. Era 2: the model lab's API, on the lab's roadmap. | Era 3: the client's cloud, the client's keys, the client's VPC. The engagement does not own the runtime. |
| What the buyer's actual 2026 question is | Era 1: do I want Palantir? (Yes if you are a government or a Fortune 50; the FDE comes attached.) Era 2: do I want my Applied AI engineer from Anthropic, OpenAI, Cohere, or someone else? (The engineer pulls the team deeper into one vendor's stack.) | Era 3: which artifacts do I get back, and can the system keep running if the studio, the model vendor, and the orchestration framework all change in the next eighteen months? |
Why this history matters in a 2026 buying call
Most guides on the forward deployed engineer end with "and now the AI companies are hiring them." That is the easy half of the story. The harder half is that the role has fragmented into three contracts that look identical from the outside (a senior engineer, in your building or your Slack, for a few weeks) and behave very differently from the inside.
The decision in 2026 is not "do I want a forward deployed engineer." The decision is which generation of the contract you want, which translates to which artifacts you want in your repo eighteen months after handoff. An era 1 contract leaves you on a platform. An era 2 contract leaves you on a model vendor. An era 3 contract leaves you with code, an eval harness, a rubric, a workflow, and a runbook, and lets the rest move.
That is the framing we use on every fde10x scoping call. The hour is free. You leave with a written one pager that names the engineer, the production outcome, the data sources, the rubric you will be graded against in week 2 and week 6, and a fixed fee. Whether you ever sign with us or not, the one pager is the era 3 buying spec.
Want a named senior engineer in your repo on week 1?
Sixty minutes with the engineer who would own the build. You leave with a written one pager: the outcome, the data sources, the rubric, and a fixed fee. The week 2 cancel and refund clause is in the MSA.
Frequently asked questions
Where did the forward deployed engineer role come from?
Palantir invented it in the early 2010s under the internal codename Delta. The customer base was intelligence agencies that could not openly describe what they needed; a remote product team had nothing to build against. Palantir put engineers inside the customer environment to learn, observe, and build in real time. By 2009 there were already 120 of these engineers; up until roughly 2016, Palantir had more forward deployed engineers than traditional software engineers.
Why is the role called Delta at Palantir?
Delta is the NATO phonetic alphabet letter for D. In Palantir's early days, each team in Business Development was named after a letter in the NATO alphabet, and the embedded-engineer team kept the Delta name as it grew into a formal role. The external title is Forward Deployed Software Engineer (FDSE).
When did OpenAI and Anthropic start hiring forward deployed engineers?
Anthropic was hiring under the explicit "Forward Deployed Engineer, Applied AI" title through 2024 and into 2025, with open positions across at least eight cities. OpenAI's dedicated FDE team launched at the start of 2025 after Colin Jarvis (then a Solutions Architect) presented the business case; the team began with two engineers and has since grown past ten across eight cities globally.
What is the difference between a Palantir FDSE and an Anthropic Applied AI FDE?
Palantir's Delta configures Palantir's platform (Gotham, Foundry) inside the customer; the work is encoded as Foundry pipelines and ontologies that need the platform to keep running. Anthropic's Applied AI FDE builds production applications on Claude, ships MCP servers and sub-agents, and provides white glove deployment support; the work is portable as code but binds the team to one model family. The two roles share the on-site shape and almost nothing else structurally.
Is there a third generation of forward deployed engineering?
Yes. As of 2025 a vendor neutral studio era is emerging. The shape is the same (a named senior engineer in the client's repo for two to six weeks), but the contract is structurally different. There is no platform license. There is no vendor attached runtime. The leave behind is the agent code, an eval harness with cases drawn from production traces, a rubric.yaml on main, a .github/workflows/pilot-gate.yml workflow, and a runbook. The model vendor is whichever the client picks (Anthropic, OpenAI, Bedrock, Vertex, Azure OpenAI, or open weight). fde10x is one of these studios.
Why are AI companies hiring this role specifically now?
Foundation models commoditized faster than the application layer. As a16z framed it in 2025, enterprises buying AI "want to use it, but they need you to set it up." The model lab that wins the application layer wins the seat, and the cheapest way to win the application layer is an engineer inside the customer for a few weeks. The structural pattern is the same one Salesforce, ServiceNow and Workday used to build their moats: trade margin for moat by doing the implementation work yourself.
Did the FDE pattern exist before Palantir?
Embedded engineers existed long before Palantir, in different forms (IBM systems engineers from the 1960s, contract engineers at defense primes, professional services teams at every enterprise software vendor). What Palantir did in the early 2010s was give the pattern a name, an internal title, a career ladder, and a thesis: that the engineer is the product distribution mechanism, not the salesperson.
How do I tell which generation of FDE I am hiring?
Ask one question: when the engineer leaves, which artifacts are in our repo, and which are not? If the answer involves a platform license, a hosted runtime, or a proprietary framework that has to keep being paid for, you are hiring an era 1 FDE. If the answer involves a model vendor your team did not pick and an SDK boundary that runs through one company's API, you are hiring an era 2 FDE. If the answer is the agent code, the rubric, the eval cases, the workflow, and the runbook in your repo with the model swappable behind the SDK, you are hiring an era 3 FDE.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.