The Forward Deployed Engineer Roadmap: 6 Phases and the Skills Each Needs (2026)

Forward Deployed Engineer is one of the fastest growing roles in Silicon Valley right now. OpenAI, Anthropic, AWS and Google are all building dedicated teams and pouring serious money into them.

But look at the actual job descriptions and they span engineering, architecture, and working directly with customers. It is genuinely overwhelming to work out where to begin and what actually matters.

This is the complete roadmap, broken into six phases, with the exact skill each phase demands.

The six phases only make sense once you understand what the role is and why it exists — so let's start there.

What the role is, and why it exists

The biggest problem with AI right now is not the technology. It is getting it to work inside real businesses where the infrastructure is outdated and the workflows have not changed in years.

There is hard data behind this. MIT's NANDA initiative studied 300 public AI projects and found roughly 95% of enterprise AI pilots produced little or no measurable impact on profit and loss. The problem was not the models. It was how they were put into use.

Historically, companies hired consultants from the big firms for this kind of thing — the classic IT transformation engagement. But those consultants are not actually implementing anything. And with AI moving as fast as it is, you cannot wait four months for a slide deck.

So the barrier to implementing AI inside a real business stayed high, and companies were not adopting fast enough on their own.

The frontier labs took a different approach, one pioneered by Palantir. Instead of selling you a model and hoping for the best, they embed their own engineers directly inside your business to implement the product for you. Palantir's Forward Deployed Software Engineer role is the blueprint the whole industry copied. OpenAI and Anthropic are now doing exactly this.

That is a forward deployed engineer. They own the outcome of implementing AI into a business. Not advising on it — actually making it work in production.

What it pays

Compensation reporting varies a lot by source, level and location, so treat these as ranges rather than precise figures:

The reason the numbers are high is not glamour. It is that the work happens inside messy enterprise environments where nothing is clean — which becomes obvious around phase four.

The six phases

Everything an FDE does runs through six stages: discover, design, build, deploy, prove, scale. I'll use one worked example throughout — an insurance company — so you can see how each phase connects.

Phase 1 — Discover

This is where you go into the business and figure out what problem actually needs solving.

The truth is that what a customer tells you they want and what they actually need are almost always two different things.

Leadership at our insurance company says: "Our claims process is too slow, customers are complaining about response times, we think we need to modernise our claims platform."

On the surface that sounds reasonable. As an FDE you do not take it at face value. You start digging, and you find the claims platform is not the issue at all.

The real bottleneck is everything that happens before a claim is assessed. Every claim arrives with supporting documents — photos, repair estimates, medical records. Each one has to be manually read, cross-referenced against policy terms, and written up as an assessment. By hand. For every single claim.

That is why it takes four days to respond to a customer. Nothing to do with the platform. Everything to do with the manual process wrapped around it.

That is a completely different problem to the one leadership described. And anyone who has spent real time inside enterprises will tell you this is the norm: most companies have a process problem that technology can solve. Workflows have not changed in years because that is how it has always been done.

The skill: business acumen fused with technical judgement. It comes from having enough reps that walking into a company, your experience points you in the right direction. The more businesses you work with, the faster you spot inefficiencies, because the patterns repeat. And knowing the technology well enough lets you see where AI genuinely helps versus where it just adds complexity.

If you have done cloud consulting, migrations or technical assessments, this is the same discovery process — applied through an AI lens.

Phase 2 — Design

Once you have found the real problem, it has to become something you can build. This phase is about scoping.

The manual document review is the bottleneck. So what exactly are we building?

An AI agent that reads the claim documents, extracts the key details, cross-references them against policy terms, and delivers a structured summary ready for review. Hours of manual work becomes minutes. You are recreating the original manual process — just with AI instead of a person doing the reading.

What you are not building matters just as much

In this case you are not automating the claim decision. That requires human judgement and regulatory sign-off. You are removing the bottleneck, not replacing the judgement.

This distinction is why a huge number of AI pilots fail. Scope stays vague, everyone quietly expects the solution to do everything, and nothing ever ships to production.

Once scope is clear it needs a technical design — the full picture of how this runs in production. Infrastructure, data access, security, and what happens when things go wrong. Every one of those involves trade-offs, and being able to explain why you chose each is a large part of the job.

The skill: system design. Taking a messy real-world business problem and turning it into a structured technical plan that can be built and deployed.

If you understand cloud architecture from platforms like AWS this will feel familiar, because it is the same thinking — mapping services, data flows, security boundaries and failure modes. The only difference is that a model now sits at the centre of the architecture.

And what separates experienced engineers from everyone else: the best architecture is never the most complex one. It is the one that solves the problem with the least complexity.

Phase 3 — Build

Now the engineering happens.

The agent needs access to the company's own data. That is RAG — retrieval augmented generation — connecting the agent to internal records, policies and documents so it works with real business information rather than only its general training knowledge. Without it, the AI has no context about the business at all.

It also needs grounding in historical claims — years of previously processed cases, so the output follows how assessments were actually done rather than producing something generic.

Evaluation is not optional

Before this goes anywhere near real users, it has to be tested properly. That is eval engineering: building a way to measure whether the output actually works reliably.

You run the agent across hundreds of test claims and track how often it extracts the correct information, how accurately it summarises, and whether it ever fabricates details — hallucination. The point is proving reliability with hard numbers.

This is exactly what frontier labs measure their own FDEs on: eval-driven feedback and measurable workflow impact. It is a requirement, not a nice-to-have.

The part documentation never mentions

Anyone who has worked inside enterprise environments knows connecting to existing applications is never as clean as the docs suggest. APIs are inconsistent. Data formats do not match. Sometimes there is no API at all and you engineer a workaround.

That is the reality of building inside a real business — and a large part of why these roles pay what they do.

The skill: AI engineering. Using models to build applications that run reliably inside a real business. The technology evolves fast, but what stays constant is your ability to ship things that work in production and solve real problems.

Phase 4 — Deploy

A working solution now has to go from a test environment into production inside a real company. That jump is much harder than people expect.

The agent works perfectly in testing. Now it has to run inside the actual environment — and the first thing you hit is that most enterprises will not let sensitive data hit a public API. They need the model running on their own private infrastructure, often through something like AWS Bedrock, where they control the environment and know exactly what happens to their data.

One of the biggest concerns in enterprise AI right now is whether company data is being used to train the provider's next model version. For several regulated industries that is an outright dealbreaker, and the FDE has to navigate all of it.

Then there is the environment itself. Databases are old. Security is locked down. Compliance rules restrict what data the AI is allowed to touch. And the way teams work has not changed in a very long time.

Deploying is not purely a technical challenge. It is an organisational one, because you are changing how people do their jobs — and that is always harder than the technology.

This is the 80% of the job nobody talks about. Building a demo is easy. Deploying it inside a messy enterprise production environment is the real work. It is also exactly what cloud and DevOps engineers deal with every day: getting things into production securely, reliably, and in a way the business can actually operate.

The skill: cloud and infrastructure engineering. Deploying real applications into real environments securely and reliably, while understanding data governance and the operational side of running models in production.

Phase 5 — Prove

Now you verify that what you built actually works the way it should in production.

Is the agent processing claims accurately and consistently? If not, you adjust. Maybe it misreads certain document types, or misses details in specific policy formats. You identify it, fix it, run it again. This phase is iterative — you keep refining until the results are genuinely solid.

Then you put the numbers in front of leadership. Claims that took hours of manual review now process in minutes. With a real dollar value attached.

This matters more than most engineers realise. Companies are pulling back on AI spending, because they have seen the demos, heard the pitches, and funded pilots that went nowhere — which is exactly what that 95% figure describes. Spending rocketed; the promised revenue did not arrive.

So proving ROI is not a nice-to-have. It is what builds the trust that leads to bigger engagements.

The skill: communication. Connecting technical work to business outcomes. Leadership cares about revenue, cost and risk. If your solution moved at least one of those, you created real value. A lot of engineers struggle here — for an FDE it is as important as the engineering.

Phase 6 — Scale

The most underrated phase, because the work does not stop once results are proven. In many ways this is where the real value starts.

The document review agent works and leadership can see the numbers. The natural next step is applying the same pattern elsewhere — underwriting, compliance, customer onboarding. An FDE is best positioned to spot those opportunities because they have been inside the business long enough to understand how it actually operates on the ground.

Then there is AI operations. Production AI is not deployed and forgotten:

• Model performance has to be monitored over time
• Costs have to be tracked, because API calls add up fast
• When a new model version ships, behaviour can change and the solution may need adjusting

Keeping all that running is an ongoing responsibility, and the customer neither wants it nor is staffed for it. That is precisely why they need an FDE.

There is also the feedback loop back to the product team. You notice patterns repeating across customers, and those get documented and fed back so they can be built into the product. That on-the-ground experience shapes the roadmap, and it is one of the most valuable things an FDE contributes.

Which ties to why the role exists commercially: the deeper an AI product embeds into an organisation's workflows, the harder it becomes to switch to a competitor. Every new use case makes the relationship stickier. That is why frontier labs are investing so heavily — they are removing the barrier to entry entirely by doing the implementation themselves.

The skill: product mindset plus operational know-how. Spotting where AI can create more value while keeping what is already live running smoothly.

Where FDE meets cloud engineering

Notice what came up again and again across those six phases: system design, cloud architecture, infrastructure, deployment, DevOps, security, monitoring.

The overlap with cloud engineering is enormous. The AI layer — model integration, RAG, eval engineering — sits on top of that foundation.

And that ordering is not accidental. The reason forward deployed engineers are effective is that they spent years building, deploying and operating real systems before AI was part of the conversation. You cannot skip that. You can pass every AI certification available and it will not replace experience with production environments.

Set your expectations honestly

This is not an entry-level role. It is something you move into after four, five, six years of real engineering experience. It demands business judgement, technical depth and on-the-ground problem solving that only comes from doing the work. There is no shortcut.

If you are earlier in your journey, the realistic path is to build the foundation first — which is largely the cloud engineering path. If that is where you are, the AWS cloud engineer roadmap covers it, and being able to explain a complete production system end to end is the single best proxy for the design skill phase two demands. This walkthrough of a real architecture is a good template.

On the AI layer specifically, be selective. Most AI certifications are course-completion badges that prove nothing — here is which ones to avoid and which are actually worth it.

One last thing about job titles

Something I learned a long time ago: do not tie your identity to a job title.

"Forward deployed engineer" might not exist in five years. It could be absorbed into another role or renamed — that happens in tech constantly.

What will never change is that businesses will always need people who can solve their problems with technology. The title changes; the core of the work does not. Understand a business, design a solution, build it, deploy it, prove it works.

So if you are wondering where to start, do not chase the title. The FDE role is lucrative and booming right now, but the goal is to become so good as an engineer that you are undeniable. Everything else follows from that.