From Forward Deployed Engineers to Forward Deployed Software
Forward deployed engineers can earn the first use case. Forward deployed software is what turns the second, third, and tenth use case into repeatable ROI.
The market has discovered forward deployed engineers. That does not mean customers actually want them.
In the last two weeks, the three leading frontier labs have each reached for the same instrument. OpenAI launched the OpenAI Deployment Company with more than $4 billion in backing at a $10 billion valuation, anchored by TPG, Bain Capital, Brookfield, Goldman Sachs, McKinsey and Capgemini. Google Cloud CEO Thomas Kurian announced plans to hire hundreds of forward deployed engineers to form a new team inside Google Cloud. Anthropic partnered with Blackstone, Hellman & Friedman and Goldman Sachs on a $1.5 billion venture to embed engineers inside private equity portfolio companies and redesign workflows around Claude. The framing in each case is roughly the same: enterprise AI is hard, customers need help, send the engineers. This is a symptom of where we are in the adoption curve, not the answer to it. So what does the answer actually look like, and what are customers actually buying?
This rise of the forward deployed engineer tells us that the market has found a real problem: AI does not become valuable just because a model is available, a workflow has been demoed, or an integration exists in theory. The hard part begins when the system meets the customer’s actual operating environment, where the real process is not quite the documented process, handoffs are messy, ownership is unclear, approvals depend on context, and exceptions are often known by everyone but written down by no one.
In that environment, it makes sense that companies are sending engineers closer to the customer. Someone has to understand how the work actually happens before software can do anything useful with it. The mistake is to assume that because forward deployment is often necessary at the beginning, it is what the customer ultimately wants to buy.
The customer does not wake up wanting a forward deployed engineer. They do not want another technical team embedded in their business, another delivery model to manage, or another standing implementation function that quietly becomes part of the operating model. What they want is simpler and much harder: they want the work done, inside the environment where the work already happens, with enough reliability and control that they can trust the outcome.
The first use case is allowed to be messy
There is nothing wrong with using people to get the first use case right. In enterprise AI, it is often the only honest way to begin.
The first deployment is where the real workflow is discovered. It is where you learn which system is trusted, which process is mostly performative, which exception matters, where the risk sits, and what evidence the customer needs before they will let the software act with confidence. These things are not always available in a requirements document because the requirements document is often a partial fiction. It captures what the process is supposed to be, not necessarily how value, judgment, and accountability actually move through the organization.
That is the useful role of the FDE. They get close enough to the customer to expose the context that the product does not yet know how to capture for itself. They translate operational reality into something software can understand, and they find the gap between the demo and the deployment.
But that should be the point of the motion: to teach the software. If every new deployment requires the same amount of human discovery, bespoke configuration, and engineering effort to make the customer successful, then the company has not found a scalable AI model. It has found a consulting model with a better interface.
Consulting starts where product learning stops
The line between forward deployment and consulting is not the title on the team, it is whether the work compounds.
If an engineer sits with the customer, understands the workflow, builds around the exceptions, and leaves behind a system that makes the next use case faster, more reliable, and less dependent on human interpretation, that is product learning. If the same engineer, or another one just like them, has to come back and repeat the same exercise again and again, that is consulting.
This distinction matters because AI companies can easily hide a services business inside a software story. They can call it deployment velocity, customer obsession, outcome orientation, or any other phrase that makes the human effort feel strategic. Some of it is strategic. The danger is not being close to the customer; the danger is becoming permanently dependent on that closeness.
Customers will accept human help when it accelerates value, but they will not confuse it for the outcome. A long-running FDE engagement may feel reassuring at first because it means smart people are paying attention. Over time, though, it starts to look like exactly what customers were trying to avoid: another project, another dependency, another team whose knowledge lives partly in software and partly in people’s heads.
The promise of AI in the enterprise is not that customers get a more technical consulting team, it is that more of the work can move into software without losing the context, control, and judgment that made the human process work in the first place.
Forward deployed software
That is why the more interesting idea is forward deployed software.
Not software that waits for the customer to adapt to it, and not software that sits outside the workflow asking people to come to yet another place to get value. Forward deployed software enters the customer’s operating environment, learns how work is actually done, and gradually takes on more of the deployment burden that would otherwise sit with an FDE.
This does not mean pretending every workflow can be fully automated. That is usually where AI products become either brittle or irresponsible. In many enterprise processes, judgment still matters. Subject matter experts still matter. Review, escalation, auditability, and deterministic controls still matter. The point is not to remove humans from the loop everywhere; it is to stop using humans for work that software should be able to handle once the first deployment has taught it what matters.
Forward deployed software should learn the workflow, remember the exceptions, and understand where probabilistic reasoning is useful versus where deterministic logic is required. It should know when a task can be completed automatically, when it needs human review, and what evidence must be preserved so the customer can trust the result. In other words, software should start taking on the tasks that made forward deployment necessary in the first place.
That is what changes the economics for the customer. The first use case may require a heavier lift, but the second should be easier and the third should be faster. By the tenth, the customer should not feel like they are starting again. They should feel the return compounding.
The customer buys the outcome
Context graphs, integrations, and workflow memory all matter. But they are not what the customer is buying. They are the machinery behind the outcome. The customer buys the confidence that the work will happen correctly, consistently, and with less human effort over time.
That is the useful way to think about the infrastructure layer. It matters because enterprise AI cannot own real work if it does not understand the environment it is operating inside. It needs access to the systems, rules, exceptions, permissions, approvals, and prior decisions that shape how work actually gets done. But those things only matter if they make the outcome faster, safer, cheaper, or more repeatable.
No customer is buying a context graph because they want a graph. They are buying fewer stalled processes, faster approvals, cleaner handoffs, less operational drag, and more confidence that the same result can be delivered again without assembling another project team around it.
That is the customer-centric test for AI deployment. Did the work get done? Did it happen in the environment where the business already operates? Did it require less human effort over time? Did the next use case benefit from the last one?
If the answer is yes, then forward deployment has done its job. If the answer is no, then the FDE has become the product, and the customer is back in the world of consulting, even if everyone is using more modern language.
The real prize
The real prize is not more forward deployed engineers. It is software that can do more of what forward deployed engineers are currently being asked to do: understand the customer’s environment, translate messy workflows into executable systems, preserve the right controls, involve experts where judgment matters, and turn the first deployment into a faster path for the next one.
That is the difference between a services motion and a compounding software-based outcome. It is also the difference between a customer buying another project and a customer buying repeatable ROI.
Forward deployed engineers can be the bridge, but if you need them for too long, the bridge has become the destination. Customers do not want the bridge. They want to get to the other side.