Verdict: The forward deployed engineer (FDE) is the fastest-growing tech role of 2026 — job postings are up 729% year over year — because 95% of enterprise AI projects produce no measurable return when nobody owns the deployment process. The companies making AI work (OpenAI, Anthropic, AWS, Palantir) all use the same playbook: find the highest-volume repetitive process, build on top of existing systems, keep the workflow recognizable to users, spend more time on trust than on building, and measure the dollars saved. You can run this process yourself with five steps — no FDE title required.
Last verified: 2026-08-07
- FDE job postings grew 729% YoY (Indeed, April 2025 to April 2026)
- MIT NANDA study: 95% of 300 enterprise AI projects produced zero measurable ROI
- AWS invested $1 billion in a forward deployed engineering unit (June 2026)
- OpenAI launched a $4 billion Deployment Company built around FDEs (May 2026)
- Morgan Stanley hit 98% advisor adoption using the FDE model
- Volatile facts: job posting counts, salary bands, and company headcount figures in this space change monthly.
What is a forward deployed engineer?
A forward deployed engineer (FDE) is a builder who embeds directly inside a customer's organization to make AI work in production — not to deliver a strategy document or configure a product, but to write code against real data inside messy, legacy-heavy systems until the AI does useful work that was previously done by hand. Palantir pioneered the role for government and defense clients who had no clean requirements and no tolerance for vaporware; OpenAI, Anthropic, Google Cloud, Salesforce, and AWS have all since built teams around the same model (The New Stack).
The role exists because there is a gap between "our AI works in a demo" and "our AI is live inside this company's compliance, data, and workflow environment." The FDE lives in that gap. They scope the problem, write the integrations, build the evaluation safeguards, earn user trust over months of piloting, and stay accountable for the outcome.
Why is every AI company suddenly hiring FDEs?
The demand explosion has a single root cause: AI moved from demos to deployment, and deployment is harder than anyone expected.
An MIT NANDA initiative study ("The GenAI Divide: State of AI in Business 2025") analyzed 300 public enterprise AI projects and found that 95% produced no measurable profit-and-loss impact, despite $30–40 billion in collective investment (MIT/MIT Media Lab, July 2025; Axios, August 2025). The study's conclusion was that the models were not the problem — the deployment was. Companies slapped generic tools onto processes they hadn't studied, built around workflows they hadn't documented, and left adoption to chance.
That gap created demand for people who could close it. FDE job postings grew roughly 729% year over year, from about 643 postings in April 2025 to over 5,330 in April 2026, according to Indeed data (Business Insider, May 2026). The supply of qualified engineers grew at a fraction of that rate, which is why companies are racing to build teams before their competitors do.
Who is investing and how much?
| Company | Investment / Structure | Date | Source |
|---|---|---|---|
| AWS | $1 billion forward deployed engineering unit, "thousands" of embedded engineers | June 30, 2026 | CNBC |
| OpenAI | $4 billion "Deployment Company" subsidiary, acquired Tomoro (~150 FDEs) | May 11, 2026 | OpenAI |
| Anthropic | $1.5 billion enterprise joint venture with Blackstone, Goldman Sachs | May 2026 | Decrypt |
| Salesforce | Committed to building 1,000 FDEs with a six-week onboarding program | 2025–2026 | Salesforce |
| OpenAI (internal) | FDE team grew from 2 people (Jan 2024) to 39, targeting 52 by year-end | 2024–2025 | ZenML/Altimeter podcast |
How does the FDE deployment process actually work?
The deployment methodology that separates the 5% of AI projects that succeed from the 95% that fail follows four core principles, drawn from how OpenAI, Anthropic, and Palantir run their FDE teams. These are not generic best practices — they are the specific workflow patterns that produce measurable ROI.
Step 1: Pick the process that costs the most money
The first principle is volume-driven process selection. You are looking for the person who handles the same kind of message, request, or transaction 50+ times a day, because automating a task that happens once a week saves nobody anything.
A business already has its entire operational history in its support tickets, email logs, transaction records, and CRM. You can hand that data to a model and ask it to identify where the volume concentrates — which tasks are repeated most often, by which teams, with what frequency.
OpenAI's FDE team did exactly this at one of the world's largest banks. They targeted the single job that thousands of wealth advisors did every day — researching and synthesizing financial information for clients — and built an AI assistant around it. The result was a 98% adoption rate among advisor teams (OpenAI Morgan Stanley case study).
The lesson: do not start with "where can we use AI?" Start with "what repetitive human task is costing us the most?"
Step 2: Build on top of what the business already runs
The second principle is that an AI agent is only worth what it can reach. If a team keeps all their work in Notion, you do not build them a separate system and migrate their data — you connect the agent to their Notion using an integration protocol like the Model Context Protocol (MCP) and let everyone keep working the way they always have.
This matters more than it used to because businesses have invested years and millions in their existing systems. One example from the field: a company that had spent $5 million and 5 years getting onto their finance system was never going to move off it. The entire job was getting everything else in the business talking to it, not replacing it.
The same principle applies to how people work, not just what tools they use. If someone has been running an 11-step process for years and you hand them a one-step version, they stop using it — the middle disappeared, and they are being asked to trust an answer that just appeared. Instead, you keep the steps visible so people can verify the work, and let the agent do its work inside each step.
Step 3: Separate human tasks, software tasks, and AI tasks
Every process has three kinds of work in it. The FDE's job is to figure out which kind handles each step:
| Task type | How to identify it | What to do with it |
|---|---|---|
| Fixed-rule tasks | Follows a deterministic rule that must come out right every single time | Keep as ordinary software — no AI needed |
| Judgment tasks | Requires reading something messy and making a judgment call | This is what AI is for |
| High-stakes decisions | Getting it wrong is expensive, or it is a genuine business call | Keep with a human, even if a model could technically do it |
In a typical eight-step process, this triage might result in four steps running fully automated, three steps running with a human checking the output, and one step staying fully human. The reason the fully human step exists is that it is a business judgment call — AI cannot make it yet, or the cost of getting it wrong is too high to hand over.
A company put an AI agent on its refund requests and on paper it worked: it read each request, checked it against the refund policy, and turned down the ones that didn't qualify. But weeks in, the company started losing long-time customers. Every refund the agent turned down was one the policy said to turn down — by the book. An FDE went and sat with the person who used to do that job and discovered an undocumented step: if the purchase was on a company card, the human always approved it without reading further, because those accounts buy every month and arguing over one refund loses the entire account. That check went into the workflow as a fixed rule ahead of anything the model decided. The problem wasn't the AI — it was a missing business rule that lived in someone's head.
Step 4: Budget more time for trust than for building
At the bank where OpenAI deployed, the technical build was finished in six to eight weeks. It took another four months of pilots and testing before the advisors would actually rely on it. That ratio — roughly 1:3 for building versus trust — is not an anomaly. It is the norm for any change to a daily workflow.
If you are doing something every day the same way you have done it for the past year, any change to that process has to earn its way in. Whether you are handing it to 5,000 people or to five, the trust-building phase is the bottleneck. Skip it, and you get 0% adoption of a system that technically works.
How can you run this process yourself — the five-step roadmap?
You do not need an FDE title or a $4 billion subsidiary to run this deployment methodology. The following five steps constitute a practical AI deployment audit that any team can run.
Step 1: Observe and document the real process
Watch how a job is actually done — not how it is documented, but how it happens in practice. Write down every single step in the order it occurs. Then ask why each step is done the way it is. If nobody can give you a concrete reason, that is almost always a workaround somebody put in years ago that nobody has questioned since.
This is the most important step and also the most overlooked. Most processes that look broken from the outside have undocumented business logic baked into them that only the person doing the job knows about. Until you capture that logic, any AI you build will miss it — and the system will feel wrong to the person using it.
Step 2: Run every step through three filters
Take the documented process and classify each step:
- Does this step follow a fixed rule and must come out right every time? If yes, it stays as ordinary software. It does not need AI and AI would make it less reliable.
- Does this step require reading something messy and making a judgment call? This is what AI is for. Flag it for the model.
- What does it cost when this step goes wrong? If getting it wrong is expensive — if it loses a customer, triggers a compliance violation, or costs more than the automation saves — that step stays with a person even when a model could technically handle it.
You will almost never find that the entire process should be run by AI. Some steps stay as software, some go to the model, and some stay with a person. That mix is the correct answer — handing the whole thing to a model is exactly how you end up in the 95% of AI projects that produce nothing.
Step 3: Build for the ways the system can fail, not just the happy path
When there is only one way something can go right, there are a thousand ways it can go wrong. If you only build for the way it goes right, what you built is worthless as soon as it meets a real-world edge case.
With AI, the main failure mode is overconfidence: the model hands you an answer even when it has no idea. You need to handle the places where the model is not sure — either by routing those cases to a human reviewer or by adding explicit confidence thresholds that flag low-certainty outputs for manual review. An AI agent that costs $2,000 a day but saves more than $2,000 a day by sending the right engineer to the right job is worth keeping — but only if you measure both sides of that equation.
Step 4: Test against real examples with known answers
A model gives a slightly different answer every time, even if you ask it the same question. If you only test a few times, you will miss the rare cases where it falls over.
Instead, pull real examples out of the process you documented in Step 1 — cases where you already know the right answer. Run the system across all of them and count how many it got right. Then go read the ones it missed and fix those. This is the evaluation-driven approach that OpenAI's FDE team used at Morgan Stanley — building tailored evals that measured domain accuracy, context relevance, and hallucination rates before the system went live (OpenAI).
Step 5: Put a number on what it was worth
You should be able to say whether the deployment brought money in, took a cost out, or made a risk smaller — because nothing else counts. If you cannot connect the AI deployment to a measurable business metric (revenue, cost saved, error rate reduced, cycle time shortened), you do not have a successful deployment. You have a pilot that never graduated.
What skills does an FDE actually need?
The people who succeed at this work are not the engineers who want to build code that holds up in 10 years. The job is getting something rough in front of a real user quickly — which is what AI coding tools hand you on the first pass anyway.
The skill profile is "wide across business process and technology, with one area they are genuinely deep in." The business half gets taught on the job faster than the technical half — but in practice, if you are building with AI agents, the technical scaffolding is increasingly handled by the tools themselves. What you need is the business judgment to know which steps should be automated, which should stay human, and what it costs when things go wrong.
For a practical deep-dive into building the kind of multi-agent team architecture FDEs use, see How to Build a Multi-Agent AI Team Your Whole Company Actually Uses (2026). For a broader framework on how AI deployment maps to project management, see End-to-End Project Management in 2026: The Resolution Framework That Replaces Agile for Builders.
What this means for you
If you are a small business owner or operator, the FDE playbook is a framework you can run on your own processes right now:
- Start small. Find the most repetitive job in your business — the one someone does 50+ times a day — and sit with the person who does it. Document every step.
- Triage. Split those steps into fixed-rule (software), judgment (AI), and high-stakes (human). You will find that AI belongs in fewer steps than you think — and that is the correct answer.
- Build on what you have. Do not rip out your existing tools. Connect AI to them. If your team lives in Slack and Notion, connect the agent there.
- Keep the workflow recognizable. Users need to see the steps they are used to. Let AI work inside each step; do not collapse 11 steps into one and ask people to trust a magic answer.
- Measure money. If the deployment does not move a dollar number — revenue, cost, or risk — it is not done.
For real-world examples of AI automation projects that succeeded (and failed), see 7 Lessons From Real AI Automation Projects That Actually Worked. To understand the full spectrum of AI agent capabilities for deployment, see 10 AI Agents That Do Real-World Work in 2026. And for how to set up the kind of agent operating system that an FDE would build, see How to Build a Claude Agent Operating System in 2026: The Practical 5-Layer Guide.
FAQ
Q: What is a forward deployed engineer (FDE)? A: A forward deployed engineer is a technical builder who embeds directly inside a customer's organization to make AI work in production. Unlike a consultant who delivers recommendations or a solutions engineer who configures a product, an FDE writes production code against real data inside messy systems and stays accountable for the outcome.
Q: How fast is the FDE role growing in 2026? A: FDE job postings grew roughly 729% year over year, from about 643 postings in April 2025 to over 5,330 in April 2026, according to Indeed data. The supply of qualified engineers grew at a fraction of that rate, making it one of the fastest-growing and hardest-to-fill roles in tech.
Q: Why do 95% of enterprise AI projects fail? A: A 2025 MIT NANDA study analyzing 300 enterprise AI projects found that 95% produced no measurable P&L impact. The primary cause was not the models but the deployment: companies used generic tools without studying their actual workflows, building on top of processes they hadn't documented, and leaving user adoption to chance.
Q: How long does it take to deploy AI in an enterprise? A: The technical build is typically the shorter phase — OpenAI's FDE team completed the build at Morgan Stanley in 6–8 weeks. But trust-building and adoption took another 4 months of piloting. Budgeting roughly 1:3 for build versus trust is a realistic starting point.
Q: How do you decide which process to automate with AI first? A: Pick the highest-volume repetitive task — the one someone does 50 or more times a day. Use your existing support history, transaction logs, or CRM data to identify where the volume concentrates. Automating a task that happens once a week saves nobody anything.
Q: Should every step in a process be handled by AI? A: No. In a typical 8-step process, the optimal split might be 4 steps fully automated, 3 steps with human review of AI output, and 1 step staying fully human. Steps that follow fixed rules stay as software; steps where mistakes are expensive stay with people. Handing the entire process to a model is how you join the 95% that fail.
Every claim here is traced to a primary source, dated, and listed under Sources. Research and drafting are AI-assisted; editing, verification and publication are human decisions, and a person is accountable for what appears on this page. How we work →
Discussion
0 comments