Quick summary: By my evaluation framework, an FDE contract worth paying for does more than deploy a system on the customer's site. What the team learns has to flow back into the vendor's product, and the customer has to be able to run and extend the system after the team leaves. Gartner predicts that through 2028, fewer than 20% of FDE contracts will turn a customer's repeated needs into features in the core product. So before you sign, pin down the deliverables, the knowledge transfer, and the exit plan.
A hypothetical example used throughout: A small distribution company in Vietnam wants to automate invoice reconciliation. An AI software vendor offers a package: "an FDE team on site for 3 months." The team works with the accountants, connects the systems, and puts the workflow into production. But after the team leaves, every time an invoice template changes, the company has to call the vendor to fix it and pay extra. The system runs, but the people who truly understand it don't work for the company.
This matters now because OpenAI and Anthropic both announced large investments in enterprise AI deployment capacity in 2026. At the same time, Gartner is warning about "FDE washing": putting the FDE label on consulting services that don't deliver matching value. The announcements are on the OpenAI and Anthropic sites, and the warning is in Gartner's release.
A Forward Deployed Engineer (FDE) is an engineer who brings a vendor's technology into a company's real operating environment. I explain the role in more detail in What is a Forward Deployed Engineer (FDE)?. The criterion to check when hiring an FDE is which capabilities stay with the company after the deployment team leaves.
Why do many people say FDE is just rebranded consulting?
Because from the outside, the work of an FDE and the work of a deployment consulting team can look almost identical. Both come to learn what the customer needs, connect systems, and write custom software. If you only look at the daily activity, it is hard to tell a product-development model from a deployment service with a new name.
In its September 29, 2026 release, Gartner analyst Mukul Saha said many vendors are applying the "forward deployed" label to activities that used to be called implementation, professional services, solution engineering, or AI consulting. Some are genuinely rethinking their operating model. Others use the label because it sounds more strategic.
Gartner calls the practice of marketing consulting services under the FDE label "FDE washing." Saha warns that some vendors charge premium prices without matching depth in deployment or change management. Customers may see fast progress at first but never build the internal capability to continue afterward.
The debate is not only coming from Gartner
In a March 16, 2026 post, Ethan Mollick said that embedded AI deployment engineers are useful, but he is not sure they will deliver what many companies expect. In his view, bringing AI into a company is often not mainly a technical problem. Companies also have to rethink how they use deep expertise and how they organize work around AI.
Take the distribution company from the opening. The engineering team can build a flow that reads invoices and flags discrepancies. But who decides which cases need an accountant to check? When the data doesn't match, which department is responsible for handling it? Writing more code does not settle these organizational decisions.
In a satirical post on May 12, 2026, Mollick called the newly formed teams "consulting (sorry, forward deployed engineering)." His point is that as long as people have to work out where AI helps, change the organization, and integrate systems, that work still needs people to do it.
Gergely Orosz offers a different objection. In a May 14, 2026 post, he argued that you can't really be an FDE unless the engineer works for the company that builds the platform. The appeal of the role is the ability to contribute back to the platform after working with customers, rather than just wiring systems together and pushing customers to use more tokens.
By Orosz's reading, the distinguishing question is whether the vendor's product changes after each deployment. If the answer is always no, the engineering team may still do good work, but the model is not necessarily different from traditional consulting.
The skeptics have a point: renaming a role does not create product capability. So why do tech companies and investors still want to grow the FDE model?
If it is easy to confuse with consulting, why does FDE still attract investment?
Because a vendor can accept heavy deployment costs early in order to improve the product and build an advantage that is hard to copy later. Instead of selling software and leaving customers to figure out how to use it, vendors put engineers into real environments to learn things they can't see during product development.
The a16z view: don't optimize margin too early
On June 4, 2025, Joe Schmidt, a partner at the venture firm a16z, published Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups.
Schmidt argues that AI startups selling complex products to enterprises should invest in hands-on deployment services such as FDEs. That may lower gross margin at first. But if the deployments help the startup understand real needs and improve the product, the upfront cost can turn into an advantage that is hard to copy. In his view, a company should prioritize growing total gross profit as fast as possible rather than focusing only on gross margin percentage.
Schmidt gives two cases:
| Company | Gross margin at IPO | Gross margin in 2024 |
|---|---|---|
| ServiceNow | 63.2% | 79% |
| Workday | 54.1% | 75% |
Data source: Joe Schmidt, a16z, June 4, 2025.
These numbers show that both companies' gross margins rose over time, but they do not establish FDE as the cause of the increase. Schmidt uses them to illustrate a business choice: spend resources serving customers directly if what you learn lets the product serve later customers better. This is a strategic argument from an investor's point of view, not a guarantee that every startup that builds an FDE team will succeed.
The OpenAI view: each customer should make the next one easier
Colin Jarvis, Head of Forward Deployed Engineering at OpenAI, explains the team's goal in What FDE means at OpenAI, published around October 22, 2026.
Jarvis says he started building the team in early 2025 to close the "deployment gap": the distance between a model appearing to do a task and a company being able to use that capability reliably in its work.
According to Jarvis, each FDE engagement should leave a better starting point for the next customer. If the next customer no longer needs an FDE to solve the same class of problem, that is a sign the team did well. Problems learned from customers are fed back into the product, and specific problems are passed to the research team.
OpenAI describes one semiconductor customer. After custom applications went into production, the FDE team moved them onto a shared harness built around Codex, the layer that controls how agents behave, with the custom parts packaged as plugins and skills.
By OpenAI's own figures, in this semiconductor case the move to the shared harness removed about 90% of the custom code in each project. In an August 2026 example OpenAI gives, the first deployment took two months, while expanding to a second team took one day. Both figures come from OpenAI's What FDE means at OpenAI.
The mechanism that matters here is reuse. At first, engineers solve the customer's specific problem. Along the way, they spot the parts that can be shared and package them so the next deployment doesn't start from scratch. Deployment work becomes an input to product development.
Palantir treats FDE as product strategy
From the perspective of someone who works at Palantir, Chad Wahlquist argues that the company has no services business and that forward deployed engineering is product strategy, not go-to-market strategy. He says this is something many people misunderstand about FDE, in a July 2, 2026 post.
This view has something in common with the arguments from Schmidt and Jarvis. If a deployment team only produces custom software for each customer, the company has to put in the same effort again on every new contract. If the team finds shared needs and improves the platform, the same investment can pay off across many customers.
So the two sides of the debate don't necessarily contradict each other. FDE can be a product-development strategy, but it can also run as a headcount-dependent consulting service.
How do you tell a real FDE from consulting with an FDE label?
In my view, check two outcomes after the FDE team leaves: whether what they learned from the customer flows back into the vendor's product, and whether the customer can run and modify the system on its own. A team that delivers both has a clearer claim to being an FDE in the product-strategy sense.
Two endings to the same project
Ending A: The system runs, but the customer stays dependent.
The distribution company from the opening gets a working invoice reconciliation system, but its internal engineers have no eval suite (sample invoices with expected results, scoring rules, and a way to rerun them after every change) and don't know how to fix the flow when an invoice template changes. The custom code is never folded into the vendor's shared product, so the next customer still needs a separate deployment project.
Ending B: The customer runs it themselves, and the shared product improves.
From the start, accountants and internal engineers sit with the FDE team to agree on the handling cases and build an eval suite. By the end of the contract, the internal engineers know how to fix the workflow, rerun the evals, and decide when a human needs to check. The vendor also moves the reusable invoice-reading part into the shared product so the next customer doesn't have to rebuild it.
A table for evaluating vendors
| Criterion | Product-development FDE | Consulting with an FDE label |
|---|---|---|
| Goal | Solve the customer's problem and improve the shared product | Complete a customer-specific scope of work |
| Code after deployment | Reusable parts go into the product, plugins, or skills | Custom parts mostly stay inside the customer project |
| Learning from customers | Repeated problems become input to product development | Knowledge mostly stays with the deployment team |
| Knowledge transfer | The internal team helps build it and knows how to change the system | The customer mostly receives a system to use |
| Verification | There is a way to check the system after the FDE team leaves | Checking and fixing still depend on the vendor |
| End of contract | The customer can run and extend the system on their own | The customer keeps needing the same team for routine changes |
This is my own evaluation framework, not an FDE certification standard.
A traditional consulting firm can still transfer knowledge well and leave the customer able to run the system. Conversely, a team with the exact FDE title can still produce a vendor-dependent system. The name of the role cannot replace checking the outcome.
Gartner predicts the rate of turning customer needs into product will stay very low
In its forecast published on September 29, 2026, Gartner says that through 2028, fewer than 20% of FDE contracts will turn a customer's repeated needs into features in the vendor's core product.
It is notable that Gartner picked this very capability to assess the model's risk. It is close to what Jarvis describes at OpenAI and to the test Orosz uses to separate FDEs from ordinary deployment roles.
However, a vendor's ability to develop its product is not enough to protect the customer. A platform can learn a great deal from a project while the customer still can't fix its own system. That is why the two criteria need to be checked separately: the vendor has a mechanism to feed repeated needs into the product, and the company receives the ability to operate on its own.
You need to turn those two criteria into contract terms you can verify before signing.
What should you settle before hiring an FDE team?
Settle the scope of work, who is accountable, how results will be verified, and the exit conditions before the FDE team starts. Don't wait until the system is in production to ask who takes over.
In its September 29, 2026 release, Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI systems built by vendor FDE teams, because costs climb sharply and the company can't develop the system further on its own. Agentic AI here means AI that can plan and call tools to carry out a sequence of tasks.
According to Mukul Saha, many FDE contracts have structural problems before they have technical ones. Gartner therefore splits contract management into three stages: before signing, during deployment, and at exit.
Below is the checklist I derived from Gartner's framework, written as questions you can use in conversations with a vendor.
Before signing
- Does the problem really need an FDE? Does any part require deep knowledge of the vendor's product, fast adaptation, or tight integration with internal systems that an ordinary deployment team would struggle to handle?
- Who on the vendor's product side picks up recurring needs? Is there a named product contact, an example of a past customer need that became a shared feature, plugin or skill, and a place where this project logs such needs? The vendor does not need to promise that every customization goes into the core.
- Who is accountable for the business outcome? Is there an executive sponsor responsible for the invoice reconciliation results, rather than someone who only approves the deployment budget?
- What does the contract deliver, and who owns what? Does it clearly define the code, configuration, operating documentation, intellectual property, knowledge-transfer responsibilities, and exit conditions?
During deployment
- Who on the company side works alongside the FDE team? Do the accountants who own the process and the internal engineers sit with the FDE team, and do end users take part in testing the system?
- How is each release verified? Is there an eval suite in the handover assets, not just on the vendor engineer's laptop? Is it spelled out which cases the AI may handle on its own and which need human oversight?
When the FDE team exits
- Can you run and fix the system yourself? Can internal engineers update the invoice-reading workflow, rerun the evals, and handle changes without calling the FDE team?
- Under what conditions does the vendor exit? Do both sides carry out the exit plan agreed at the start, rather than extending the contract because the internal team isn't ready?
This three-stage framework comes from Gartner's September 29, 2026 release.
For the distribution company in the opening, a handover only means something if internal engineers can support a new invoice template and rerun the eval suite to see whether the change broke old cases. That is also why the exit stage in Gartner's framework has to be prepared from day one: the ability to take over must form while the two teams work together, not start on handover day.
A simple handover test: internal engineers adapt the system to a new invoice template on their own, rerun the agreed eval suite, and the accountants confirm the result against pass criteria set at the start of the project.
From the company's side, the checklist reduces dependence on the vendor. For someone who wants to become an FDE, what does it demand in terms of professional skill?
What does this mean if you want to become an FDE?
A good FDE is valuable not only for building a solution for the customer but for making the customer need them less after each deployment. That takes the skill to build systems plus the ability to hand them over and spot what can be reused.
This is the spirit of how Colin Jarvis describes the FDE team's goal at OpenAI: each engagement should create a better starting point for the next customer, as he writes in What FDE means at OpenAI.
Writing a workflow that uses a model to read invoices is a technical result. But if only the person who wrote it knows how to fix it, the system still depends on one individual. An FDE needs to make clear how the system is verified, when a human must step in, and how the internal team keeps operating it.
For the parts that get reused, the engineer also needs to know how to separate them from the customer's own code and package them as shared components. OpenAI's example of moving custom applications onto a shared Codex-based harness, with plugins and skills for the custom parts, shows one concrete way to do it, per the same OpenAI post.
In my view, two capabilities are easy to undervalue if you see an FDE only as a coding job:
Capability transfer: Not just showing users how to operate the system, but helping internal engineers understand how it works, verify it, and change it.
Packaging knowledge: Not just finishing the customer's request, but recognizing which parts can become a general capability of the product.
An engineer can write code fast and still not be good at these two things. Conversely, understanding the business and working well with people is not enough if you can't build or verify systems in a real environment.
If you want to go this way, I'll go deeper into the skills and how to learn them in A path to becoming an FDE with AI coding, the next post in this series.
Frequently asked questions
Gartner's warnings are easy to read as saying FDE has no value, while the AI labs' investments suggest the opposite. It helps to separate a forecast about deployment risk from each party's business argument.
Is Gartner saying FDE is the wrong model?
No. Gartner warns that how FDE is deployed and how the contract is structured can leave companies dependent on the vendor, and it also gives guidance on when to use FDE.
Those cases include problems that need deep product knowledge, fast adaptation, or tight integration with the operating environment. The 70% forecast through 2028 is about enterprises abandoning agentic AI systems built by vendor FDE teams because costs rise and they can't develop the systems further, not a failure rate for every AI project. This comes from Gartner's release.
Should a startup build its own FDE team?
There is a case for it if the startup sells a complex product and needs to learn directly from customer environments to improve it.
According to Joe Schmidt at a16z, a startup can accept lower gross margin early on to invest in deployment and build an advantage that is hard to copy. But Gergely Orosz stresses that what sets FDE apart is the ability to contribute back to the platform, rather than just integrating and pushing up customer usage.
In my view, a startup should assess reusability after each contract. If every new customer needs a nearly independent custom project, the company risks operating more like a services shop than a product company. That is also the risk highlighted in Gartner's under-20% forecast.
Why do the AI labs keep pouring money into FDE?
Because a model's capability doesn't automatically become a system a company can use reliably. On May 11, 2026, OpenAI announced the OpenAI Deployment Company with more than $4 billion in investment and a deal to acquire Tomoro, adding about 150 FDEs and deployment specialists.
On October 2, 2026, Anthropic announced Claude Frontier Academy with $100 million in investment and a goal of training 10,000 Frontier Deployed Engineers by the end of 2027. These moves show the labs continuing to invest to close the deployment gap, while Gartner's warning focuses on the customer's ability to run the system alone and on how durable the contracts are.
The final test: when is hiring an FDE team worth it?
Hiring an FDE team is worth considering when the problem can't yet be fully written up as technical requirements, needs deep knowledge of the vendor's product, fast adaptation or tight integration with internal systems, and the contract has a clear exit plan. In that case you are buying more than software-writing effort: you are buying coordination between people who understand the platform and people who understand your internal processes.
If the requirements are already clear and the integration can be described and tested independently, compare against a deployment service or a traditional partner. Gartner recommends FDE only for problems that need deep product understanding, fast adaptation, or tight integration with the operating environment. Outside those cases, I think an ordinary deployment team is easier to predict on cost and results.
Stop rules before you sign:
- Don't hire an FDE team when the inputs and outputs of the problem are already clear and an ordinary deployment team could take it.
- Don't hire an FDE team when the problem needs neither deep knowledge of the vendor's product, nor fast adaptation, nor tight integration with internal systems.
- Don't hire an FDE team when you have no domain owner or engineer ready to take over the eval suite and keep operating the system.
Hire only when you accept the trade-off: budget and your internal team's time spent sitting with the FDE team, learning how the system works, and taking over responsibility for running it after the team leaves. If the vendor can't commit to that outcome, the contract is buying temporary deployment capacity, whatever the engineering team is called.
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 "FDE or rebranded consulting? How to tell before you hire an AI deployment team" on modernEngineer and apply it to this repo.
1. Call the content_get tool of the modernengineer MCP server with locale "en", slug "fde-hay-consulting-doi-ten". If MCP is not connected or access is refused, read the page https://modernengineer.dev/en/library/fde-hay-consulting-doi-ten 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
- fde-hay-consulting-doi-ten
