A working definition · Updated September 2026
What is a Forward Deployed Engineer?
The role that companies are hiring for at a pace up several hundred percent year over year, that almost nobody can define in one sentence. Here is the one sentence, then the rest.
The one-sentence version
A Forward Deployed Engineer is a customer-facing software engineer who works inside your business, deploys AI into the workflow where the money actually leaks, and proves it moved a number.
The job is three roles in one person: consultant, product manager, and engineer. Not the average of the three. The best of each. The consultant part discovers what the business actually needs. The product manager part decides what to build and what to leave alone. The engineer part ships it into your systems and keeps it running.
Palantir invented the role. Their framing still holds: a product engineer builds one capability for many customers, a Forward Deployed Engineer builds many capabilities for one customer. The output of an engagement is working software in the customer's environment. Not a slide deck, which is consulting. Not a demo, which is sales engineering. Not a ticket queue, which is staff augmentation.
Why the role exists now
Intelligence became a commodity. Every company can buy the same models from the same handful of providers. Whatever advantage a business gets from AI no longer comes from having it. It comes from where, how, and why it gets deployed. That last mile is the job.
The evidence that the last mile is where things break is not subtle. An MIT study put the failure rate of enterprise AI pilots near 95 percent, and the failures are rarely the model's fault. Across the practitioner talks I have studied, from Anthropic, Cursor, Sierra, and Palantir alumni, the same five deaths repeat:
- Built for the demo. It worked on clean inputs in a sales call and fell over on the forty-sender inbox, the forwarded PDF, and the screenshot of a spreadsheet.
- Forced a migration. The vendor asked the client to move off the system they spent two years and two million dollars installing. The client said no, correctly.
- Handled the happy path only. There is one way a workflow goes right and a thousand ways it goes wrong. The exceptions are the actual job.
- Nobody owned it after launch. Models change, costs drift, edge cases arrive. Without an owner the system decays and gets quietly abandoned.
- Moved no metric. Nobody agreed on the number before building, so nobody could prove anything after.
Palantir was mocked for a decade for running an unscalable consulting business. It now has the highest average contract value among public software companies. OpenAI, Anthropic, Databricks, Microsoft, and more than a hundred startups have since adopted the role. The market caught up to the idea that deployment is the product.
The method: one loop, run in order
Every serious account of the role converges on the same loop. Each stage gates the next, and skipping one is how pilots die.
- Discover
- The documented process is fiction. The real one lives in one veteran's head. Sit next to the person doing the work, pull ten to twenty real completed cases, and walk the stated problem back to the actual bottleneck. Get an executive in the room, because mid-level contacts hand you pre-filtered requests.
- Triage
- Run every step of the mapped workflow through three filters. A fixed rule that must be right every time becomes deterministic software. A messy input that needs judgment goes to the model. Anything expensive to get wrong stays with a human. Most real solutions are mostly deterministic, with the model at a few points and a person approving the rest.
- Build
- The smallest scope that proves value, shipped fast and iterated with the user watching. On top of the ERP, CRM, or spreadsheet they already run. Keep their steps visible: a one-step black box replacing an eleven-step process gets abandoned.
- Evaluate
- Build an eval suite from real historical cases with known answers. The pass rate is not the deliverable. The failure analysis is: of the nine failures, five were missing data and four pulled the wrong record. Each becomes a fix, a guardrail, or a routing rule to a person.
- Deploy
- Production is cultural. Shadow mode, then suggestions, then gated actions, then autonomy. Private inference, access control, audit logs, and the client's compliance rules are part of the build. Budget more time for trust than for code.
- Prove
- Businesses measure three things: revenue, risk, cost. State the impact in one of them with a before-and-after number, and agree on that number at scoping time, not after.
- Scale
- One proven workflow exposes the next bottleneck upstream or downstream. The loop runs again. That is how one deployment compounds across a business.
What a Forward Deployed Engineer is not
Because the title is new, it gets attached to work that is not the job. Four things to rule out:
- Not pre-sales. A demo that never runs in production is sales engineering. Useful, but a different job.
- Not advice without building. If the engagement ends with recommendations and no running software, it was consulting.
- Not one-to-many product engineering. An FDE builds for one customer's reality. Patterns that repeat across customers get fed back into a platform, but the engagement is bespoke.
- Not staff augmentation. When the ask begins with “we're understaffed,” the problem is headcount, and an FDE will tell you so on the first call.
When and how to hire one
The role fits when three things are true at once. A technical capability is meeting a non-technical team. There is real volume in the workflow, enough that recovering days or dollars per case adds up to something a budget meeting cares about. And an executive owns the number that should move.
Questions worth asking any Forward Deployed Engineer before you engage them:
- Which of my systems will you build on, and which will you ask me to replace? The right answer to the second half is none.
- What number do we agree on before you write code, and how will you measure the baseline?
- What does your eval report look like, and what happens to the cases that fail?
- Who owns this six months after launch?
- Show me something you deployed that is still running.
This is the work I do. It starts with a two-week discovery sprint and ends with software running on your systems and a number you can defend. See the three engagement shapes, or email me a description of the workflow that leaks money.
Watch the method explained
I run Forward Deploy, a YouTube channel on how this job actually works, with long-form breakdowns and a daily short. Start with The $10M Autopsy: Why 95% of AI Pilots Fail, then The Sommelier's Job: What a Forward Deployed Engineer Actually Is. The full series is in The FDE Roadmap playlist, and the free 30-day plan for doing the job before you have the title is at forwarddeploy.fonz.sh.
Questions people ask
- What is a Forward Deployed Engineer?
- A customer-facing software engineer who works inside a client's business rather than at a vendor's headquarters. The role combines consultant, product manager, and engineer: discover the real bottleneck, decide where AI belongs, build it on the systems the business already runs, and own the result until a metric moves.
- What does FDE stand for?
- Forward Deployed Engineer. Palantir popularized the title, where the engineers were also called Deltas. It is now used by Anthropic, OpenAI, Databricks, Cursor, Sierra, and many startups.
- How is it different from a consultant?
- A consultant's deliverable is advice, usually a deck. A Forward Deployed Engineer's deliverable is working software in the client's environment, with an evaluation report and a measured before-and-after. The FDE also stays on after launch.
- When does it make sense to hire one?
- When a technical capability is meeting a non-technical team, there is real volume in the workflow, and an executive owns the number that should move. Not when the real problem is headcount, and not when the request is a demo.
- How long does a forward deployment take?
- About two weeks of discovery, then six to ten weeks of build, then a longer trust period of shadow mode, suggestions, and gated actions. Trust takes longer than the build.
- Why do most AI pilots fail?
- An MIT study put the failure rate near 95 percent. The pattern: built for the demo, forced a migration, happy path only, no owner after launch, and no number agreed up front.