Recently, there is a position in the AI industry that is becoming more and more popular: FDE, Forward Deployed Engineer. According to data from Indeed cited by Business Insider, forward-deployed engineering-related positions grew from 643 to 5,330 in one year, a year-on-year increase of more than 700%.
Many people understand FDE as "pre-sales engineer", "implementation engineer" or "consultant". These statements are all correct, but neither is complete.
FDE is not an isolated position but a new organizational interface. It stands between models, products, engineering, customers, business processes and enterprise systems, and is responsible for advancing AI capabilities from demos to real production environments.
The core judgment of this article is:
FDE is not a "pre-sales person who is better at writing code", nor is it an "implementation engineer with a different title". In the AI era, the essence of FDE is to use engineering capabilities to transform high-uncertainty business problems at customer sites into AI applications and production workflows that can be launched, evaluated, and reused.
This judgment comes from the compilation and analysis of public recruitment information: On May 31, 2026, the author compiled 97 FDE/FDSE/FDE-adjacent recruitment information, covering 33 companies and organizations, including OpenAI, Anthropic, Palantir, Google Cloud, Databricks, Mistral AI, Workato, JetBrains, Stack Overflow, Deloitte, EY, BCG X, etc., and analyzed them in this article.
1. History and development of FDE position
The full name of FDE is Forward Deployed Engineer, which literally means "front-line deployed engineer".
This word was first widely recognized and has a lot to do with Palantir. Palantir's FDSE, or Forward Deployed Software Engineer, is a very representative position: entering customer sites, understanding real problems, building software with customers, integrating data, transforming processes, and feeding experience back to the product.
This is the earliest spiritual core of FDE:
It’s not about having a perfect product first and then handing it over to customers for use; it’s about discovering what the product should look like based on customers’ real problems.
In the era of large models, the significance of FDE has been further amplified.
In the past, the difficulties in enterprise software deployment were mainly data, permissions, processes, integration and training. In the AI era, these questions still exist, and new uncertainties are added: Is the model reliable? Can RAG cover real knowledge? Can the agent safely call tools? Which processes can be executed by AI and which must be approved by humans? How to define eval? How to prove business ROI?
These uncertainties are precisely what are most difficult for customers to resolve. What customers really need is not just an API or demo, but someone who can enter the business site and assemble model capabilities, internal data, enterprise systems, permissions governance and business processes into a production system that can run.
In the past few years, everyone was more concerned about whether the model was strong enough to do things. Now the model's ability has reached the expert level in most knowledge-based work.
The popularity of FDE is a signal: the focus of the AI industry is shifting from pure model capabilities to the real implementation of enterprise AI such as deployment, adoption, and measurable impact.
2. Job portrait analysis based on real recruitment information
The 97 recruitment information counted in this article come from public recruitment pages, official job lists and a small number of recruitment summaries. 50 of them come from official job details page or official details page level information. The statistics are based on "number of positions". The same company publishes similar positions in multiple cities and records them as multiple records.
The following is specific data analysis.
1. Which companies are recruiting FDEs?
Among the 97 samples, the company with the largest number of positions is:
| company | Number of positions |
|---|---|
| Palantir | 38 |
| OpenAI | 22 |
| Google Cloud | 5 |
| Anthropic | 2 |
| Other companies/organizations | 30 |
There are a total of 67 samples from the four categories of Palantir, OpenAI, Google Cloud, and Anthropic, accounting for 69.1% of the total samples.
Through the division of job description types, it can be seen that FDE currently has two main lines.
One is Palantir-style FDSE, which focuses on software engineering, data integration and business process transformation in complex customer scenarios.
The other one is OpenAI / Anthropic / Google Cloud-style AI FDE, the core of which is to deploy LLM, agent, RAG, eval, workflow automation and other capabilities into the enterprise production environment.
The technical focus is different, but the underlying logic is the same:They are not simply delivering products, but turning customer sites into part of the evolution of products and platforms.。
2. Analysis of high-frequency requirements
After classifying the 97 recruitment information, we can see several high-frequency capabilities:
| Competency/Requirement Category | Occurrence |
|---|---|
| Client-side, embedded, customer-facing work | 96/97 |
| Production deployment, rollout, online, delivery | 90/97 |
| Integrations, APIs, data, enterprise systems | 80/97 |
| Communication, cross-functional collaboration, ownership, dealing with ambiguity | 84/97 |
| eval, adoption, impact, ROI, success indicators | 73/97 |
| Reusable patterns, playbooks, product feedback, platform abstractions | 74/97 |
| Write code, full-stack, production-grade build | 64/97 |
| Python | 63/97 |
| TypeScript / JavaScript / Node.js | 62/97 |
| AI / LLM / GenAI / Agent / RAG related capabilities | 55/97 |
| Business trip or customer site | 57/97 |
| Security, permissions, governance, reliability, observability | 16/97 |
3. Years of experience: Median is 5 years
In 36 of the 97 samples, clear minimum years of experience could be parsed. Among them, 26 require 5 years or more, accounting for 72.2%; the median minimum experience requirement is 5 years.
This shows that most FDE positions are not junior positions. It requires candidates to have a certain degree of engineering maturity and be able to independently advance problems with incomplete information, unstable requirements, and complex customer systems.
But FDE is not just for senior engineers. The key is not years per se, but whether the candidate can handle ambiguous problems, face customers directly, write production code, make technical trade-offs, measure solutions with business results, and abstract one-time delivery into reusable patterns.
3. Standard paradigm for OpenAI jobs
If you want to understand FDE in the AI era, OpenAI's JD is a good sample.
These keywords appear repeatedly in multiple FDE-related positions at OpenAI:
discovery、technical scoping、system design、build、production rollout、production adoption、workflow impact、eval-driven feedback、product and model roadmap、reusable tools、playbooks、building blocks。
Together, these words are basically OpenAI’s definition of FDE:
FDE is responsible for starting from the customer's real business problems, completing technical clarification, system design, code construction, production online, adoption rate promotion, effect evaluation, and providing on-site feedback to feed back the product and model roadmap.
The eval-driven feedback here is not to simply ask customers "do they feel good", but to define task success criteria, collect failure samples, measure the differences between the old and new processes, and continuously improve the system.
This is significantly different from traditional enterprise software implementation.
Traditional implementation engineers are faced with a relatively certain product: the customer bought it and now needs to configure, integrate, go online, and train it.
OpenAI's FDE faces a more open problem: the customer has a complex process, and AI may be able to change it, but how to change it, what model to use, how to evaluate, how to connect to the system, which links are handed over to AI, and which links require human review, all need to be explored on site.
OpenAI's FDE is not a single position. Variants such as Standard FDE, Platform FDE, Technical Deployment Lead, Domain FDE, FDE Manager, Forward Deployed Software Engineer, etc. can be seen in the sample.
Judging from these job variations, OpenAI is more like building an AI deployment organization rather than just filling a few customer engineer positions.
The key to this organizationNot selling, but deploying; Not demo, but production; not a single point of customer success, but turning the customer site into a feedback loop for the evolution of products, platforms, and models.
4. Technology and capability requirements: FDE’s background is still engineer
When many people discuss FDE, they overemphasize communication, customer site, and business understanding, but ignore a basic fact:
FDE must first be an engineer.
If you can't write code, read the system, debug, or make technical judgments, FDE can easily degenerate into a consultant, pre-sales, or project manager.
Judging from the 97 recruitment information, FDE’s ability requirements are concentrated at four levels.
1. System integration capabilities
Enterprise AI projects are rarely "the user enters a sentence and the model returns a sentence." Real projects usually involve SSO, RBAC, internal databases, CRM, ERP, Slack, Teams, Jira, Snowflake, Databricks, API gateway, approval flow, log audit, monitoring alarms, cost control, grayscale release and rollback mechanism.
This explains why out of 97 samples, 80 involve integration, API, data, and enterprise system.
FDE does not need to be proficient in all enterprise systems, but must be able to quickly enter unfamiliar systems, understand the boundaries, and make operational integration solutions.
2. Full-stack and production code capabilities
64 samples explicitly involve writing code, front-end and back-end, production-grade build, or full-stack capabilities.
This shows that FDE is not just someone who draws architectural diagrams. In many cases, FDE needs to make the prototype himself or even harden the critical path to production.
In AI scenarios, common construction contents of FDE include internal copilot, agent workflow, RAG applications, evaluation platforms, business process automation tools, approval interfaces, data connectors, model calling services, and monitoring dashboards.
FDE's engineering capabilities are not necessarily reflected in the depth of the algorithm, but in "the ability to put the system together, run it stably, and put it online."
3. LLM/Agent/Eval capabilities
Among the full sample, 55 items reflected AI/LLM/GenAI/Agent/RAG related capability requirements. This number adopts a wide range, and the purpose is to measure whether the position is related to AI deployment, rather than simply counting how many times certain words appear.
This shows that the new generation of FDE needs to understand the real behavior of the LLM system, rather than just knowing how to call the model API.
At least understand prompt, structured output, RAG, tool calling, agent workflow, human-in-the-loop, eval data set, hallucination risk, latency / cost trade-off, observability and failure mode analysis.
Especially eval. FDE cannot just say "the model works well", but must be able to answer: What is good about it? How to test? How much is it improved compared to the old process? What is the failure sample? How to continue monitoring after going online? Is it worth expanding deployment?
Without eval, FDE can only stay in demo. With eval, FDE can drive production adoption.
4. Communication, product judgment and organizational promotion capabilities
The 84 samples cover requirements such as communication, cross-functional collaboration, ownership, and ambiguity handling.
This is not a soft skill embellishment, but a core competency of FDE.
FDEs need to be able to talk about ROI with customer business leaders, system boundaries with CTOs/architects, permissions, auditing, and data isolation with security teams, workflows with frontline users, and reusability capabilities with internal product teams.
Summarize FDE’s capability model into one sentence:
Engineering capabilities are the foundation, AI system capabilities are tools, product judgment is the lever, and customer on-site advancement is the amplifier.
5. The difference between FDE and pre-sale: pre-sale proves “can be sold”, FDE proves “can be used”
FDEs can easily be misunderstood as pre-sales engineers, because they are all on the customer side, doing demos, and explaining technical solutions.
But the core goals of the two are different.
The core tasks of pre-sales engineers are to help customers understand product value, complete technical demonstrations, answer security, architecture, and integration questions, support sales in promoting deals, and prove that products meet purchasing conditions.
The goals of FDE are further back and deeper: connect the system to the customer's real environment, write code or guide the customer engineering team to build, let the solution enter the production workflow, promote user adoption, define eval and success indicators, discover reusable patterns, and feed back the product and model roadmap.
Therefore, the difference between pre-sales and FDE is not "who is more advanced", but "being at a different position in the value chain".
The pre-sales solutions are:
Why should customers buy?
FDE solves:
How does it really turn into business results after a customer buys?
6. The difference between FDE and implementation engineers: implementation delivers products, FDE defines solutions
Compared with pre-sales, the boundary between FDE and implementation engineers is more subtle.
Many people say that FDE is not just an implementation engineer? This statement is not completely wrong. FDE does include implementation.
FDEs and implementation engineers both work on the customer side, deal with system integration, promote go-live, solve on-site problems, and deal with customer IT, business, and engineering teams.
But simply equating FDEs with implementation engineers misses the most critical difference:
Who defines the solution.
The default premise of the implementation engineer is that the product has been relatively determined, the customer has purchased it, and now it needs to be configured, integrated, migrated, tested, trained, and launched online.
It deals with “the uncertainty of a known product in the customer environment.”
The default premise of FDE is: the customer has a high-value but vague problem. Existing product capabilities may only cover part of it, and it needs to be judged, built, verified, and launched on-site, and decisions should be made on what should be productized.
It deals with "the uncertainty of the solution itself."
Therefore, implementation engineers are responsible for reducing delivery uncertainty. FDE is responsible for transforming high-uncertainty customer problems into deliverable, reusable, and productizable systems.
If a so-called FDE can only do configuration, migration, training, and online support, but cannot write core code, cannot affect the product roadmap, cannot define eval, and cannot precipitate reusable patterns, then it is essentially the implementation engineer changing the title.
On the other hand, if a position called Implementation Engineer can write code in depth, influence products, define customer problems, and abstract platform capabilities, then it is very close to FDE in terms of capabilities.
So, don’t look at the title, look at the boundaries of responsibilities.
Implementation engineers deploy products to customer sites. FDE deploys customer site problems back to the company's product system.
The real value of FDE is not that it "can also be implemented", but that it can turn every implementation into a closed loop of learning about the company's market, product and model capabilities.
7. The difference between FDE and consultants: Consultants help clients think clearly, while FDE wants to get things done.
FDE is also often compared to consultants. This comparison is interesting because FDE does inherit many consulting skills: understanding the business, interviewing customers, breaking down processes, identifying high-value scenarios, communicating with senior management, and driving organizational change.
The real difference between FDEs and consultants is not who can discover AI opportunities, but who is responsible for "turning AI opportunities into production systems."
The core value of a consultant is usually to help clients define problems, identify opportunities, design solutions, plan roadmaps, promote organizational consensus, and manage complex change processes. Even if they participate in implementation, they often focus more on business solutions, process transformation, project promotion and organizational collaboration.
FDE must continue to go deeper into the project: Can this process really be transformed by AI? In which systems is the data located? How to clear permissions? What tools can the agent call? How to make the first version of prototype? How to define eval? Who will use it after it goes online? How are indicators monitored? How to give feedback on failed samples? Can this model be copied to the next customer?
In other words, consultants can help customers determine "where is it worth using AI", and FDE must further answer "how to make this AI system, how to put it online, how to evaluate it, and how to reuse it."
Therefore, the difference between FDEs and consultants is not "who understands the business better", nor "who can think of AI scenarios", but who is responsible for the closed loop from problem definition to engineering implementation, production launch, effect evaluation and product feedback.
| Dimensions | consultant | FDE |
|---|---|---|
| core delivery | Diagnosis, plan, roadmap, change recommendations | Runnable system, production deployment, business results, reusable model |
| Work focus | Help customers think clearly | Help customers make it and run it |
| Ability base | Business analysis, industry insight, communication, project promotion | Engineering capabilities, system integration, AI workflow, customer promotion |
| success criteria | Solution quality, customer recognition, strategic clarity | production adoption、workflow impact、eval、ROI |
| relationship with product | Usually do not directly change the product | On-site experience must be fed back into products, platforms and models |
| Main risks | Stay with PPT and suggestions | Caught in one-off customization and engineering firefighting |
This is why the statement “Consultants can do FDE” needs to be interpreted with caution.
A small number of technical, data-based, and product-based consultants do have the opportunity to switch to FDE. But most traditional strategy consultants cannot directly become FDEs by taking a few AI courses.
Real FDE requires a lot of engineering skills: you need to be able to write production code, understand APIs, permissions, deployment, monitoring, testing, security, cost and troubleshooting. Without these abilities, the best you can do is become a business leader or deployment strategist in an FDE team, rather than a full FDE.
A more reasonable statement is:
Future consulting teams need to be FDE-ified, but not every consultant will become an FDE.
Ask the consultant to explain the problem clearly. FDE turns problems into systems.
An excellent AI implementation team requires the combination of two abilities.
8. People with different backgrounds are suitable for different FDE routes
FDE is not a single portrait. According to the recruitment information, several typical routes can be seen.
1. AI Lab FDE
Representative companies include OpenAI, Anthropic, Google Cloud, Mistral AI, etc.
This type of position is suitable for people who are familiar with LLM, agent, RAG, eval, tool use, and workflow automation, and who also have strong engineering capabilities and customer communication skills.
The key is not "knowing how to use an agent framework", but understanding why the LLM system fails in the production environment, how to test, how to control risks, and how to enter the real process.
2. Palantir-style FDSE
This type of route places greater emphasis on complex business, data systems, customer sites, and high-voltage delivery.
It does not necessarily require candidates to be LLM experts, but it requires candidates to be able to use software to solve problems in chaotic reality.
Suitable for full-stack engineers, data engineers, backend engineers, infra engineers, and engineers with consulting or customer site experience.
3. Platform FDE
Platform FDE not only works on customer projects, but also abstracts recurring problems at customer sites into platform capabilities.
For example, unified eval framework, permissions and audit modules, enterprise data connectors, agent workflow templates, observability tools, deployment playbook, and reusable integration layer.
This type of route is suitable for platform engineers, infra engineers, developer platform engineers, and full-stack engineers with strong abstraction capabilities.
4. Domain FDE
Some FDE positions are not pan-AI, but strong field-based, such as semiconductors, national defense, finance, medical care, manufacturing, energy, etc.
The barrier to this type of position is that the customer problem itself has high domain complexity. It is not enough to understand AI, you must understand the industry language, processes and constraints.
In addition, once both domain understanding and AI are implemented, scarcity will be very high.
5. Technical Deployment Lead
This type of position is more focused on the person in charge of delivery. They may not necessarily write the most code every day, but they are responsible for the technical roadmap, milestone, scope, dependency, acceptance criteria, stakeholder management and adoption.
It is suitable for technical program managers, solution architects, staff engineers, engineering managers, and technical leaders with strong customer delivery experience.
6. Implementation engineers, pre-sales or consultants transfer to FDE
Strong implementation engineers, strong pre-sales engineers, and technical, data-oriented, and product-oriented consultants all have the opportunity to transfer to FDE.
The advantage of an implementation engineer is that he understands go-live, customer systems, and project delivery; his shortcomings are usually product abstraction, engineering depth, and outcome indicators.
The advantage of pre-sales engineers is that they understand customers, value expression, and stakeholders; their shortcomings are usually production code, system design, post-launch adoption, and real responsibility boundaries.
The advantage of consultants is that they understand business issues, understand process dismantling, understand high-level communication, and are better at explaining complex issues clearly; their shortcomings are usually engineering implementation, system integration, production deployment and long-term operation responsibilities.
Conclusion
The concentrated emergence of FDE is not only the invention of a new title in the recruitment market, but also the organizational response as AI enters a new stage.
When models are not strong enough, what the industry lacks most are researchers and model engineers.
When model capabilities begin to be strong enough, what the industry lacks most is people who can bring the model into the real process.
FDE solves this problem.
It connects two worlds:
On one side are models, APIs, agents, RAG, eval, and platform capabilities;
On the other side are customer organizations, business processes, permission systems, historical baggage, IT security, user habits and ROI pressures.
There is a long gulf between these two worlds. The value of FDE is to fill this gap.
To the company, FDE is not a "more expensive implementation team" or a "more technical pre-sales team." Without engineering authority, product closed loop and reusable platform, FDE can easily degenerate into high-end project outsourcing.
For me personally, FDE is not a position that can be easily entered by relying on AI enthusiasm. It requires engineering and AI capabilities, communication skills, business judgment, product awareness, and delivery resilience. It is suitable for those who are not satisfied with just writing module code, nor are they satisfied with just explaining solutions, but are willing to enter real complex scenarios and make things happen.
There is no shortage of demos in the AI industry. What is really scarce are people who can push demos past the last mile.