Key takeaways
- A forward deployed engineer (FDE) is not a consultant and not a solutions architect. They write production code in your environment and feed what they learn back into the product you are buying.
- The model started at Palantir and spread through AI vendors because LLM products are hard to adopt without someone inside the building.
- For a buyer, the trade is speed for access. You get an engineer who can move faster than your own change process allows, and in return you give an outsider production reach.
- The usual failure is not a bad engineer. It is a working system that only one person understands, delivered under a contract that never mentioned handover.
- If a vendor offers FDEs, ask about access, evidence and exit. Seniority matters less than those three.
A forward-deployed engineer is a vendor’s software engineer who works inside the customer’s systems, building and shipping against real constraints and feeding what they learn back into the product. The role exists because some products cannot be adopted at arm’s length.
The term is everywhere. OpenAI’s careers listing, read on October 19, 2026, shows a team called Forward Deployed Engineering with roles open in San Francisco, Seattle, New York, Washington DC, London, Madrid, Munich, Paris, Zurich, Seoul, Singapore, Sydney, Tokyo and Abu Dhabi. It also lists variants for financial services, healthcare, legal and government, plus a Forward Deployed Security Engineer. That is a function being built out worldwide, not an experiment.
Most of what is written about the role is written for people who want the job. This guide is written for the people who end up paying for one.
What is a forward deployed engineer?
A forward deployed engineer is a vendor’s engineer who builds inside the customer’s environment and is responsible for the outcome, not just the advice.
Gergely Orosz describes the role in What are Forward Deployed Engineers, and why are they so in demand? (The Pragmatic Engineer, August 12, 2025) as a mix of embedded work with customer teams and work on the core product, combining software engineering, sales and platform engineering. He traces it to Palantir, where FDEs were known internally as “Deltas” and outnumbered traditional software engineers until around 2016.
Three properties define the role. A role missing any of them is something else.
- They write code that runs in your environment. Not slides and not a reference architecture. Working software against your data, your identity system and your release process.
- They are employed by the vendor, not by you. Their incentive is that the product succeeds in your estate. That lines up with your interests but is not identical to them.
- What they learn goes back into the product. This is what sets the model apart commercially. Orosz gives the example of OpenAI FDE work for a call center customer informing a voice model improvement, so one customer’s hard problem becomes a product capability.
Orosz also notes the honest complication: the role is often mistaken for consulting, and the line between consultant and engineer can blur. His distinction is long-term customer work plus contribution back to the product.
This summary reflects the free portion of that article, which is paywalled after the section on Ramp.
Where did the role come from, and why is it everywhere now?
Palantir invented it for customers whose internal bureaucracy was the binding constraint, and AI vendors adopted it because their products have the same adoption problem.
Palantir’s insight was that, for large enterprises and government agencies, the obstacle to value was rarely the software. Nobody inside the organization could line up the data, the access and the decisions fast enough. An embedded engineer could move faster than the customer could alone. They were not better engineers. They were outside the customer’s own approval chain.
AI products create the same condition. Orosz names OpenAI, which stood up an FDE team in 2025 alongside its Solutions Architect role. He also names Ramp, with roughly 15 FDEs working in pods, and describes similar roles at Commure, Matta, Gecko Robotics, Lindy and Salesforce. He reports on-site time ranging from about 25% at Palantir to as much as 50% at Commure.
The underlying reason matters, because it decides whether you need the model. An LLM product does not fail at installation. It fails when someone has to decide which of your processes it touches, what it is allowed to do, which data it may read, and what “good enough” means for your workflow. Those decisions belong to neither the vendor nor the customer alone. They need someone who understands both the product’s real limits and your real constraints, sitting in the same room.
Explore Forward Deployed Engineering for Your Enterprise
Connect business priorities with hands-on engineering to integrate AI, solve operational challenges, and implement solutions within your existing technology environment.
What do FDEs do at Palantir, OpenAI and Anthropic?
At the companies that built the model, FDEs work embedded with customers on production deployments and feed what they learn back to product teams. The detail differs by company, so rely on each company’s own postings rather than on commentary.
What the public record supports, and no more:
- Palantir. Orosz traces the role to Palantir and reports the internal name “Deltas.” He reports on-site time of about 25%.
- OpenAI. The careers listing read on October 19, 2026 shows a dedicated Forward Deployed Engineering team across more than a dozen cities, with sector variants. Orosz reports that the team was stood up in 2025 and that its work on customer problems can feed product improvements.
- Anthropic. A Forward Deployed Engineer posting on Anthropic’s Applied AI team, read on October 23, 2026, says the engineer “embeds directly with our most strategic customers,” works “within customer systems to build production applications with Claude models,” and contributes “insights back to our Product and Engineering teams.” It lists customer-site travel of 25 to 50 percent.
Treat anything beyond postings and named first-hand reporting as opinion.
How is an FDE different from the alternatives?
An FDE owns delivery of a working outcome inside your estate. That is a different job from advising, demonstrating or supplying capacity.
The last row matters most for a buyer. Each model has a typical failure, and they are not interchangeable.
- A consultant fails when the recommendation cannot be implemented in your estate, which you find out after the engagement ends.
- A solutions engineer fails at the production boundary. The demo worked on chosen inputs and nobody owned what came next.
- Staff augmentation fails when capacity is supplied against a backlog that no senior person is shaping, so you get speed in the wrong direction.
- An FDE fails by succeeding in a way you cannot sustain. The system works and is in production, and the understanding of how it works leaves with the engineer.
That last failure is specific to this model, and it is the one to contract against. If you are comparing the two models directly, see forward deployed engineers vs staff augmentation.
Why has the model spread to AI delivery?
The gap between an AI demo and an AI system in production is made of decisions that only someone inside the organization can make and only someone who knows the technology can frame.
That gap lines up closely with the gates in the PoC-to-production checklist: production-shaped data, a service identity with scoped permissions, a reversible write path, an evaluation set with a recorded baseline, a measured cost per transaction, an exception path, and a named owner after handover.
None of those is a model problem. Each one means negotiating with a data owner, a security reviewer or a process owner, and knowing what to ask for. A vendor at arm’s length cannot do it. A customer without deep product knowledge does not know what to ask. The embedded engineer sits in that gap.
The same logic explains why the model shows up around legacy estates. Where the constraint is a system nobody wants to touch, the person who can move is the one with product knowledge and a mandate to work inside the customer’s environment. That is the staffing argument behind legacy application modernization services as much as an AI one.
Turn Enterprise AI Strategy Into Working Solutions
Work with engineers who understand your business processes, technical constraints, and integration requirements to move from AI use cases to practical implementation.
When should you ask a vendor for forward deployed engineers?
Ask when the obstacle is inside your organization rather than inside the product. Otherwise the model costs you access for no gain.
Buyers get the fifth condition wrong in both directions. If you want your own team running the system afterward, the FDE model suits you, but only if transfer is written into the engagement rather than hoped for at the end. If you do not want to run it yourself, you are describing a managed service. Buy one, with an availability commitment and a support model, instead of an embedded engineer.
What does the model cost you that a normal engagement does not?
Access, and access is hard to take back. Four costs never appear on an invoice.
Production reach for a non-employee. An embedded engineer who can only work in a sandbox is not embedded. So the model means giving an outsider meaningful access to live systems. That is a security and compliance decision before it is a commercial one, and the people who own those risks should make it.
Key-person concentration. The engineer who built it understands it. If the engagement ends without deliberate transfer, you depend in production on a person your vendor employs.
Blurred accountability. When a vendor’s engineer builds in your estate, using your data, against your process, who owns a production defect is unclear unless you settled it in writing.
Product-direction asymmetry. The feedback loop that makes the model attractive to the vendor means your hard problems shape their roadmap. That is usually good for you. Know that it is happening and ask what of your context travels back.
What should you require in the contract?
Six things. The three about exit matter more than the three about the work.
| Requirement | Why | What goes wrong without it |
|---|---|---|
| Named individuals, with substitution rights | You are buying specific people. The model is personal by design | A strong first team is quietly rotated out |
| Scoped, time-bound, reviewable access | Production reach for a non-employee needs an owner and an expiry | Access outlives the engagement and surfaces at an audit |
| Code, tests and IP ownership stated explicitly | The work is built in your estate but written by their employee | A dispute at the moment you want to leave |
| Documentation as a deliverable, not a favor | This is the model’s typical failure | A working system nobody inside understands |
| A named internal counterpart per workstream | Transfer happens continuously or it does not happen | Handover becomes a meeting at the end |
| A defined exit: what you hold on the last day | The engagement will end | You renew because you cannot run it without them |
Negotiate the last three hardest. They are the ones most likely to be waved through, because the early weeks of a good FDE engagement feel excellent. That feeling is the risk. Speed creates the impression of transfer, and the two are unrelated.
The decision
Treat forward deployed engineering as an access decision, not a staffing one. The model works because it puts someone with product knowledge inside your approval chain. Everything that makes it effective, including production reach, closeness to your data and authority to build rather than advise, is something you grant rather than buy.
Run the five conditions before you ask for it. If fewer than three apply, buy a conventional engagement. If three or more apply, spend your negotiating effort on documentation as a deliverable, a named internal counterpart per workstream, and a written definition of what you hold on the last day. The engagement will feel fast and productive long before it is transferable, and that gap is where renewal pressure comes from.
GrowExx offers this model as forward deployed engineering services, engaged as a sprint, a pod or a program. Its stated terms include client ownership of code and IP, least-privilege access that is revoked at handover, and runbooks, documentation and knowledge transfer at the end. Hold any vendor to the contract list above, including us. For wider AI delivery, see AI consulting and AI agent development.
FAQs
What is a forward deployed engineer?
A software engineer employed by a vendor who works inside a customer’s organization, in their systems and with their data, building and shipping production software against the customer’s real constraints and carrying what they learn back into the vendor’s product. The role began at Palantir and is now common at AI companies. OpenAI’s careers listing shows a dedicated Forward Deployed Engineering team across more than a dozen cities.
What is the difference between a forward deployed engineer and a consultant?
A consultant produces a recommendation. A forward deployed engineer produces working software running in your environment and answers for it. The second difference is the product feedback loop: an FDE’s work on your problem informs the vendor’s roadmap, and a consultant has no way to do that. The line does blur in practice. The practical test is whether the deliverable is a document or a running system.
Is a forward deployed engineer the same as a solutions engineer?
No. A solutions engineer or architect usually works at the boundary, scoping, designing and demonstrating, often to win the deal, and hands over where production begins. A forward deployed engineer crosses that boundary and owns delivery inside the customer’s estate. Several companies run both roles side by side. OpenAI stood up its FDE team alongside an existing Solutions Architect role.
When does the forward deployed model make sense for a buyer?
When the obstacle is inside your organization rather than inside the product. The work touches several systems of record you control, your own approval process is slower than the build, the rules that matter are undocumented, nobody has deployed this product against your use case before, and you want your own team running it afterward. If fewer than three of those apply, a conventional engagement does the same work without giving an outsider production access.
What should you require before letting a vendor’s engineer into production?
Scoped, time-bound, reviewable access with a named internal owner. Explicit agreement on who owns the code, tests and IP. Documentation as a contractual deliverable. A named internal counterpart for each workstream so transfer happens continuously. A written definition of what you hold on the last day. The typical failure is not poor work. It is good work that only the departing engineer understands.
Find the Right Engineering Model for Your Enterprise
Book a Strategic Assessment
