What's a forward deployed engineer ?

Written by Rajeev Puri

If you've looked at tech job boards lately, you've seen the title "Forward Deployed Engineer" over and over. OpenAI has it. Anthropic has it. So do Palantir, Google, Microsoft, AWS, and the big consultancies. A few years ago most developers had never heard of it, so where did it come from, and why is everyone hiring for it at once?

The short version

A forward deployed engineer (FDE) is a software engineer who works inside the customer's world instead of at their own company's office. You write real code, but you write it for one customer's actual problem, using their data, their systems and their odd constraints. Then you stay until it works in production. It's part engineer, part consultant, and you own the result the way a founder would. The name comes from the military, where forward-deployed forces sit close to the action instead of back at base.

Before Palantir

The idea isn't new. It goes back to the mainframe era, when buying a computer meant buying the vendor's people along with the hardware. According to the Engineering and Technology History Wiki, IBM announced the System/360 on April 7, 1964, replacing five product lines with one compatible family. Monthly rental ran from about $2,700 for a basic setup to $115,000 for a large one, and purchase prices ranged from $133,000 to $5.5 million. Customers placed more than 1,000 orders in the first four weeks. At those prices, nobody was left to figure it out alone. So IBM put people in the building. Customer engineers installed and maintained the machines, and systems engineers helped customers get real work running on them. At Columbia University, two IBM customer engineers were stationed full time in the machine room for the entire life of the university's 360/91, from 1969 to 1980. Training enough service staff was one of the big industry problems System/360 was designed to ease. That's the family tree. An expensive, complicated product does nothing useful until someone sits next to it and makes it fit. The difference is the work itself: those engineers mostly installed, configured and kept things running, while a modern FDE writes new software around the product. IBM wasn't alone. DEC and HP sent field engineers too. When ERP and CRM software took off in the 1990s, firms like Accenture grew by customizing big software suites for each client. Then SaaS vendors pushed the opposite philosophy: configure, don't customize. For a while that made on-site engineers look old-fashioned.

How it started at Palantir

Palantir was founded in 2003 to help intelligence and defense agencies make sense of huge, fragmented datasets, as Stanford's Palantir session describes it. The hard part wasn't only technical. The users couldn't always describe what they needed, the data was sensitive or classified, and workflows changed constantly. A finished product thrown over the wall didn't fit. So Palantir sent engineers to sit with the users. They'd build a rough demo, show it, and sometimes hear "this is terrible" straight to their faces (a story told in StartupHub's FDE playbook). Then they'd fix it and come back. Palantir later described iterating roughly every two weeks based on field feedback. Inside the company there were two big engineering tracks, as Palantir's own blog explains. Devs built the core platforms, Gotham for intelligence work and Foundry for commercial customers, on the principle of one capability for many customers. Deltas were the forward deployed engineers, working on one customer with many capabilities. The name is a leftover from the early days, when each business team was named after a letter of the NATO phonetic alphabet. Deltas were often paired with Echoes, who tended to be domain experts handling relationships and workflows. And when a Delta built something useful in the field, it could flow back into the product. Sources disagree on the exact timeline. Some place the model's emergence in the mid-2000s, others in the early 2010s. One account says Palantir had more FDEs than regular product engineers by 2016, though I'd treat that as unverified. What's clear is that for a long time this was a Palantir thing, and outsiders mostly saw it as an odd, expensive way to build software.

Quiet years, then a slow burn

Through the 2010s the role stayed niche. Palantir wrote about it, ex-Palantir people spread it into other startups, and the Delta job became known as a place where future founders learn. By December 2022, The Pragmatic Engineer was publishing explainers asking what FDEs were and why anyone wanted them. It was still a curiosity.

The AI turn

Then generative AI arrived and exposed a gap. Models were impressive in demos and stubborn in real companies. Data was messy, systems were old, nobody owned the project, and pilots stalled. Selling a model API wasn't enough, so AI companies went back to Palantir's playbook. OpenAI began building its FDE team in late 2024. In 2025 the numbers went vertical. The Financial Times reported that monthly FDE listings rose by more than 800% between January and September 2025. Bloomberry's analysis of about 1,000 postings found 1,165% growth comparing January to October of 2024 and 2025. Venture firm a16z started calling the pattern services-led growth: trade some margin for speed by putting engineers next to customers.

Where things stand today (November 2026)

The role has gone from startup trick to industry strategy, and the money is serious. These figures come mostly from news reports and one trade tracker, so check the originals before quoting them. In February, OpenAI announced alliances with McKinsey, BCG, Accenture and Capgemini to push its enterprise agent platform. In May it launched the OpenAI Deployment Company with more than $4 billion behind it, majority owned by OpenAI, and bought the UK consultancy Tomoro to add about 150 deployment specialists. A week earlier Anthropic had announced its own services arm, and in July it launched Ode with Blackstone and Hellman & Friedman, aimed at mid-sized companies. The cloud giants followed. Reports put AWS's dedicated FDE organization at $1 billion, working in small pods on short sprints. Microsoft is reported to be putting 6,000 engineers inside customer operations. Google Cloud has dozens of open FDE roles, and Accenture planned a 1,000-person FDE workforce around Google's Gemini Enterprise. In October, Anthropic announced a $100 million academy to train 10,000 "Frontier Deployed Engineers" by the end of 2027, and AWS published FDE certifications. Indeed data reported by Business Insider counted 5,330 FDE postings in April 2026, against 643 a year earlier. Not everyone is cheering. Gartner is reported to predict that 70% of enterprises will drop vendor-built agentic AI by 2028 because the cost trap is too big, and estimates only about 2,000 active FDEs today, which is a lot fewer than the postings suggest. Analysts have also called FDEs a crutch that hides immature products, and warned that without real co-design they turn into glorified integrators. a16z says most copycats of the Palantir model fail because they never build the reusable platform underneath, and end up as consultancies with a nicer front end. My read: the demand is real, because getting AI into production inside a messy company is genuinely hard. But the label is being stretched, and some of what's posted under it is closer to support or pre-sales work. The test of whether it lasts is whether deployments get cheaper and more repeatable over time, or just stay custom forever.

What an FDE actually does today

The job changes by company, but a typical engagement starts the same way. A company wants AI to do something real, like answer support tickets, review contracts or route orders, and the model can't do any of it until it can reach the company's own data. So most of the work is plumbing. You connect the model to the places the information actually lives: databases, SharePoint folders, PDFs, internal APIs, and systems like Salesforce or SAP. That data is usually messy, badly documented and sensitive, so the early weeks go into pipelines: pulling it out, cleaning it, fixing schemas and keeping it fresh. For retrieval, you split documents into chunks, create embeddings, load them into a vector store, and tune search and ranking so the model gets the right context. Practitioners keep repeating the same lesson: fix data preparation, permissions and freshness before you touch the model. Then you build the AI layer on top. That means prompts, agents that call tools and recover when a step fails, and guardrails for things like personal data and prompt injection. The good FDEs agree with the customer on what a good answer looks like before building anything, then write the evaluation tests (golden datasets, regression suites, human review for high-stakes cases) so everyone can tell whether a change actually helped. Security shapes everything. Access control has to follow the company's existing permissions, so the model never shows someone a document they shouldn't see, and every step needs logging. Deployments often run inside the customer's own cloud account or on their own servers rather than behind a public API, and you work with their security and legal reviewers instead of around them. After launch you keep owning it: watching latency and cost, fixing what breaks, and writing runbooks so the customer's team can run it without you. Along the way you keep talking to the people who have the problem, because what they really need is often different from what they first asked for. And you tell your own product team what you keep seeing across customers, so the product gets better. That last part matters. An FDE who only does one-off custom work is basically a contractor. The good ones turn patterns into product.

Is it a good career move?

It depends on what you like. If you enjoy ambiguity, talking to people and seeing your code used by someone the same week, it's a great fit. If you want to sit in one codebase and go deep for months, you'll probably be unhappy. Some roles also involve heavy travel, with one OpenAI posting asking for up to 50%. Given the Gartner warning and the title inflation, it's also worth asking how much of the job is coding and whether the engineers feed back into the product. Those two answers tell you whether it's a real FDE role or something else wearing the name.