OpenAI, Anthropic, and Google are increasingly staffing “forward deployed” engineers inside customer organizations—an approach that challenges the industry’s “AI as a utility” promise. The push is less about luxury service and more about a gap: turning frontie
For the industry that sells “frontier AI” like a utility—turn it on like electricity—the most striking detail has started to look mundane and human: engineers showing up.
OpenAI recently announced the OpenAI Deployment Company. designed to embed “Forward Deployed Engineers” inside organizations tackling complex problems in demanding environments. OpenAI says these engineers will work with business leaders. operators. and frontline teams to find where AI can make the biggest impact. redesign workflows. and convert those gains into durable systems.
Anthropic is hiring Forward Deployed Engineers for its Applied AI team as well—people who “embed directly” with strategic customers to push enterprise adoption and ship real-world applications.
Google is doing the same.
If intelligence were truly a utility, the argument goes, companies wouldn’t need to send their own people into every workplace to make the system work.
The promise of frontier AI has long relied on a powerful metaphor: abundant intelligence. available on demand. as easy to access as electricity. water. or cloud computing. Utilities scale because they remove complexity from the user. The described reality—sending specialized staff into customer environments—creates a paradox at the center of enterprise AI.
Forward Deployed Engineers often aren’t there to chase novelty. They are there to take frontier models out of the clean demo world and make them function inside “messy. regulated. fragmented organizations.” That means grappling with permissions. legacy systems. compliance. data quality. workflows. and operational constraints—details that vary from one organization to the next and don’t show up in benchmarks.
And that’s precisely the uncomfortable message embedded in the hiring: the product, as packaged, is not yet enough.
The tension becomes clearer when the pattern is placed alongside earlier technology transitions. In other industries, there’s usually a phase where delivery is artisanal before it becomes industrial. Before enterprise software was packaged, implementation was bespoke. Before cloud platforms matured, companies needed specialists to configure infrastructure. Before the web settled into standards for browsers. hosting. content management. and design conventions. building a website took far more custom work.
Forward Deployed Engineering is presented as belonging to that same pre-platform stage. Palantir popularized a similar model years ago. and its Forward Deployed Software Engineer description is based on engineers working directly inside customer environments to make software operate in operational reality.
The difference now is that OpenAI and Anthropic are converging on the same delivery pattern. The implication is not that forward deployment has failed; it’s described as a transitional form—what appears before a category finds its true platform layer.
Mature enterprise software, the comparison suggests, scales differently. SAP does not scale by sending SAP employees into every customer; it relies on a partner ecosystem. Salesforce implements with the help of AppExchange—now evolving into AgentExchange—and a large ecosystem of partners. ISVs. and systems integrators. The idea is straightforward: the platform company creates the substrate, and the ecosystem industrializes delivery.
When the vendor itself must supply scarce human expertise to make the product work, the category is still immature. When partners and repeatable architectures can carry more of the load, scaling becomes possible.
There’s also a business-model trap in play. Once Forward Deployed Engineering becomes a source of revenue. prestige. customer lock-in. and strategic proximity. the vendor has incentives to keep it. The people doing the work—solving the product’s incompleteness—can become entangled with the business model that benefits from that incompleteness. In other words. even if a “real platform” would reduce the need for bespoke intervention. eliminating forward deployment can become harder for the very companies selling it.
The article argues the missing piece is not simply “a better model”—a larger. more agentic model with longer context. more tools. more memory. more reasoning traces. and more autonomy. The forward deployed work described—mapping workflows. understanding constraints. connecting systems. structuring context. governing access. and turning AI outputs into operational outcomes—points instead to a gap in architecture.
What’s repeatedly required in deployments is framed as a set of layers that convert 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 would have to become infrastructure.
That connects to the return of business process reengineering, too. In 1990. Michael Hammer’s Harvard Business Review article. “Reengineering work: don’t automate. obliterate. ” argued companies shouldn’t use technology only to speed up outdated processes; they should redesign the processes themselves. The case here is that AI raises the bar: insert AI into old workflows and you get faster versions of obsolete processes. Customize each deployment with engineers and you get artisanal transformation that can’t scale.
The breakthrough described is when redesign becomes systematized—when business processes are represented, governed, adapted, and optimized continuously. That is framed as the moment enterprise AI shifts from a consulting-style engagement into a platform.
Forward Deployed Engineers are treated as a clue that the bridge between general AI capability and specific organizational reality still requires humans to translate the company into the machine. Someone has to interpret constraints, determine which workflows matter, connect data, process, action, and outcome.
And history suggests what happens next. Web consultants didn’t disappear after the web matured. but “build me a website” stopped being mysterious custom engineering for most organizations. ERP consultants didn’t vanish after SAP matured. but ecosystem and standardization reduced the need for the vendor to deploy everywhere personally. Cloud architects didn’t disappear after AWS became a platform, but infrastructure became programmable, repeatable, and scalable.
The test of a platform is therefore practical: 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 engineers sitting inside the customer; can partners build on it; can customers configure it; can it scale beyond the handful of enterprises able to afford white-glove deployment?.
Until the answer is yes, the article pushes for honesty about what is being sold. It’s not “AI on tap” alone—it’s “AI on tap, with plumbers included.” For now, that may be fine. But the mistake would be confusing the artisanal phase with the destination.
The next stage of enterprise AI. as described here. won’t be defined by the most impressive model or the largest deployment team. It will be defined by who builds the layer that makes those teams less necessary—the layer that represents the company itself. encoding processes. constraints. permissions. memory. and outcomes in ways AI systems can actually use.
When that arrives, today’s forward-deployed boom is supposed to look obvious in retrospect: not as the final form of enterprise AI, but as the bridge between demos and platforms.
Because utilities don’t scale by sending engineers to every sink. They scale when the plumbing is already there.
OpenAI Deployment Company Forward Deployed Engineers Anthropic Applied AI Google enterprise AI enterprise AI adoption platform versus services AI architecture business process reengineering customer deployments