Why are big AI companies embedding engineers with customers, and what does that mean?

Why are big AI companies embedding engineers with customers, and what does that mean?

The promise of frontier AI has always sounded like a utility: abundant intelligence, available on demand, as easy to access as electricity, water, or cloud computing. The metaphor is powerful, and for good reason. Utilities scale because they abstract complexity away. You don’t need an engineer from the power company sitting in your office every time you turn on the lights. 

And yet, the most sophisticated AI companies in the world are increasingly doing something very different: They are sending people. 

OpenAI recently announced the OpenAI Deployment Company, explicitly designed to embed forward deployed engineers (FDE) inside organizations working on complex problems in demanding environments. These engineers, according to OpenAI, will work with business leaders, operators, and frontline teams to identify where AI can make the biggest impact, redesign workflows, and turn those gains into durable systems. Anthropic is hiring FDEs for its applied AI team, people who embed directly with strategic customers to drive enterprise adoption and ship real-world applications. And Google is doing the same. Is that a coincidence? 

That is revealing. Because if intelligence were already a true utility, this would not be necessary. You would not need to send your own engineers to every customer to make the faucet work. 

The paradox of AI as a utility 

This is the paradox at the heart of the current enterprise AI model: The industry speaks the language of scale, abundance, and platforms, but its delivery model increasingly resembles high-end consulting. 

That does not mean the work is unimportant. Quite the opposite. Forward deployed engineers are often solving the real problem: taking frontier models out of the demo environment and making them function inside messy, regulated, fragmented organizations. They deal with permissions, legacy systems, compliance, data quality, workflows, operational constraints, and all the things that make companies different from benchmarks. 

But that is precisely the point. The need for these people is not merely a commercial innovation. It is a symptom. It tells us that the product, as currently packaged, is not yet enough. 

In the previous articles in this series, I argued that large language models were never built to run a company, that enterprise AI must move from tools to systems, and that the systems that finally work will not look like chatbots or copilots, but like intelligence embedded into the organization itself. The FDE phenomenon confirms that argument from the vendor side. If the AI lab has to send engineers to reconstruct context, redesign workflows, and make the system operate under real constraints, then the missing layer is not imagined. It is sitting there, being supplied manually. 

The preplatform pattern 

Every major technology industry goes through an artisanal phase before it becomes industrial. 

Before enterprise software became packaged, implementation was bespoke. Before cloud platforms became mature, companies needed armies of specialists to configure infrastructure. Before the web stabilized around browsers, standards, hosting providers, content management systems, analytics, and design conventions, building a website required far more custom work than it later would. 

Forward deployed engineering belongs to that same historical pattern. Palantir popularized the model years ago. Its own description of the forward deployed software engineer role is based on engineers working directly inside customer environments to make software function in operational reality. 

That model made sense for Palantir because its customers often had extremely complex, high-stakes, highly specific environments. But when OpenAI and Anthropic begin to converge on similar patterns, the signal is different: the frontier AI industry is discovering that models alone do not cross the enterprise gap. 

That does not make FDEs a failure. It makes them a transitional form. They are what appears before a category has found its true platform layer. 

SAP does not send SAP employees to every customer 

This is where the comparison with mature enterprise software becomes useful. 

SAP does not scale by sending SAP employees into every customer. It has a vast partner ecosystem. Salesforce does not implement every customer itself. It has AppExchange, now evolving into AgentExchange, and a large ecosystem of partners, independent software vendors, and systems integrators. The platform company creates the substrate; the ecosystem industrializes delivery. 

That distinction matters. When the vendor itself has to supply the scarce human expertise required to make the product work, the category is still immature. When partners, integrators, templates, standards, and repeatable architectures take over, the category begins to scale. 

This is why the current FDE wave should be read carefully. It is not proof that frontier AI has become a platform. It is proof that it has not yet become one. 

A true platform reduces the need for bespoke intervention. A preplatform product depends on it. 

The business model trap 

There is another problem, and it is more subtle: Once forward deployed engineering becomes a source of revenue, prestige, customer lock-in, and strategic proximity, it becomes harder for the vendor to eliminate it. The very people solving the product’s incompleteness can become part of the business model that depends on that incompleteness. 

This is classic innovator’s dilemma territory. Clayton Christensen’s argument was that successful companies often struggle not because they fail to see the future, but because their existing business models make the future unattractive or cannibalistic. In this case, the dilemma is simple: If a frontier AI company builds the layer that makes deployments repeatable, modular, and partner-scalable, it may undermine the bespoke, high-touch model that currently brings it close to the largest customers. 

That is why the real platform may not come from inside the companies training the models. It may come from another layer. 

The missing layer is not another model 

The temptation, as always, is to assume that the answer is a better model. A larger model. A more agentic model. A model with longer context, more tools, more memory, more reasoning traces, and more autonomy. 

But the FDE model suggests something else. If engineers are being sent into customers to map workflows, understand constraints, connect systems, structure context, govern access, and turn AI outputs into operational outcomes, then the missing piece is not simply intelligence. It is architecture. 

More specifically, it is the layer that turns company reality into something AI systems can operate within: 

persistent context, 

process structure, 

permission models, 

constraint management, 

feedback loops, 

workflow state, 

business semantics, and 

outcome tracking. 

Today, that layer is often reconstructed manually by expert engineers on each deployment. Tomorrow, it will have to become infrastructure. 

That is the real opportunity. 

Why this is really BPR with agents 

This also connects directly to the return of business process reengineering (BPR). 

In 1990, Michael Hammer’s famous Harvard Business Review article, “Reengineering work: Don’t automate, obliterate,” argued that companies should not use technology merely to speed up outdated processes. They should redesign the processes themselves. The idea was right, but in many cases the technology of the time was not yet capable of supporting the ambition. 

AI changes that, but it also makes the problem more demanding. If companies merely insert AI into existing workflows, they get faster versions of obsolete processes. If vendors merely send engineers to customize each deployment, they get artisanal transformation that does not scale. 

The real breakthrough comes when the redesign itself becomes systematized: when business processes are not just automated, but represented, governed, adapted, and optimized continuously. 

That is the point at which enterprise AI stops being a consulting engagement and starts becoming a platform. 

The FDE is the clue 

This is why the forward deployed engineer is so interesting. The FDE is not the future of enterprise AI. The FDE is the clue that the future has not fully arrived. 

The role exists because current systems still require humans to bridge the gap between general AI capability and specific organizational reality. Someone has to translate the company into the machine. Someone has to interpret constraints. Someone has to determine which workflows matter. Someone has to connect data, process, action, and outcome. 

But history suggests that once a repeatable layer appears, the artisan becomes less central. Web consultants did not disappear after the web matured. But “build me a website” stopped being a mysterious custom engineering problem for most organizations. Enterprise resource planning (ERP) consultants did not disappear after SAP matured. But the ecosystem became standardized enough that the vendor did not need to personally deploy the product everywhere. Cloud architects did not disappear after Amazon Web Services (AWS) became a platform. But infrastructure became programmable, repeatable, and scalable. 

The same thing will happen here: Forward deployed engineers will not vanish. But if enterprise AI becomes a real platform category, they will become exceptional rather than foundational. 

The real test of a platform 

The test is simple: Can the system work without sending the lab? Can it understand the company without a bespoke mapping exercise every time? Can it operate under constraints without manual reconstruction? Can it adapt to workflows without a team of engineers sitting inside the customer? Can partners build on it? Can customers configure it? Can it scale beyond the handful of enterprises that can afford white-glove deployment? 

Until the answer is yes, we should be honest about what is being sold. It is not AI on tap. It is AI on tap, with plumbers included. 

And that is fine, for now. Every category has its artisanal phase. The mistake is confusing that phase with the destination. 

What comes next 

The next stage of enterprise AI will not be defined by who has the most impressive model or the largest deployment team. It will be defined by who builds the layer that makes those deployment teams less necessary. 

That layer will not merely answer questions. It will represent the company. It will encode processes, constraints, permissions, memory, and outcomes in ways that AI systems can actually use. It will allow models to operate inside the business rather than hover above it. It will turn bespoke deployment into repeatable architecture. 

When that happens, the current FDE boom will look obvious in retrospect—not as the final form of enterprise AI, but as the bridge between demos and platforms. 

And when the real platform layer appears, the industry will change very quickly. Because utilities do not scale by sending engineers to every sink. They scale when the plumbing is already there.