Quick summary: A Forward Deployed Engineer (FDE) goes into a business, finds a real problem, builds the solution directly and gets it running in production. What sets the role apart is responsibility for the outcome after deployment, not just writing code. Palantir developed the model years ago, but it drew major attention in 2026 as AI companies invested in deployment teams. The reason: AI can work well in a demo, while making it work reliably in daily operations is a different problem.
A business can buy access to an AI model, hire people to build an app and watch a demo run well. Then employees start using it for real, the data turns out to be scattered across several systems, and small errors interrupt the work. The gap between "AI can do this" and "the business can use this" does not close on its own after the code is handed over.
If you use coding agents or vibe coding (having AI write most of the code from a plain-language description), the FDE role is worth understanding. As building an app gets faster, the important question shifts from "how do I write this?" to "how do I know I'm solving the right problem, and how do I keep the solution working in the real world?" This article takes it in order: what an FDE does, how the role differs from its neighbors, why AI companies built FDE teams in 2026, and how AI coding changes the job.
What does an FDE do that a software engineer doesn't?
An FDE starts from a specific customer's problem, not necessarily from a written software requirements document. They learn how the work actually happens, identify what is causing trouble, then build and deploy the solution themselves.
Take a hypothetical case that runs through this article: a small distribution company in Vietnam has an accounting team that must reconcile invoices from several places. Order information sits in Excel files, payment data sits in the accounting software, and invoice photos are sent by staff over Zalo, a messaging app widely used in Vietnam. Every week, the accountants spend hours opening each source and hunting for the matching transaction.
The company director says: "We want to use AI to fix this." With a typical take-the-requirements approach, an engineer would ask: "What features does the app need?" But the director doesn't know what app they need either.
An FDE starts by sitting with the accountants and watching one invoice get processed from the moment it arrives until it is reconciled. They look at which columns the Excel files have, how the accounting software lets them pull data, and whether the photos sent over Zalo follow a fixed format.
After that, the FDE may find that the main problem is not a missing chatbot. The data hasn't been brought into one place, and there is no reliable way to match transactions. Only then do they decide what to build.
If the data has a fairly stable structure, an automated workflow may be enough. If the invoices are photos in many different formats, AI can help read the information, while the reconciliation step still needs validation rules and a way to handle uncertain cases.
The FDE can use AI coding to build a trial version, put it into the accountants' process, then watch the reconciliation errors and keep fixing them. The job doesn't end when the app runs on the engineer's own machine.
In FDE: nghề hot 2026 sinh ra ở giao điểm giữa AI và doanh nghiệp ("FDE: the hot 2026 job born where AI meets business", written in Vietnamese), Nguyễn Phi Vân describes the FDE process as running in reverse: the engineer goes into the business, observes the problem, understands the data, finds a solution with the customer, then builds it and keeps fixing it after deployment.
In Gregor Ojstersek's Engineering Leadership newsletter (August 15, 2026), Colin Jarvis, who leads OpenAI's Forward Deployed Engineering team, sums it up:
"A forward deployed engineer is focused on outcomes."
In the invoice example, the outcome is not having one more AI app. The outcome to verify is that the accountants can reconcile data more accurately, do less manual work, and know what to do when the system fails.
To go deeper on identifying the right problem before writing code, read Fable 5 and the unknowns problem: fix the map before you code.
But sitting next to the customer, learning the work and proposing a solution sounds a lot like what consultants and sales engineers already do. So where does an FDE's responsibility actually differ?
How is an FDE different from a consultant, a sales engineer and a requirements-driven engineer?
The two easiest criteria are when a person joins and what they are responsible for once the system is in operation.
A solution sold to a business can pass through several stages. Someone proves the product is worth buying, someone analyzes the problem, and someone builds the system the customer will use.
In the invoice reconciliation example, all four roles can take part, in different ways.
| Role | When do they join? | What do they deliver? | Who is responsible when it runs for real? | In the invoice example |
|---|---|---|---|---|
| Sales engineer | Usually before the contract is signed | A demo or trial version to prove the solution | Usually handed off to a deployment or support team | A chatbot demo that can read invoices |
| Consultant | When the business needs analysis and recommendations | A report, improvement options | Depends on the contract, may not run the system directly | A proposed new reconciliation process |
| Software engineer working from requirements | Once the requirements are clear enough | Software that meets the requirements | Depends on the organization, may sit with development or operations | Building the invoice-matching feature to spec |
| FDE | From exploring the problem to putting the solution into use | A solution built, integrated and verified in the real environment | Directly involved in handling and improving results within the deployment scope | Sits with the accountants, defines the problem, builds, puts it into use and keeps fixing |
The table below is a rough framing I put together from the sources in this article, not a standard definition. Actual responsibilities depend on the company and the contract.
For example, a solutions engineer may do a lot of work after the contract is signed. A technical consultant may also write code and support operations over the long term. A software engineer on an internal product team may work as close to users as an FDE does.
Job titles are not enough to tell them apart. Look at the actual responsibilities. In the FDE model, the engineer usually takes part in both discovering the problem and building the solution. When an API (Application Programming Interface, the way two pieces of software exchange data) goes down or the customer's data changes format, they don't stop at saying the software was delivered to spec. They help handle it so the customer's work keeps running, within the agreed scope of responsibility.
This mix of technical skill and deployment responsibility did not appear with the AI wave. Palantir organized its engineers on a similar model years ago.
Where did the FDE model start?
The FDE model is tied to Palantir, where engineers were split between building a shared platform and deploying directly for individual customers.
In Dev versus Delta: Demystifying engineering roles at Palantir, published April 8, 2019, Palantir explains the company's two largest engineering roles:
- Dev (Software Engineer): Builds the software platform that serves many customers.
- Delta (Forward Deployed Software Engineer): Works directly with one customer, deploying and customizing the platform to solve important business problems.
Palantir expresses the difference in two formulas:
| Dev | Delta |
|---|---|
| "One capability, many customers" | "One customer, many capabilities" |
Back to the distribution company. A Dev might build a shared document-processing platform for many businesses. The platform offers an API that takes a file and returns structured data.
A Delta goes to the distribution company, finds out why the accountants reconcile by hand, and uses that platform to build a fitting solution. If the platform lacks a needed capability, the Delta can write the extra code and contribute it back to the core product so later customers benefit too.
That is what makes this model different from a team that only takes software customization requests. The work in the field also produces information that improves the shared product.
In the same 2019 article, Palantir says Delta sits within Business Development, with each team serving one customer directly. Success is measured by the impact on the customer's business goals, not just by finishing features.
In Y Combinator's Lightcone conversation on September 8, 2025, Bob McGrew, who helped build the FDE model at Palantir, explains how Palantir developed the FDE model and why AI companies are adopting it.
Did FDE come from the military?
A common explanation, repeated in many places, is that the FDE name comes from the military. But the origin of the team name needs to be separated from the origin of the whole working model.
| What you may read | What is supported |
|---|---|
| The FDE name comes from the military | Palantir's article does not confirm a military origin for the FDE role |
| "Delta" is a name with military meaning | Palantir explains "Delta" as a trace of how its early Business Development teams were named after the NATO alphabet |
According to Palantir (2019), there is a basis for saying the name "Delta" relates to naming teams after the NATO alphabet. But you can't conclude from that that the whole FDE profession has military origins.
Engineers working directly with customers is an old model. What is new in 2025 and 2026 is not the FDE name appearing, but AI companies increasing their investment in this way of working, with more large investments and programs announced in 2026.
Why did AI companies increase their investment in deployment in 2025 and 2026?
AI can already produce convincing demos, but the bottleneck is getting that capability into business processes reliably. FDE is one way for AI companies to close that gap directly.
In What FDE means at OpenAI, Colin Jarvis calls it the "deployment gap": the distance between what a model appears to do and what users can actually rely on in their work. He founded OpenAI's FDE team in early 2025 to narrow that gap.
In a demo, you can hand the model a hand-picked invoice, write a prompt and get accurate information back. In production, invoices can be blurry, data can be missing, and access rights differ between employees.
One wrong result can flow on into the accounting software, so the system needs a way to catch errors and let a person check the important cases. You can't judge this work just by whether the model answers one prompt correctly.
FDE hiring jumped from 2025
Henley Wing Chiu at Bloomberry analyzed about 1,000 FDE job postings from Revealera data and recorded these notable figures.
| Metric | Result in the analysis |
|---|---|
| Growth in job postings | Up 1,165% from January to October 2025 compared with the same period in 2024 |
| Median salary | 173,816 USD per year, across postings that disclose salary |
| Travel requirement | 68% of positions |
| Size of hiring companies | 58% of positions are at companies with 11 to 200 people |
These figures come from Henley Wing Chiu's analysis at Bloomberry, published November 18, 2025 and updated January 25, 2026. They are results from one job-posting dataset, not statistics for the whole FDE labor market. The salary figure also does not represent FDE pay in Vietnam.
What stands out to me is that 68% of positions in the dataset require travel. That fits the nature of the work, which needs direct contact with systems and people inside the customer's organization.
An FDE doesn't have to sit in the customer's office on every project, but being where the work actually happens remains a defining trait.
OpenAI, AWS and Anthropic invest in deployment
OpenAI, May 11, 2026: Announced the OpenAI Deployment Company, a unit controlled by OpenAI that places FDEs inside customer organizations.
According to the announcement, the unit starts with more than 4 billion USD in initial investment. OpenAI also reached an agreement to acquire Tomoro, a UK AI consultancy, to add about 150 FDEs and deployment specialists. The deal had not closed at the time of the announcement.
Amazon, June 30, 2026: According to Reuters (republished by The Star, June 30, 2026), Amazon committed an initial 1 billion USD to a unit within AWS made up of engineers who work on-site at customers.
Anthropic, October 2, 2026: Announced the Claude Frontier Academy, with a 100 million USD commitment and a goal of training 10,000 "Frontier Deployed Engineers" by the end of 2027. The program recruits participants by nomination.
The three moves are not identical. OpenAI is building a deployment unit, AWS is investing in a team of engineers working directly with customers, and Anthropic is focusing on training.
What they share is that each company is putting resources into getting AI into real work, rather than building models and leaving customers to figure out how to use them.
Why do AI companies accept service-like work?
A software product usually benefits when the same platform is sold to many customers without much rewriting. FDE changes that math somewhat, because engineers have to spend time learning each customer and integrating with their existing systems.
The upfront cost of serving a customer is therefore higher than for a product people can start using by just signing up. Joe Schmidt of a16z, in Trading Margin for Moat on June 4, 2025, argues that AI startups can accept low gross margins early in exchange for a competitive advantage that is hard to copy, gained through hands-on deployment.
I think there is another important technical benefit: the difficulties met during deployment show the company which parts of the product aren't yet good enough for the next customer to use on their own.
Colin Jarvis also put it this way on October 22, 2026: the FDE team's work is only truly done, in a broad sense, when the next customer can solve the same kind of problem without a deployment team. What is learned from customers needs to flow back into improving the product and the model.
If FDEs keep solving the same problem by hand for each customer, the company isn't getting the full benefit of this model.
But as AI companies invest heavily in FDE, another question comes up for people who use coding agents: if AI can already write most of the code, which parts of the FDE job become more important?
How does AI coding change the FDE job?
AI coding can cut the effort of producing code, but it doesn't replace understanding the business or taking responsibility for technical decisions during deployment.
Nguyễn Phi Vân argues that a future FDE may not need to be as strong at coding as a traditional software engineer, but must understand the business better.
She also stresses an important skill: knowing when not to use AI, because an ordinary automation workflow is sometimes cheaper and more stable.
That view comes from Nguyễn Phi Vân's article of October 6, 2026. I agree with the direction of the analysis, but there is a difference between writing code faster and taking responsibility for building a system that works reliably.
Back to the distribution company. You use a coding agent to build an app that reads invoices and reconciles transactions. Here an agent is a program that can call tools on its own and repeat steps to finish a task.
You describe the requirements in a prompt, the agent generates code, writes an API to connect the data and builds a UI for the accountants. The app runs, but some problems still need solving before it goes to production.
Is the data allowed to go into the model?
Invoice photos can contain customer and transaction information. Whoever builds the system has to understand the business's data policy and can't assume an outside API is allowed to receive every document.
What happens when an API fails?
If the accounting software stops responding mid-run, the system may write part of the result and then halt. You need to decide how retries work and avoid creating duplicate transactions.
What stops the agent from acting wrongly?
An agent allowed to use tools can do more than a chatbot that only replies with text. If it has write access to the accounting system, a wrong inference can lead to a wrong action.
You need to separate the operations the agent may perform on its own from those that need human confirmation. Those write permissions and approval steps have to be enforced inside the business application itself, at its own API or runtime. Mechanisms for blocking a coding agent from inappropriate actions through hooks and configuration layers only protect you while you use the agent to write code; they do not travel with the software you deploy.
How do you know the system keeps working correctly?
A few invoices processing successfully does not prove the solution is reliable. You need evals, a set of cases with expected results used to check quality, that test specific cases, including missing data and uncertain reconciliation results.
How will cost change under regular use?
A trial version handling few documents may not reveal the running cost. Once it is in a daily workflow, the number of model and API calls can change, and whoever deploys it has to measure and adjust how it is handled.
These problems don't go away when code is written faster. A trial version can be up and running before the team building it fully understands what is needed to use it safely.
To me, this is where AI coding and FDE meet in an interesting way. The coding agent helps produce the solution, and the FDE has to judge which solution is worth building and what must be verified before it goes to users.
Knowing how to ask AI to write an app is not enough to be an FDE. But being fluent with AI coding, combined with the ability to understand a problem and deploy in practice, can be part of how an FDE works.
FAQ
A few points about FDE are easy to misread, especially since many companies use the same title for different scopes of work.
Does an FDE need to be a strong coder?
An FDE still needs enough technical skill to build, integrate and troubleshoot software. AI coding doesn't remove that requirement.
Bloomberry's job-posting analysis still records programming skills as a requirement in FDE positions, but gives no figure for each level of programming proficiency.
According to Nguyễn Phi Vân, the ability to understand business problems will matter more and more, even as the requirement to write code by hand changes.
You don't have to be the person who writes every line the fastest. But if you don't understand what the code is doing and can't handle errors when it runs for real, it is hard to carry an FDE's responsibility.
Is FDE just consulting under a new name?
You can't conclude that from the title alone. The FDE model has real differences, but the risk of relabeling consulting services as FDE is also real.
Palantir distinguished Delta from consultants by saying Delta builds long-term solutions with the customer, rather than delivering a one-time analysis or recommendation.
Still, a consultancy with a team of engineers who directly deploy and maintain systems can do much of the same work as an FDE.
Gartner has warned about "FDE washing", meaning consulting services labeled as FDE, in its press release of September 29, 2026.
To tell them apart by deployment responsibility, business model and real results instead of job title, continue with FDE or rebranded consulting?
Do Vietnamese businesses need FDEs?
Vietnamese businesses may need FDE-style capability, but not necessarily a person with the FDE title.
In Nguyễn Phi Vân's view, part of the opportunity lies in businesses with many manual processes and data scattered across the tools they already use.
The distribution company with Excel, accounting software and Zalo shows how that kind of problem can appear. It is a hypothetical case, not evidence of how common it is or of demand for FDE hiring in Vietnam.
A small company may only need an engineer who understands the business, or a suitable service provider. What matters is having someone who identifies the right problem and takes responsibility for getting the solution into use.
When does a problem need an FDE, and when not?
An FDE is worth the investment when the problem isn't yet defined clearly enough to become a requirements document and the hardest part is getting the solution into operation. Conversely, if the requirements are clear and an ordinary automation workflow can solve it, you don't need the FDE model.
In the first scenario, the distribution company already has invoice data in a stable format. The accounting team knows the reconciliation rules and can fully describe the exceptions. What remains is moving the data automatically and matching it by the agreed rules.
A software engineer or an automation service provider can handle this from a clear requirements document. Placing an FDE on site for a long period would add unnecessary cost.
In the second scenario, departments haven't agreed on a process and the data sits in several systems. Every software change uncovers a new business exception.
Here, writing a complete requirements document up front may not be feasible. A capable engineer who learns the business while building and adjusting the solution with users will be worth more.
But an FDE has to spend time learning each customer's own systems, may need to work on site, and keeps handling problems after deployment. The business is paying for the whole process of understanding the problem and getting the solution into operation, not just for the code that gets written.
The next two posts in the series pick up from here: FDE or rebranded consulting? looks at telling real FDE work from relabeled consulting, and A path to becoming an FDE with AI coding covers the skills and a practice problem you can work through yourself.
Stopping rule: When the problem is clear, the process is stable and an ordinary team can maintain the solution at lower cost, reduce or end the FDE's deep involvement. If you keep sending engineers to solve the same problem for each customer without improving the product or the way it is deployed, the cost of the FDE model can exceed the value it creates.
Use this piece in your agent
Get an API keyCopy the text below and paste it into Claude Code, Codex or whichever agent you use. The agent reads the piece and checks it against the repo you have open.
Read "What is a Forward Deployed Engineer (FDE)? The role bringing AI into businesses" on modernEngineer and apply it to this repo.
1. Call the content_get tool of the modernengineer MCP server with locale "en", slug "forward-deployed-engineer-la-gi". If MCP is not connected or access is refused, read the page https://modernengineer.dev/en/library/forward-deployed-engineer-la-gi instead.
2. Summarize the main steps of the piece and point out which apply to this repo.
3. Propose concrete changes and ask me before editing any file.Connect MCP in Claude Code (once)
claude mcp add --transport http modernengineer \
https://api.modernengineer.dev/mcp \
--header "Authorization: Bearer <API key>"This piece is open to everyone: without MCP, the agent can still read it straight from the link.
- Version
- v1.0.0
- Updated
- 29/10/2026
- Licence
- All rights reserved
- Slug
- forward-deployed-engineer-la-gi
