Why do AI companies hire Forward Deployed Engineers?
- Authors
- Name
- Amit Shekhar
- Published on
AI companies hire Forward Deployed Engineers because a model that works in a demo does not work inside a real company by itself. Someone has to sit with the customer and build the missing pieces until the system runs in production.
In this blog, we will learn about why AI companies hire Forward Deployed Engineers. We will also see what a Forward Deployed Engineer is, the gap between a model demo and a working system inside a real company, why selling an AI platform alone does not close that gap, how a Forward Deployed Engineer closes it, what the company gets back, and when a company does not need Forward Deployed Engineers.
We will cover the following:
- What is a Forward Deployed Engineer?
- The gap between a demo and a working system
- Why selling an AI platform alone does not work
- How a Forward Deployed Engineer closes the gap
- What the company gets back
- When a company does not need Forward Deployed Engineers
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.
What is a Forward Deployed Engineer?
A Forward Deployed Engineer is an engineer who works inside a customer's company, builds the AI software the customer needs on top of the AI company's platform, and stays until it runs in production.
The word "forward" comes from the idea of being sent forward, close to the customer, instead of sitting back at the company's office.
The role was created by Palantir. It is common at AI companies that sell models, agents, or AI platforms to other businesses.
A Forward Deployed Engineer is half engineer, half consultant, and full owner. The engineer decides what to build, builds the integrations and the AI agent with a coding agent such as Claude Code, tests it on the customer's real data, and owns the outcome.
Now, let's understand why this role exists.
The gap between a demo and a working system
Let's say an AI company has built a model. The company shows a demo to a bank. In the demo, the model reads a loan document, pulls out the important fields, and answers questions about it. The demo works perfectly.
The bank is impressed and signs the contract.
Now, the bank tries to use the same model inside its own company. The following issues arise.
Messy data: In the demo, the loan document was clean. Inside the bank, the documents are scanned images, some are many years old, some are in two languages, and the same field has five different names across five departments.
Old systems: The bank's data lives in a system built long before anyone talked about AI. There is no simple way to pull a document out and send it to the model. Someone has to build that path.
Security rules: The bank cannot send customer data to a server outside its own network. The model must run inside the bank's environment, with permissions that follow the bank's rules.
Unclear requirements: The bank says, "We want AI for loan processing." But, nobody in the bank can say exactly which step must be automated first, what a correct output looks like, or who checks the result.
The distance between the demo and the working system is the gap. Every AI company that sells to other businesses faces this gap.
A quick note for you
No matter which tech domain you work in, get familiar with these topics:
- LLM
- RAG
- MCP
- Agent
- Fine-tuning
- Quantization
We put it all together in one video:
AI Engineering Explained: LLM, RAG, MCP, Agent, Fine-Tuning, and Quantization
No need to stop reading - bookmark it and watch later when you get time. Future you will thank you.
Now, let's get back to the topic.
Why selling an AI platform alone does not work
The first approach is simple. The AI company sells access to the platform, gives the customer the documentation, and waits.
Consider what happens next.
The customer's own engineers are busy with their regular work. They have never built with this AI platform before. They do not know which parts of their data are good enough for the model, and they do not know how to write an evaluation to check if the output is correct.
So, the project moves slowly. After a few months, the customer has a half-built prototype that nobody trusts. The customer says the AI does not work. The AI company says the customer did not integrate it properly.
The issue with this approach is that the AI company has no one on the ground who understands both the model and the customer's environment. Let's see how the next approach solve this issue.
The second approach is to add a Solutions Engineer. A Solutions Engineer supports the sales team, builds demos, and answers technical questions before the deal is signed.
The issue with this approach is that the Solutions Engineer steps back after the deal is signed. Nobody owns the production delivery. The gap is still open.
So, here comes the Forward Deployed Engineer to the rescue.
How a Forward Deployed Engineer closes the gap
A Forward Deployed Engineer is placed inside the customer's company for the length of the project.
Let's go back to the bank.
First, the Forward Deployed Engineer sits with the loan team and scopes the problem. The engineer finds that the loan team spends most of its time checking whether the income documents match the application. That is the first thing to automate.
Then, the engineer looks at the real data. The engineer finds that the scanned documents need to be converted to text before the model can read them, and that two departments use different formats.
After that, the engineer directs the coding agent to write the connector that pulls documents out of the bank's old system, and reviews the code the coding agent produces. The engineer directs the coding agent to build the AI agent that reads each document, compares it with the application, and flags a mismatch. The engineer then directs the coding agent to write the evaluation, runs it on a few hundred real cases, and checks where the AI agent fails.
The engineer also works with the bank's security team so that the model runs inside the bank's network and only reads the documents it has permission to read.
Finally, the engineer ships it to the loan team, watches how they use it, and fixes what breaks.
Here, we can notice that the engineer does not type all of the code. The coding agent writes most of the code. The engineer's job is to describe the task clearly, review and verify what the coding agent produces, test it on real data, and design the full system around it.
Here, we can also notice that the engineer owns the outcome. The project is not done when the code is written. The project is done when the loan team uses the system every day and trusts its output.
This is how a Forward Deployed Engineer closes the gap.
Want to become a Forward Deployed Engineer?
These are the skills this role needs, and we teach them in our AI and Machine Learning Program at Outcome School:
- RAG
- AI Agent
- Model Context Protocol (MCP)
- Evaluation of LLMs and Agents
- Model Deployment and Serving
- AI Security
We take you from the fundamentals to building real AI systems, step by step.
What the company gets back
The AI company does not hire Forward Deployed Engineers only to finish one project. The company gets the following things back.
The product learns what real customers need: The Forward Deployed Engineer sees where the platform fails inside a real company. The scanned document problem, the missing connector, the security rule, and the evaluation gap all go back to the product team. The next version of the platform handles them.
A working reference deployment: Once the bank's system runs in production, the AI company has a real example that works. The next bank with the same problem gets a known path instead of a fresh experiment. Over time, the Forward Deployed Engineers turn these repeated paths into reusable parts of the platform.
Trust: The customer saw an engineer from the AI company sit with their team, understand their data, and stay until the system worked. That customer renews the contract and expands the use to other teams.
Stay updated: Subscribe to our newsletter to get our latest AI and Machine Learning blogs straight to your inbox.
When a company does not need Forward Deployed Engineers
Not every AI company needs this role.
Consider an AI company that sells a self-serve product. A developer signs up, reads the documentation, calls the API, and has a working result in an afternoon. The integration is simple. The data the product needs is already in the right shape. There is no old system to connect, and there is no security team to convince.
In this case, a Forward Deployed Engineer has nothing to close. The gap between the demo and the working system is small enough for the customer to cross on their own.
The need for Forward Deployed Engineers grows with the size of the gap. The messier the customer's data, the older the customer's systems, the stricter the customer's rules, and the less clear the customer's requirements, the more the company needs an engineer on the ground.
Now we must have understood why AI companies hire Forward Deployed Engineers, what gap they close, how they close it, and when a company does not need them.
Frequently Asked Questions
Which company created the Forward Deployed Engineer role?
Palantir created the Forward Deployed Engineer role. Today, the role is common at AI companies that sell models, agents, or AI platforms to other businesses. These companies need engineers who can work inside a customer's company and stay until the AI software runs in production.
How is a Forward Deployed Engineer different from a Solutions Engineer?
A Solutions Engineer works before the deal, and a Forward Deployed Engineer works after it. The Solutions Engineer supports the sales team, builds demos, and answers technical questions, then steps back once the deal is signed. The Forward Deployed Engineer stays inside the customer's company and owns the production delivery.
Does a Forward Deployed Engineer write all the code by hand?
No. A coding agent such as Claude Code writes most of the code. The Forward Deployed Engineer describes the task clearly, reviews and verifies what the coding agent produces, tests it on real data, and designs the full system around it.
When is a Forward Deployed Engineer's project done?
The project is done when the customer's team uses the system every day and trusts its output. Writing the code is not the finish line. The Forward Deployed Engineer ships the system, watches how the team uses it, and fixes what breaks.
That's it for now.
Thanks
Amit Shekhar
Founder @ Outcome School
You can connect with me on:
Follow Outcome School on: