An AI deployment meets the workflows, exceptions and governance that already exist. | Image credit: Tanía Diaz / Ordinal
AI companies are putting engineers much closer to the people using their products.
Main takeaways
- Forward Deployed Engineers work where AI products meet real operational conditions.
- Their growth reflects a deployment problem, not simply a new engineering specialism.
- Customer-specific engineering can reveal what the product still cannot handle on its own.
- What one deployment teaches should be built into the product, not re-engineered for the next customer.
- The useful question is where a business’s implementation gap actually sits.
OpenAI currently advertises Forward Deployed Engineer (FDE) roles across sectors including healthcare and legal services, as well as general enterprise deployments. It describes FDEs as engineers who work alongside customer teams from discovery and technical scoping through system design, production rollout and adoption.
Palantir has used forward-deployed roles for years, with engineers working directly with customers on implementation and problem-solving.
The job title is attracting attention because enterprise AI has exposed an old implementation problem in a new form: getting the technology to work is different from getting it to work inside a particular organisation.
When the Demo Meets the Business
A model can perform impressively in a demonstration. Once it enters an organisation, it encounters existing systems, data structures, permissions, workflows, regulatory requirements and people who already have ways of getting the work done.
Recent research reinforces how important those conditions are. A 2026 systematic review of 160 peer-reviewed studies on organisational AI implementation identified recurring conditions for successful adoption: socio-technical alignment, governance, data foundations and organisational capabilities.
Research focused specifically on large language models (LLMs) has reached a similar conclusion. Interviews with providers, adopters and advisers found that enterprise LLM implementation involves aligning the technology with existing workflows, infrastructure, strategic goals and organisational resources. The researchers describe implementation as a multi-stage process rather than a single decision to adopt a tool.
This is the environment an FDE enters.
The engineer may need to understand why a team moves information between two systems, what happens when the standard workflow fails, which errors require escalation or why a technically possible solution would create problems elsewhere.
Those questions cannot always be answered from the product side.
The FDE Can Also Reveal a Product Gap
There is a tension in the model.
Customer proximity can make implementation better. But if every deployment requires extensive bespoke engineering, the FDE may also be compensating for something the product cannot yet do reliably on its own.
That debate is already visible among people working in the field. Vivek Gopalan has argued that the important test is whether knowledge from one deployment gets incorporated into the product, so the next customer does not require the same engineering work. Eugen Alpeza, who says he previously led forward-deployed AI engineering at Palantir, has described part of the current FDE expansion as companies filling a product gap with engineering headcount.
The distinction is useful because OpenAI’s own role description includes both sides of the job. FDEs are expected to work closely with customers, but they are also expected to turn recurring patterns into tools, playbooks and reusable building blocks, and to feed what they learn back into product and model development.
A deployment therefore has value beyond solving the immediate customer problem if it makes the next deployment less dependent on bespoke intervention.
Do You Need an FDE or a Different Implementation Model?
For a company adopting AI, the decision is not necessarily whether to hire someone called a Forward Deployed Engineer.
It is to identify where the gap sits.
A difficult integration, model evaluation problem or production architecture may require embedded engineering expertise.
A technically capable organisation can face a different problem. The workflow may not be well understood. Different teams may follow different versions of it. Ownership may be unclear, or nobody may have defined what successful adoption should change.
Adding engineering capacity does not resolve those conditions by itself.
This is where the FDE trend becomes useful for businesses that will never employ an FDE. It shows how difficult it has become to separate the technology from the environment where it will operate.
The research on organisational AI implementation points in the same direction. Successful adoption depends on technical capability alongside the workflows, governance, people and organisational structures surrounding it.
Before deciding who needs to implement the technology, businesses can ask a more useful question:
Is the problem in the AI, in the way the work operates, or in the connection between the two?
That answer should determine what expertise comes next.
References
- Aguado-García, J.-M., Alonso-Muñoz, S., & De-Pablos-Heredero, C. (2026). The implementation of artificial intelligence in organizations by functional areas: A review and conceptual model. Journal of Management & Organization, 32(4), 1119–1144. https://doi.org/10.1017/jmo.2026.10091
- Wang, X., Zhong, W., Huang, K., & Liang, B. (2025). High interest but low adoption: Navigating organizations’ journey towards generative artificial intelligence implementation. International Journal of Information Management. https://www.sciencedirect.com/science/article/pii/S0268401225001410
- OpenAI. Forward Deployed Engineer (FDE). OpenAI Careers. https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/ (archived 23 September 2026)
- Palantir. Careers. Palantir UK. https://www.palantir.com/uk/careers