Key takeaways
- Deployment is becoming the real bottleneck in enterprise AI. Access to capable models is increasingly commoditised. The difficult work is connecting AI to proprietary data, existing workflows, security controls and measurable business outcomes.
- FDEs can trade short-term margin for a long-term moat. Working closely with customers can accelerate time to value, expose unmet product needs and embed the startup deeply within mission-critical workflows.
- The model only scales when fieldwork becomes product. If every engagement starts from zero, the startup is building a consultancy. If each deployment creates reusable software, tools and knowledge that make the next deployment faster, the FDE team becomes a product engine.
Between January and September 2025, job listings for forward deployed engineers increased by more than 800%, according to an analysis of Indeed data by the Financial Times. That is an extraordinary increase for a role that, until recently, was mostly associated with Palantir.
The reason is becoming clear. Companies have spent billions buying access to increasingly capable AI models, but many are still struggling to turn those models into working systems. A polished demo can be built in a weekend. Deploying AI inside a bank, pharmaceutical company or global manufacturer means dealing with proprietary data, legacy systems, security controls, regulatory requirements and employees who may have little incentive to change how they work.
Consider John Deere. OpenAI’s forward deployed engineers worked directly with the agricultural machinery company to customise AI-powered precision-farming tools. According to the Financial Times, the resulting system helped farmers reduce chemical spraying by 60% to 70%. The value did not come from access to a model alone; it came from applying that model to the machinery, data and operating realities of agriculture.
This is why the FDE is becoming one of the most sought-after roles in AI. For the past decade, the ideal SaaS company was designed to keep engineers away from customers: build the product once, sell it repeatedly, hand implementation to customer success and protect the gross margin. AI is turning parts of that model inside out.
Over the past few months, AWS, Microsoft, OpenAI and Anthropic have committed or attracted roughly $9 billion to organisations designed to help customers implement AI. The message for founders and VCs is hard to ignore: access to powerful models is becoming abundant, but implementation excellence remains scarce.
AI is easy to demo and hard to deploy
Anyone who has spent time with the latest AI coding tools knows how quickly a compelling prototype can be created. A good demo can be built in a weekend, using clean data and a carefully selected use case. A production deployment inside a bank, hospital or global manufacturer is a completely different proposition.
The production system has to contend with fragmented databases, undocumented business logic, access controls, legacy software, regulatory requirements and edge cases that were never written down. It also has to work for employees who may be sceptical about the technology or have little incentive to change how they work. In that environment, the model is only one part of the system and often not the most difficult part.
A widely cited MIT NANDA study found that the overwhelming majority of enterprise generative AI initiatives in its dataset had failed to create a measurable impact on profit and loss. The finding was widely reduced to “95% of AI pilots fail”, but the more useful conclusion was why they stalled. The problem was not simply that the models were insufficiently capable; it was that generic AI tools failed to learn from, integrate with and adapt to the workflows of a specific organisation.
This creates a two-sided knowledge gap. The customer’s team understands its business, including the data structures, approval processes, security constraints and exceptions that never made it into the documentation. The startup understands the technology: how the models behave, where hallucinations emerge, how retrieval pipelines fail and how to balance accuracy, latency and cost. Neither side possesses the other’s context, and a product manual or standard onboarding process rarely closes that gap.
This is where the FDE comes in.
What does a forward deployed engineer actually do?
The role is most closely associated with Palantir. The company describes a forward deployed software engineer as someone who embeds directly with customers to configure its platforms and solve difficult operational problems. While a traditional product engineer typically develops one capability for many customers, an FDE brings together multiple capabilities to solve the problems of one customer.
In practice, an FDE might map a company’s data, build an integration, design an agent workflow, establish an evaluation framework and work through security requirements. They may also sit with employees to understand how a process actually works, as opposed to how management thinks it works. The best FDEs can move from a meeting with the CIO to a code editor and then to a workshop with frontline users without losing credibility in any of those settings.
This makes the role difficult to define and even harder to hire for. FDEs sit somewhere between engineering, product, implementation and consulting, but they are not simply technical consultants with a more fashionable title. They are expected to build production systems and remain accountable for whether those systems deliver the intended result.
The title itself matters less than the function. Some startups call these employees applied AI engineers, deployment engineers, solutions architects or field engineers. What they have in common is proximity to the customer and ownership of the last mile between a capable product and a working deployment.
Why the FDE is having its moment
Forward deployed engineering is not new. What has changed is the ambition of the software.
Traditional SaaS generally asks the customer to adapt its processes to the product. AI products increasingly promise to adapt themselves to the customer’s data, language and workflows. This flexibility makes the initial demo more compelling, but it also creates significantly more implementation work.
AI agents increase the stakes further. A system that recommends an action can tolerate some uncertainty because a person remains responsible for the final decision. A system that takes the action: approving a refund, changing a production schedule, contacting a customer or modifying a contract, has to understand permissions, exceptions and consequences. As software moves from helping people perform work to performing parts of the work itself, implementation and product design start to merge.
This helps explain why model companies and cloud platforms are moving deeper into services. AWS says its FDE teams will work directly with customers’ business, engineering and security functions, leaving behind deployed systems, architectural documentation, runbooks and trained internal teams. OpenAI says its FDEs will work with executives, operators and frontline employees to choose high-value workflows and connect its models to the company’s data, controls and business processes. Anthropic describes small engineering teams working alongside customers to understand where Claude can have the greatest operational impact before building tailored systems.
Microsoft has gone a step further, arguing that its new Frontier Company extends beyond conventional FDE work by combining engineering with industry expertise, change management and continuous improvement. The implication is clear: enterprise AI deployment is not only a technical integration project. It is increasingly a form of business transformation.
The VC thesis: trading margin for moat
For VCs raised on SaaS metrics, an implementation-heavy go-to-market strategy naturally raises concerns. If every customer needs a team of expensive engineers, how does the company scale? What happens to gross margins? Is this really a software business, or a consultancy with AI branding?
These are the right questions, but treating all service work as a red flag can be too simplistic. As Andreessen Horowitz has argued, forward deployment can amount to trading short-term margin for a longer-term moat. The key question is not whether services are involved, but whether those services make the product more repeatable, reusable and defensible over time.
Done well, the FDE model can create several advantages. First, it compresses the distance between a signed contract and a working system. Many enterprise AI deals die in the gap between proof of concept and production because the customer lacks the internal resources, incentives or technical knowledge to complete the deployment. Putting the startup’s own engineers into that process gives the company more control over time to value.
Second, forward deployment can become a powerful product-discovery engine. An FDE sees problems that will rarely surface during a sales call: where the data is missing, which integrations are repeatedly required, where users stop trusting the output and which supposed edge cases appear in nearly every deployment. If that information reaches the product team, the startup is no longer guessing what to build. It is learning from real production environments.
Finally, the work can create defensibility. Models can be replaced, prompts can be copied and features can converge quickly. A system woven into proprietary data, internal permissions and mission-critical workflows is much harder to displace. The real moat is not the custom code itself, but the accumulated understanding of how the customer operates—and the ability to turn that understanding into a better product.
The danger: becoming a consultancy by accident
There is, of course, a less attractive version of this story. A large customer requests a custom workflow, and the startup agrees because the contract is too important to lose. Engineers spend several months building something that cannot be reused elsewhere. The customer is happy and asks for additional projects, so the startup hires more people to keep up.
Revenue grows, but headcount grows with it. The roadmap becomes a collection of commitments made to the largest customers, and each new deployment starts almost from scratch. The company may have built a respected consultancy, but it has not built a scalable software business.
High-touch implementation is not automatically a moat. Sometimes it is simply unpriced labour. The difference depends on whether the company can convert what it learns in the field into reusable software, tooling and deployment processes.
For founders, this means the FDE model needs operating discipline from the beginning.
The startup playbook for scaling FDEs
1. Deploy pods rather than looking for unicorns
It is tempting to write a job description for someone with deep AI expertise, strong product judgement, industry knowledge, commercial instinct and the ability to communicate with the C-suite. Unfortunately, that person is either extremely rare or already running a company.
A more realistic approach is to deploy a small pod. One person can own the customer relationship and overall outcome, while product engineers, data engineers and domain specialists rotate in as required. This reduces dependence on a small number of heroic individuals and makes the engagement easier to repeat.
2. Qualify customers for readiness, not interest
Interest in enterprise AI is abundant, but readiness is not. Before committing an expensive technical team, founders should confirm that the customer has a specific workflow tied to an economic outcome, an executive sponsor capable of removing blockers and internal technical owners who can work alongside the FDEs.
The startup should also understand whether the necessary data is accessible and whether there is a realistic path through security, legal and compliance. A customer that wants an “AI strategy” but cannot name the process owner or provide access to its data is probably not ready for forward deployment. An FDE cannot compensate for the absence of customer leadership.
3. Start with a business outcome, not an AI use case
“Deploy an AI agent” is not an outcome. Reducing customer-support handling time, increasing claims-processing capacity, improving collections or shortening a contract-review process are outcomes.
The difference matters because it focuses the engineering team and creates a basis for measuring success. It also changes the commercial conversation. A startup that can link its deployment to a meaningful economic result can justify a much larger contract than one selling model access or software seats.
4. Design every engagement to end
A successful FDE engagement should reduce the customer’s dependence on the FDE team. The project needs a defined scope, explicit milestones and a handover plan from the beginning. Customer engineers should gradually move from observers to co-builders and eventually to independent operators.
AWS has made this idea central to its model, stating that customer self-sufficiency is designed into its FDE engagements. That is an important test for startups as well. If an FDE becomes permanent human middleware between the customer and the product, the engagement may be producing revenue, but it is also revealing a product problem.
5. Turn fieldwork into product
This is the most important part of the playbook. Every engagement will generate customer-specific work, but the company must learn to distinguish between what is truly unique and what is a common pattern wearing a different uniform.
A connector requested by one customer may be relevant to dozens of others. A specialised evaluation process may reveal the need for a general testing product. A custom permissions layer may expose a platform capability that every regulated customer will eventually require.
The company needs a formal process for identifying these patterns and routing them into the core roadmap. A useful internal metric is not only how quickly the FDE team delivers customer outcomes, but how much of its work becomes reusable product, templates, tools or documented deployment knowledge. The desired loop is: deploy, learn, productise and repeat. If the loop stops at deployment, the company is selling labour.
What should investors ask?
The presence of an FDE team should not automatically be viewed as either a red flag or a competitive advantage. Investors need to understand how the model behaves as the company grows.
How long does a typical deployment take, and is that time declining? How much of the work is reused across customers? Which parts of the product originated in the field? Can the repeatable implementation work eventually be handled by the customer or by external partners? Most importantly, does the amount of engineering effort required per customer decline as the company moves from its first ten deployments to its next hundred?
The answers reveal whether the startup is using services to build software or using software to sell services. They also show whether early gross-margin pressure is financing the creation of a scalable product or merely disguising an expensive delivery model.
The talent market is responding
Demand for FDEs has risen sharply. According to reporting based on job-posting data, listings for forward deployed engineers increased by approximately 729% between April 2025 and April 2026. OpenAI, Anthropic, Palantir, Google Cloud, Stripe and leading consulting firms are all competing for variations of this talent.
Founders should be careful not to hire purely by title, however. The best early FDE may already be inside the company: the engineer who volunteers for customer calls, the solutions architect who continues prototyping after the demo or the product manager who can still write production code. In regulated or technically complex industries, a domain expert paired with a strong engineer may be more effective than a generalist with another year of machine-learning experience.
The aim is not to build an army of travelling developers. It is to create an organisation that can combine technical depth with customer context and then convert that context into product advantage.
The bottom line
Enterprise buyers are moving beyond the stage of being impressed by AI demos. They want systems that operate inside real workflows, meet security and compliance requirements and produce measurable results. That changes what it means to build an enterprise AI company.
The defining capability may not be training the best model or releasing the greatest number of features. It may be learning faster than competitors at the boundary between the technology and the customer, then turning that learning into a repeatable product.
For founders, forward deployed engineers can shorten the path from pilot to production, reveal what the product needs to become and create meaningful customer defensibility. For investors, the model requires looking beyond a single quarter’s gross margin to determine whether implementation is generating compounding software value.
The distinction is ultimately straightforward. When each deployment makes the next deployment faster and the product more capable, the FDE is a product engine. When every engagement starts again from zero, it is consulting. The companies that understand the difference will be the ones that turn today’s deployment bottleneck into tomorrow’s moat.
He is a former General Partner at Google Ventures (GV) in Europe, former head of Google for Entrepreneurs in Europe, and founding head of Campus London, Google's first startup hub. Eze writes on Israeli tech, venture capital, artificial intelligence, and founder strategy.
He is also the founder of Techbikers, a nonprofit that brings together the startup ecosystem on cycling challenges in support of Room to Read.
- The $9 Billion Bet on Forward Deployed Engineers - August 12, 2026
- Weekly Firgun Newsletter – August 7 2026 - August 7, 2026
- Israeli Defence Tech on the Rise - July 31, 2026
