What Is a Forward Deployed Engineer? (And Why AI Work Needs One)

A forward deployed engineer, or FDE, is a software engineer who works inside the customer's environment rather than behind a product roadmap. They sit in the client's codebase, data and daily rituals for weeks at a time, find where the technology actually pays off, build it there, and hand it to the team that has to run it afterwards. The role became well known through Palantir and has since spread across AI companies, because in AI work the model is almost never the hard part. The hard part is the last mile: the messy data, the odd workflow, the skeptical team. A forward deployed engineer exists to own that last mile.

If you have ever watched a strong technical vendor deliver something that worked in the demo and died in your environment, the FDE model is the answer to that specific failure.

Related reading: what applied AI actually means, fractional AI team vs. agency vs. Big 4, and why AI pilots fail.

What a forward deployed engineer actually does

Strip away the job-title glamour and the role has four jobs.

Find the real problem. Not the problem in the statement of work. The one the operators complain about at standup. This means interviewing the people doing the work, reading the actual tickets, and looking at the actual data before proposing anything. Most scopes written before anyone touched the data are wrong in at least one expensive way.

Build inside the customer's stack. An FDE writes code in the client's repos, in the client's cloud, against the client's warehouse. Not in a sandbox that gets thrown over a wall later. This is the defining constraint of the role and it is why FDEs need genuine engineering range: you do not get to choose the language, the schema, or the deployment story.

Instrument the outcome. Every build ships with an eval harness and a business metric attached to it. If nobody can say what number moved, the work did not happen. This is also the only defence against the pattern where an AI feature ships, everyone is pleased, and six months later nobody can point to a result.

Land it with the humans. Train the team, write the runbook, sit through the first two weeks of production weirdness. The system belongs to the client after the engagement ends, and a system nobody on the client side can operate is a liability you left behind.

Why AI made this role suddenly popular

AI delivery has an unusual failure profile. The technology mostly works. The organisational fit mostly does not.

MIT found that 95% of AI pilots deliver no measurable business impact. RAND has put the failure rate for AI projects at roughly 80%, around double the rate of other IT projects. McKinsey's consistent finding is that redesigning the end-to-end workflow, not adopting the tool, is the single biggest driver of value from AI.

Read those together and a pattern falls out. The bottleneck is not model quality. It is the distance between a capable model and a specific company's messy reality. Traditional delivery models put maximum distance there on purpose: the vendor's engineers stay home, the client's engineers integrate, and a project manager carries requirements between them. Every handoff loses information, and AI systems are unusually sensitive to the information that gets lost, because the value lives in edge cases, data quirks and workflow detail.

The forward deployed model deletes the handoffs. The person who understands the model is the person standing in the mess. That is the entire idea. Everything else is logistics.

Most of why AI pilots fail traces back to this same gap.

What separates a forward deployed engineer from a consultant

Both work at client sites. The similarity ends there.

A consultant's output is a recommendation. Their leverage is analysis and framing, and their engagement ends with a document and a plan. This is genuinely valuable when the question is strategic and the answer is contested.

An FDE's output is a running system. Their leverage is that they can change the thing they are describing. When they say the retrieval pipeline is the bottleneck, they say it because they read the traces, and the fix is a pull request rather than a slide.

The practical difference shows up in how the two handle being wrong. A consultant who misreads the problem produces a plan that quietly does not work. An FDE who misreads the problem finds out inside a week, because the code does not do the thing, and adjusts. Shorter feedback loops are the whole advantage.

What separates them from a solutions engineer

A solutions engineer usually sits in the sales motion. They prove the product can do the job, handle the technical objection, and support the deal. Their success metric is closed revenue and their work is largely pre-sale.

An FDE is a delivery role. They arrive after the decision, and their success metric is whether the deployed system still moves the number a quarter later. Many people cross between the two, and the skills overlap heavily, but the accountability is different in a way that changes daily behaviour.

What makes someone good at it

The hiring bar is unusual, which is why the role is hard to staff.

• Engineering range. They land in unfamiliar codebases constantly and need to be productive in days, not months. Deep specialists in one stack struggle here.
• Real LLM experience past the demo stage. RAG, tool use, evals, guardrails, latency and cost tradeoffs. Anyone can produce an impressive prototype. Making one reliable at production traffic is a separate skill.
• A consultant's spine. They have to walk into a room of skeptical client engineers, earn trust in about a week, and be willing to tell a senior executive that the requested approach will not work.
• Tolerance for ambiguity. The first two weeks of most engagements are genuinely unclear. People who need a well-formed ticket to start are miserable in this seat.
• Writing. Memos, runbooks and updates that clients actually read. In a distributed engagement, clear writing is most of the coordination.

That combination of engineering depth, client-facing nerve and comfort with ambiguity is rare, which is why FDEs are expensive and why most companies rent the capability before they build it.

When you need one and when you do not

You want forward deployed engineering when the work is genuinely novel for your organisation, when the value depends on your specific data and workflow, and when nobody internally has shipped an AI system to production before. That is most mid-market AI work.

You do not need it for a well-trodden integration where the vendor documentation is good and your team has done similar work three times. Paying embedded-engineer rates for a task your team can execute is waste. The honest test: if you can write a specification precise enough that a competent contractor could deliver against it without talking to your operators, you do not need an FDE.

For the wider decision of whether to build the capability internally or buy it, see AI consultant vs. in-house hire and our note on fractional AI team vs. agency vs. Big 4.

Frequently asked questions

What does FDE stand for? Forward deployed engineer. The term is borrowed from military usage, where "forward deployed" means stationed at the point of operations rather than at headquarters. The point of the metaphor is proximity to the actual problem.

Is a forward deployed engineer the same as an implementation engineer? They overlap, but implementation engineers typically configure and integrate an existing product against a known playbook. FDEs build new systems where the playbook does not exist yet, and they are expected to change the plan when the data says the plan is wrong.

Do forward deployed engineers work on site? Sometimes, but embedding is about working inside the client's systems, standups and decisions rather than physical location. Most FDE work today is remote with overlapping hours and occasional travel when a room genuinely beats a call.

How many clients does one FDE handle? One or two at a time, at most. The model depends on holding deep context about a specific environment, and that context does not survive being split five ways.

Should I hire an FDE or a data scientist for AI work? If the problem is understanding your data and building a model, hire a data scientist. If the problem is getting an AI system into production and used by people who did not ask for it, that is an engineering and adoption problem, which is what the FDE role is built for. Most companies discover they had the second problem after hiring for the first.

10dem runs a forward deployed model by default. If you want to see what that looks like against your stack, talk to us or read more about how we work.