mailwal

Forward Deployed Engineer Roadmap

Amit Shekhar from Outcome School

Forward Deployed Engineer Roadmap

A step-by-step roadmap to become a Forward Deployed Engineer (FDE) in AI, with a blog for every topic.

The Forward Deployed Engineer Roadmap is a step-by-step path to become a Forward Deployed Engineer (FDE) in AI, with a free blog for every topic, starting from the basics and going all the way to shipping a production system at a customer site.

In this blog, we will learn about the Forward Deployed Engineer Roadmap. We will also see who a Forward Deployed Engineer is, how an FDE is different from an AI Engineer, how an FDE engagement works from start to end, what we will learn in each step of the roadmap, and how to follow it to prepare for FDE interviews.

We will cover the following:

  • Who is a Forward Deployed Engineer?

  • AI Engineer vs Forward Deployed Engineer

  • The FDE Engagement Lifecycle

  • The Forward Deployed Engineer Roadmap

  • How to Follow the Roadmap

  • Preparing for FDE Interviews

I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning at Outcome School.

Let’s get started.

Who is a Forward Deployed Engineer?

A Forward Deployed Engineer (FDE) is a software engineer who works directly with the customer to take an AI product from a demo to a working system in production, inside the customer’s real systems, data, and workflows.

Let’s understand the term “Forward Deployed”. It means that the engineer is placed at the front, right next to the customer, instead of sitting far away inside the product team.

The best way to learn this is by taking an example.

Let’s say a company has built an AI support assistant. The demo works perfectly on the sample data. Now, a bank wants to use it. The bank has its own ticketing system, its own documents, its own security rules, and its own idea of what a good answer looks like. Someone must sit with the bank, understand all of this, connect the assistant to the bank’s systems, prove with numbers that it gives correct answers, and take it live.

Here comes the Forward Deployed Engineer into the picture.

An FDE is three things at the same time:

  • An engineer: writes production code, builds RAG pipelines and agents, integrates APIs, and ships.

  • A problem finder: sits with the customer, understands the actual business problem, and turns a vague ask into a clear definition of done.

  • A trust builder: proves with evals and numbers that the system works, keeps it safe and secure, and explains trade-offs to both engineers and business leaders.

This is why an FDE needs breadth more than depth. We must know enough about LLMs, RAG, agents, evaluation, inference, security, and system design to make the right call quickly, in front of the customer.

AI Engineer vs Forward Deployed Engineer

An AI Engineer mostly builds the product. An FDE makes the product work for one specific customer, and then brings what they learned back to the product team.

Let me list the differences between an AI Engineer and a Forward Deployed Engineer for your better understanding.

Main focus:

  • AI Engineer: Builds the AI product

  • Forward Deployed Engineer: Makes the AI product work for one specific customer

Works closely with:

  • AI Engineer: The product team

  • Forward Deployed Engineer: The customer’s engineers and business leaders

Success means:

  • AI Engineer: The product ships with the right features

  • Forward Deployed Engineer: The customer goes live and sees real value

Knowledge needed:

  • AI Engineer: Depth in the product area

  • Forward Deployed Engineer: Breadth across LLMs, RAG, agents, evals, inference, and security

Feedback loop:

  • AI Engineer: Uses learnings from FDEs to improve the product

  • Forward Deployed Engineer: Brings learnings from the customer back to the product team

The FDE Engagement Lifecycle

Almost every FDE engagement follows the same path. First, we understand the problem. Then, we build a working prototype on the customer’s data. After that, we prove that it works, make it production-ready, and finally deploy it.

The roadmap is ordered to match this path exactly:

  • Discover (Step 0): Understand the customer problem, define what success looks like

  • Learn the toolbox (Step 1, Step 2, Step 3): Know what AI can and cannot do, and why

  • Prototype (Step 4, Step 5, Step 6, Step 7): Build a working demo on the customer’s data in days, not months

  • Prove value (Step 8): Measure quality with evals, show the numbers

  • Harden (Step 9, Step 10, Step 11): Make it safe, secure, fast, and affordable

  • Deploy (Step 12): Design the full system and choose where it runs

  • Ship a real use case (Step 13): See every idea come together in one production system

So, when we follow the roadmap step by step, we are also learning the job in the same order in which we will do it at a customer site.

The Forward Deployed Engineer Roadmap

The complete roadmap, with the link to every blog and video, is available on GitHub: Forward Deployed Engineer Roadmap

It has 15 steps, from Step 0 to Step 14. Now, let’s go through each step and see what we will learn and why an FDE needs it.

Step 0: Must Know

Before jumping into the details, we must know the six words that come up in every AI Engineering conversation: LLM, RAG, MCP, Agent, Fine-tuning, and Quantization.

As an FDE, these six words will come up in our very first customer meeting. The customer will ask: “Should we use RAG or fine-tuning?”, “Can an agent do this for us?”, “Can we run the model on our own servers?”. The roadmap covers all six in one video, so that we have the big picture before going deep.

Step 1: AI and Machine Learning Essentials

In this step, we will learn the Machine Learning basics that every FDE must know to talk to data teams, understand customer data, and measure whether a model is good or bad.

We will learn about Machine Learning, supervised vs unsupervised learning, feature engineering, the train, validation, and test split, precision vs recall, neural networks, activation functions, softmax, logits, gradient descent, and reinforcement learning.

Step 2: How LLMs Work

In this step, we will learn how an LLM works from the inside, how it generates text, and where it fails. An FDE must be able to explain to a customer why the model hallucinated, why it forgot something in a long document, and why the response takes time.

We will learn about tokenization, Byte Pair Encoding, embeddings, the Transformer architecture, Self Attention, temperature, top-k and top-p sampling, stop tokens, token streaming, the context window, the Lost in the Middle problem, and why LLMs hallucinate.

Step 3: Choosing the Right Model for the Customer

In this step, we will learn that there is no single best model. The right choice depends on the customer’s task, budget, latency needs, and where their data is allowed to go.

We will learn about Small Language Models, Large Reasoning Models, Mixture of Experts, Multimodal AI, Vision-Language Models, and LLM Routing, which means sending each query to the right LLM.

Step 4: Prompt Engineering and Context Engineering

In this step, we will learn the fastest and cheapest way to improve the results for a customer: giving the model better instructions and better context. In most FDE engagements, the first big win comes from here.

We will learn about Chain-of-Thought prompting, prompt chaining, Tree of Thoughts, context engineering, context compaction, and prompt caching.

Step 5: RAG on Customer Data

In this step, we will learn how to make an LLM answer questions from the customer’s own documents, tickets, wikis, and databases. RAG is the most common thing an FDE builds, so this is one of the biggest steps in the roadmap.

We will start with vector databases, Approximate Nearest Neighbor search, semantic search, and hybrid search. Then, we will move to rerankers, chunking strategies, contextual retrieval, HyDE, query rewriting, ColBERT, and caching. Finally, we will learn about Agentic RAG, GraphRAG, and Vectorless RAG.

Step 6: AI Agents and Tool Integration

In this step, we will learn how an LLM goes from answering questions to doing actual work inside the customer’s systems. The LLM decides which tool to use and with what input, and our agent code runs that tool, for example, calling the customer’s API.

We will start with a single agent: function calling, the agent loop, ReAct agents, Plan-and-Execute agents, Reflection agents, and agent memory. Then, we will learn about MCP (Model Context Protocol), Agent Skills, and OKF (Open Knowledge Format). After that, we will move to multi-agent systems, subagents, agent communication, AI orchestration, computer-use agents, and browser agents.

Step 7: Agentic Engineering and Building Fast with Coding Agents

In this step, we will learn the engineering practices for building reliable agents, the frameworks we will meet at customer sites, and how coding agents work. An FDE is expected to ship a working prototype in days, and coding agents are a big part of how that happens.

We will learn about harness engineering, loop engineering, graph engineering, LangChain, LangGraph, Claude Code, and Cursor.

Step 8: Evaluation and Observability: Proving Value to the Customer

In this step, we will learn how to measure whether our system is doing a good job, and how to see what it is doing in production. For an FDE, evals are not optional. Evals are how we prove value, catch regressions, and get the customer to sign off on going live.

We will learn about LLM evaluation, LLM as a Judge, AI agent evaluation, and AI agent observability with traces, spans, and metrics.

Step 9: AI Safety, Security, and Trust

In this step, we will learn how to keep an AI system safe inside a customer’s environment. Enterprise customers care a lot about this: what the model can say, what it can do, and how attackers try to break it.

We will learn about LLM guardrails, prompt injection and how to defend against it, and LLM watermarking.

Step 10: Latency and Cost in Production

In this step, we will learn how to make LLMs faster and cheaper to run. A demo that takes 10 seconds per answer, or costs too much per user, will never reach production.

First, we will learn what happens during inference: prefill vs decode, KV Cache, Paged Attention, and continuous batching. Then, we will learn the techniques that speed it up: speculative decoding, prefill-decode disaggregation, and model quantization. Finally, we will learn about the tools a customer can run on their own servers: GGUF, llama.cpp, Ollama, vLLM, SGLang, and TensorRT-LLM.

Step 11: Fine-Tuning and Customizing Models

In this step, we will learn what to do when prompting and RAG are not enough. For example, the customer needs a specific style, a specific format, or domain behavior, or wants a smaller and cheaper model that matches a bigger one. An FDE must know when fine-tuning is the right call and when it is not.

We will learn about fine-tuning, LoRA, prefix tuning, knowledge distillation, continual learning, RLHF, and Direct Preference Optimization (DPO).

Step 12: AI System Design and Infrastructure

In this step, we will learn how to design a complete AI system end to end and where to run it. An FDE must be able to sit with the customer’s architects, draw the full system on a whiteboard, and advise on where it must run: in the cloud, on their own GPUs, or on the device.

We will learn how a GPU works for deep learning, how CUDA kernels work, how a Google TPU and an LPU work, and cloud vs on-device model deployment. This step also links to the AI System Design guide to learn AI System Design step by step.

Step 13: Customer Use Case: Real-Time Voice AI Agent

In this step, we will see everything come together in one of the most requested customer deployments: a real-time voice AI agent for customer support, sales, or scheduling. It touches models, agents, tools, latency, streaming, and system design all at once, which makes it a complete end-to-end FDE project.

We will learn how to design a real-time voice AI agent, cascaded vs speech-to-speech architecture, turn-taking, endpointing, barge-in, the latency budget, time-to-first-audio, streaming TTS, filler phrases, and how to hide the delay of a slow tool call.

Step 14: Prepare for Forward Deployed Engineer Interviews

Now that we have learned everything from AI foundations to shipping a production system at a customer site, it’s time to prepare for the interviews. We will see this in detail in the last section of this blog.

How to Follow the Roadmap

The roadmap is designed so that anyone can follow it in the given order, even without any prior background in AI.

  • Follow the steps in order. Each step builds on top of the previous one.

  • Inside each step, read the blogs in the given order. Every blog explains one concept in simple words with examples.

  • Wherever there is a video for the same topic, it is listed right below the blog. We can read the blog and then watch the video, or the other way around.

  • Every blog is free to read and is written for beginners.

After every step, we must ask ourselves one question: “If a customer asked me about this tomorrow, could I explain it and make a decision?” If the answer is yes, we move to the next step. If the answer is no, we go back and read the blogs of that step again.

We will keep updating the roadmap with new topics and blogs. So, we can star the repository to get the updates.

Preparing for FDE Interviews

FDE interviews usually test three things:

  • Coding with AI Agents: practical, real-world development using AI coding agents to build, debug, and ship a feature end to end.

  • AI system design: designing a RAG system, an agent, or a voice agent for a given customer problem, with trade-offs on quality, latency, cost, and security. Steps 5 to 13 and the AI System Design guide prepare us for this.

  • Customer scenarios: a vague business problem is given, and we must ask the right questions, define success, pick an approach, and explain it simply. Step 0 and Step 8 prepare us for this.

Here, we can notice that the interview tests the same things that an FDE does every day at a customer site. That is why the roadmap follows the FDE engagement lifecycle. When we complete the roadmap, we are prepared for both the interview and the job.

We teach all of these in the AI and Machine Learning program at Outcome School.

Now we must have understood who a Forward Deployed Engineer is, how an FDE engagement works, and how to follow the Forward Deployed Engineer Roadmap step by step to become one.

© 2026 Outcome School
A1502, DGH, SECTOR 62, Gurugram, Haryana, India - 122001