FDE SERIES · PART 1ENGLISH EDITION中文版本 →

Why Anthropic and OpenAI bet billions on the same twenty-year-old job

#FDE#Anthropic#OpenAI#Palantir

FDE series, part 1 — Kezhongke （壳中客）, a nonprofit research community. Sources linked inline; research current as of August 2026.

On the same day in May 2026, Anthropic and OpenAI each announced a new company.

Anthropic formed a joint venture with Blackstone, Goldman Sachs, and H&F, valued at roughly $1.5 billion. OpenAI's new entity was reported to be raising $4 billion — its first acquisition: 150 engineers from a British consulting firm. Different backers, different structures. Underneath both sits the same organizational invention, first developed at Palantir two decades ago: the forward deployed engineer.

An FDE is an engineer who works inside a customer's environment, writes production code, owns a business outcome, and carries what they learn back into the product.

The demand curve is hard to ignore. Business Insider counted 643 FDE job postings in April 2025 and 5,330 a year later — up 729%. LinkedIn data suggests a 42x increase from 2023 to 2025. Google compressed its FDE interview loop to two rounds in two days. a16z called it the hottest job in AI.

FDE job postings, up 729% in one year

FDE job postings grew from 643 in April 2025 to 5,330 in April 2026. Data: Business Insider.

At Kezhongke, we work in the open: when a topic gets hot, we go read the primary sources. This time that meant the actual job posts from Anthropic, OpenAI, MiniMax and Tencent, a full-length retrospective by Bob McGrew — Palantir's second engineer and later OpenAI's chief research officer — and hundreds of practitioner comments. This essay answers three questions: what an FDE is, why this is happening now, and why most imitators will fail.

What an FDE actually is

The most accurate job description on the market is Anthropic's own posting.

The role sits on the Applied AI team and "embeds directly with our most strategic customers," shipping production applications built on Claude. The deliverables are specific: MCP servers, sub-agents, and agent skills that run in production workflows. Twenty-five percent travel. Base salary $280,000–$320,000.

One sentence in the posting is easy to miss, and it defines the role: "identify and codify repeatable deployment patterns, and contribute insights back to our Product and Engineering teams."

That sentence separates the FDE from three neighboring roles.

From a sales engineer: the sales engineer works the top of the funnel, proving the product can work before the contract. The FDE works the bottom, making it actually run after.

From a consultant: consultants are paid for deliverables and leave at handoff. FDEs are measured by whether the system keeps running — and they write production code, not slide decks.

From a software engineer: an SWE builds one capability for many customers. An FDE enables many capabilities for one customer.

Levels.fyi compressed it best: every customer deployment is a mini startup, and the FDE is its CTO.

Where the FDE sits

The FDE sits closest to the customer while still writing production code. Based on Anthropic's official JD and levels.fyi analysis.

Where it came from: an invention of necessity

The FDE was not designed. It was forced into existence.

In 2003, Palantir began building data systems for U.S. intelligence agencies and hit three constraints at once. The customers — the CIA, the Department of Defense — could not let data leave their networks, so SaaS was physically impossible; engineers had to go in. The customers' work was classified, so they could not answer "what exactly do you do"; traditional product discovery failed, and engineers had to sit at the customer's desk and watch. And Palantir's platform was configurable rather than finished, so the customers themselves did not know what they wanted.

So Palantir built two field roles: Deltas, engineers who deployed onsite — "to hell with generalizability," as one alum put it — and Echos, domain experts who managed the relationship. The product team back home did the opposite of the Delta's job: they abstracted what the field discovered into platform capabilities that could serve the next ten customers.

McGrew describes it as road-building. FDEs lay down gravel roads against real problems; the product team paves the most-traveled ones into superhighways. Deployment is not a cost center. It is product discovery.

The Palantir loop

Palantir's product-discovery loop: FDEs lay gravel roads in the field; the product team paves the most-traveled ones into highways.

For over a decade, Wall Street dismissed this as consulting in disguise. One detail shows how contrarian it was: until 2016, Palantir had more forward deployed engineers than product engineers. The turn came that same year, when Foundry launched for commercial markets and field knowledge began flowing back into the platform — ontology, permissions, workflow engines, most of it grown from the needs of two hundred-odd customer sites rather than from roadmap meetings.

Net revenue retention climbed toward 150%. Market cap went from $16 billion in 2020 to nearly $500 billion at its peak. a16z's reading: the software was not the moat — the FDE loop was, because it made retention compound.

a16z coined a second useful term. In 2011 Palantir rebranded its integration engineers as "forward deployed engineers," call sign Delta. They call it title arbitrage: a new name can meme an organizational change into reality. Half of today's FDE wave is the sequel to that story.

Why now: the better the model, the harder the last mile

MIT's NANDA initiative studied 300 public enterprise AI projects and found that 95% of pilots produced no measurable P&L impact. The bottleneck was not the models. It was deployment.

Traditional software is deterministic: most risk sits before delivery, and a system that passes testing usually keeps working. AI systems are probabilistic. A model that behaves well in testing degrades slowly in production — no error messages, just quietly less reliable answers, and user trust draining away. Neither license sales nor fixed-scope consulting pays anyone to stay and fix that.

Meanwhile the gap between capability and adoption keeps widening. McGrew's view: model capabilities will keep improving fast, while enterprise adoption lags far behind — and the FDE opportunity lives exactly in that gap. Box CEO Aaron Levie put it more bluntly in a widely read thread: deploying an agent is not deploying software. Software behaves the same way every time; an agent deploys work output itself. The model drifts, best practices change monthly, and deployment becomes continuous engineering.

The deepest reason is category vacuum. In SaaS, every product category came with a known market definition. Today "building an AI agent" can mean a thousand things, and even the vendors do not yet know which ones matter. When that is true, product discovery can only happen inside the customer. The FDE is that discovery mechanism, scaled: do things that don't scale, at scale. Solve one of the CEO's top five problems, earn the right to find the next one — land and expand. Pricing follows: not per seat, but per outcome. You are not selling an installation. You are selling a solved problem.

Supply and demand have found each other. YC-linked startups went from zero FDE postings two years ago to over a hundred. OpenAI reportedly assigns FDEs only to customers above $10M in annual recurring revenue. Customers willing to pay for outcomes, and engineers willing to go onsite, have met at the same price point.

The loop closes: model capabilities overflow, enterprise adoption lags, and between them lies a stretch of road with no map. The FDE is the guide.

Why most imitators will fail

The skepticism is as loud as the hype, and three strands of it deserve to be taken seriously.

First, the rebranding charge. "Isn't this just pre-sales?" asked critic Ed Zitron, in the most-replied challenge under Levie's thread. Chinese communities say "premium outsourcing." Gergely Orosz of The Pragmatic Engineer has tracked a real slide: the FDEs he met in mid-2025 were genuine hybrids of platform engineering and solutions work; many newer postings are indistinguishable from solutions architect roles — roughly 25% coding, 50% integration, 25% meetings.

Second, the incentive critique. Orosz notes that OpenAI and Anthropic house their FDEs in separate companies, which means those engineers share none of the parent company's upside: "If the role were core, the company would employ them directly, as before." Hasura co-founder Tanmai Gopal raises a harder, technical objection after a year of doing FDE work himself: the shared context that makes an AI colleague reliable lives in many heads, changes daily, and is prohibitively expensive to capture. He is no longer sure FDEs can fix the last mile they were hired to fix.

Third, the practitioners' own warnings — one person holding five roles, brutal context-switching across customers, chronic overtime. That strand is about career choice, and we leave it for part three of this series.

So who should actually hire FDEs? Across interviews with Palantir alumni investors and FDE team leads, four thresholds are emerging:

  • The customer's problems are genuinely complex and the workflows ill-defined — otherwise the FDE degenerates into an expensive pre-sales rep.
  • Contract values can grow from a $50K pilot to seven figures — otherwise the math cannot support a $220K–$400K engineer.
  • Code written in the field flows back into the product — otherwise it is pure labor, and margins never turn.
  • The platform is stable at 1.0 — otherwise FDEs become firefighters patching product gaps.

Missing any one of the four is enough to fail. Flybridge partner Chip Hazard lists five common "concept-borrowing" moves: retitling pre-sales as FDE, burning out junior generalists with three jobs at once, pulling FDEs into product bug-fixing, sending them to $50K accounts, and fly-in-fly-out "deployments" that never build trust. A widely shared Chinese analysis put the conclusion in its headline: 95% of companies shouldn't hire FDEs, and couldn't afford them anyway.

Four thresholds before hiring FDEs

Four thresholds before hiring FDEs: problem complexity, contract growth, code reflux, platform 1.0. Missing any one is enough to fail.

What happens next

Will FDEs stay this expensive? Probably not.

OpenAI executives have conceded the model is transitional: the goal is to carry customers through the complex early phase until they can run themselves. Palantir shipped an AI FDE in 2026 — an agent that translates natural language into platform operations, handling standardized work like data integration and ontology edits, explicitly positioned as an assistant to human FDEs. One emerging configuration: one senior FDE plus two or three AI assistants, covering five to ten times the customers.

In road terms: once gravel roads are traveled enough to be paved into highways, the road crew thins out. But the road-building itself does not end. One prediction circulating at AI Engineer conferences: the boundary between product development and forward deployment is dissolving, and soon every engineer will be expected to solve real customer problems. The title may cool off. The skill bundle it defined — engineering, business translation, ownership of outcomes — is becoming table stakes.

And then there is China, where vendors are racing to hire FDEs for reasons only half-shared with the U.S. The American FDE was summoned by models too new to deploy themselves. The Chinese FDE is pinned in place by data that legally cannot leave the building. That is the subject of part two.

Kezhongke （壳中客） is a nonprofit research community. Parts two and three of this series — on Chinese vendors, and on whether this job is right for you — are being developed in the open. If you have firsthand FDE or enterprise AI deployment experience, we would like to hear from you.

Sources