Why I’m writing this
I kept seeing job postings from OpenAI and Anthropic for a role called Forward Deployed Engineer (FDE), paying noticeably more than a regular SWE, with a job description that reads like a Rorschach test: write code, but also “understand the business,” and also “be embedded with customers long-term.” Turns out the role has a 20-year history — it’s Palantir’s original playbook, and every AI lab is now copying it. This post untangles what FDE actually is, where it came from, how it differs from adjacent roles, and whether it’s worth chasing.
The one-sentence definition
An FDE is an engineer a company embeds long-term at a customer site, who ships production code inside the customer’s real systems from day one, and feeds what they learn back into the company’s own product.
Three keywords matter: embedded (not a business trip — a deployment), production code (not slides, not a demo), and feedback loop (what you learn at the customer has to make it back into the product roadmap). Miss any one of the three and it isn’t really an FDE role.
Where it came from: Palantir’s “Delta”
FDE isn’t a 2026 invention. Palantir created the role around 2005 for intelligence-community customers like the CIA and NSA, internally code-named “Delta” — one customer, many capabilities.
The gap at the time was obvious:
- Consultants could articulate what a customer needed, but couldn’t ship production code — their deliverable was a report and a slide deck;
- Traditional solutions engineers could build a demo, then handed it off to a professional-services team and weren’t on the hook for the outcome;
- Government customers ran closed, sensitive systems that outside integrators simply couldn’t touch at the core.
Palantir’s answer: send its best engineers directly inside the customer, owning everything end to end — from data ingestion and modeling to how the business actually uses the system to make decisions. Around 2016, Palantir’s FDE headcount briefly exceeded its regular software-engineering headcount; the ratio only came back down once Foundry matured as a platform product and standardized away some of that work.
How FDE differs from adjacent roles
| Compared to | The difference |
|---|---|
| Consultant | A consultant delivers a report and recommendations; an FDE ships a working prototype on day one |
| Solutions Engineer / Architect | The latter hands off to professional services after the demo, closer to consulting; an FDE owns everything from data ingestion to the business decision it enables |
| Systems integrator | Palantir’s model explicitly rejects “subcontracting” — an FDE is company headcount, not an outside vendor |
| Platform / product engineer | A platform engineer writes generic features against abstract requirements; an FDE writes code against one specific customer’s specific business, then abstracts the reusable parts back into the product |
What the day-to-day actually looks like
A typical FDE engagement runs 8 to 16 weeks on-site (remote/hybrid variants are increasingly common):
- Week one: build the customer’s own “ontology” — translating their business concepts and data structures into a model the system can reason about;
- 5 to 15 deep customer conversations a week, not routine syncs, but genuine problem-digging sessions;
- “Customer discovery” is treated as part of the engineering job, accounting for 30-40% of total work — a task usually owned by PMs or customer-success managers in a traditional SWE role;
- OpenAI’s version of the role runs roughly in three phases: early scoping → validation → delivery.
What skills it takes
Technical:
- Solid full-stack engineering fundamentals;
- Applied AI/ML, especially RAG pipeline design (vector stores, chunking strategy, reranking);
- Agent development (frameworks like LangGraph / LangChain);
- Building evaluation frameworks (catching hallucination, catching drift);
- Production monitoring (logs, latency, token spend);
- Cloud infrastructure and security/compliance.
None of this is theoretical — a few real open-source projects give a pretty good feel for what an FDE deals with day to day:
- LangGraph: one of the most widely used agent-orchestration frameworks right now; building a customer-specific agent workflow almost always runs into it or something like it;
- vLLM: a production-grade inference engine that shows up in almost every deployment that has to control its own cost and latency — understanding it is what lets you tell whether a customer’s “the model is slow” complaint is actually a model problem or an inference-layer problem;
- n8n: an open-source workflow-automation/integration tool that looks a lot like the “how do we wire up this pile of legacy systems” problem an FDE faces on-site every day — except an FDE usually hand-writes the code instead of dragging nodes.
Skimming the issues and PR discussions on these repos gets you closer to the real engineering problems an FDE deals with than ten job-posting breakdowns ever will.
Soft skills:
- The ability to keep moving forward in ambiguous situations;
- Clear communication that can align with a business audience’s own vocabulary;
- Business judgment — knowing which metrics the customer actually cares about;
- The ability to operate alongside sales and customer-success teams.
Senior openings almost universally require 5+ years of experience, because the role genuinely demands both legs — technical depth and business judgment — to be strong at the same time. That naturally makes the talent pool small.
Why it’s suddenly hot right now
The core tension, in one line: roughly 95% of enterprise generative-AI pilots fail to produce measurable business value — not because the models are bad, but because of a deployment gap.
The customer’s engineers know their data schemas, their compliance requirements, the landmines in their legacy systems. The AI lab’s engineers know how models actually behave in production — how prompting patterns hold up, how to tune a RAG strategy, which scenarios cause a model to go off the rails. Neither side can substitute for the other’s knowledge, no amount of documentation closes that gap, and a customer-success manager can’t fill it either. The only role that straddles both sides is the FDE.
Palantir’s Q1 2026 earnings — 85% YoY revenue growth, 133% growth in commercial revenue — validated that this embedded-deployment model scales and drives customer retention. OpenAI and Anthropic have since copied the playbook almost line for line: engineers as diplomats, embedded on-site, a deliverable on day one, “customer discovery” formalized as an engineering responsibility, a dedicated ontology per customer, FDE feedback driving the product roadmap, and an explicit refusal to act as a pure systems integrator.
The pay backs it up: OpenAI’s mid-level band runs $160K-$280K, Google Cloud $127K-$183K, and while Anthropic hasn’t published numbers, it announced a $1.5B joint deployment venture with Blackstone this past May. a16z calling it “tech’s hottest job” isn’t much of an exaggeration.
My take
Bottom line first: this isn’t really a “more technical” job — it’s a job that asks whether you’re willing to travel long-term and whether you’re willing to be directly accountable for a business outcome.
A few things I’d weigh seriously myself:
- The lifestyle cost is real. Long-term on-site work means your rhythm looks more like consulting than a 9-to-5 engineering job — travel and timezone whiplash become the norm, and job descriptions rarely spell that out.
- The career path isn’t mature yet. Traditional engineering has the IC/EM dual ladder; FDE currently looks more like a “you build your own path” track. Whether it leads to pre-sales architecture, product, or pure technical management still doesn’t have a settled industry answer.
- There’s no exact equivalent title in China yet, but similar work has existed for a while — “delivery engineers,” “implementation architects,” and “solutions architects” on To-B / To-G projects do adjacent work. They just rarely enforce the FDE’s hard rule of “ship production code on day one,” and rarely institutionalize feeding lessons back into a product roadmap.
- The real growth value. If you want to build both “hardcore engineering” and “business judgment” muscles at the same time, FDE is an intense but fast-feedback training ground — more real than writing internal tools or parsing requirement docs, because you’re directly accountable for the customer’s money and outcome.
If the goal is purely a bigger paycheck, I wouldn’t chase this specific path — the intensity and uncertainty aren’t small. But if the goal is to close a business-judgment gap quickly within a few years, FDE — or the pockets of implementation/solutions-architect roles in China that genuinely make you write code and own outcomes — is worth serious consideration.