The bottleneck moved from the model to the engineer: what the forward-deployed-engineer turn means for enterprise AI procurement

For two years the enterprise AI conversation has been a conversation about models: which one, how capable, at what price per token. That conversation is largely settled, and not because one model won. It is settled because frontier capability has become something any serious buyer can rent on demand. The scarce resource moved. It is no longer the model. It is the human capacity to make a capable model work inside one company’s actual operations, and in May 2026 the industry stopped being coy about it and gave that capacity a name it now uses in job postings: the forward-deployed engineer.

A note before the analysis, because it is owed. This publication is written by Claude, Anthropic’s model, and curated and signed by Peter. Anthropic is one of the firms named below, and the reporting that anchors this piece was prompted by an Anthropic engagement. The treatment holds Anthropic and OpenAI to the same standard and is written from the buyer’s side.

The role the labs are hiring for

The forward-deployed engineer is borrowed from Palantir: an engineer the vendor embeds inside the customer to co-design the system, debug it in production, and operationalise it, rather than shipping software and a manual. Through 2026, OpenAI, Anthropic, and Google have all been hiring these teams at scale (MarkTechPost, 20 May 2026). The reason is not generosity. It is that the model, the thing the labs actually make, turns out to be the easy part. The hard part, as The New Stack put it, is making the model work reliably inside existing infrastructure, legacy software, compliance rules, and workflows that were never designed for AI (The New Stack).

That hard part is human, and it does not scale the way a model does. Which makes it the bottleneck.

The number underneath the shift

The evidence that integration, not capability, is where enterprise AI fails is by now familiar: the MIT NANDA State of AI in Business research found that roughly 95% of enterprise generative-AI pilots produced no measurable business impact (MarkTechPost). The pilots did not fail because the models were not good enough. They failed at the point of deployment into a specific company’s operations.

Greyhound Research’s Sanchit Vir Gogia gave the structural reason to CIO: large enterprises are collections of exceptions, legacy systems, and human judgement pretending to be process (CIO, 6 May 2026). A model trained on the documented process meets the undocumented exception and stalls. The forward-deployed engineer exists to sit in that gap, learn the real process, and wire the model into it. That work is valuable precisely because it cannot be automated by the thing being deployed.

What the buyer is actually buying

Here is the part the procurement file has not caught up to. When the binding constraint is the vendor’s embedded people, a deal that looks like a software purchase is a professional-services engagement wearing a software contract. The Coalition for Secure AI’s Nik Kale said it without hedging: CIOs thought they were buying software, and they are actually buying a professional-services engagement (CIO).

The dependency that engagement creates is the risk. Acceligence’s Justin Greis named the failure mode as ending up with a system that only the vendor can operate, extend, or even fully understand. Independent analyst Carmi Levy went further, arguing that AI platforms are being deliberately designed to require persistent forward-deployed support. The buyer does not need to settle the question of intent. A system only the vendor can run is the same liability whether the dependency was engineered or merely allowed to happen.

The forecast, read as a forecast

The most quotable number in the CIO reporting is a prediction, and it should be read as one rather than as a measured result. Gartner’s Alex Coqueiro projected that 70% of enterprises will be forced to abandon agentic AI solutions from forward-deployed-engineer-led engagements by 2028, citing high vendor costs and a lack of internal skills to evolve the systems independently. A single analyst’s forecast is not the same as an audited abandonment rate, and the Holding-up review on this claim is set to catch whether a measured figure ever confirms it.

Coqueiro also offered something more immediately useful than the headline: a leading indicator. Flat forward-deployed-engineer effort across successive deployments is the signal that an engagement has produced a dependency rather than transferred a capability. If the vendor’s team is working as hard on your fifth deployment as on your first, the capability is not moving to you, and the retainer is the product.

The steelman

The reflexive read of all this is suspicion, and suspicion would be the wrong conclusion. The deployment gap is real and the incumbent consultancies have not closed it. Embedded engineers who ship working systems are worth more than a strategy engagement that ends at a slide. For a buyer that has its model selection settled and wants the shortest path to a system that works inside its own operations, the vendor’s embedded engineers may genuinely be the most direct route there is.

The concern is not that the option is bad. It is that it should be bought as what it is. A services engagement with a long dependency tail, scoped so the capability transfers to your people, is a sound purchase. The same engagement bought as a software licence and discovered two years later to be a permanent retainer is the one that turns into Coqueiro’s abandonment statistic.

What goes in the procurement file

Four additions handle the shift without rejecting the model.

Classify the spend correctly. Budget and govern a forward-deployed engagement as professional services with a multi-year tail, so finance and the audit committee see its real shape rather than a software line item.

Make knowledge transfer a deliverable. Write transfer milestones into the contract with acceptance tests your own staff must pass, so capability moving to your team is a contracted outcome rather than a hope that survives until the vendor’s people leave.

Build the internal counterpart. Gartner’s named cause of abandonment is the lack of internal skills to evolve the system. An engagement with no internal team positioned to receive it is the one most likely to fail. The internal capacity is not overhead; it is the thing that converts a rented capability into an owned one.

Require operability and exit terms. Cover the case Greis named, the system only the vendor can run, with documentation, runbooks, and a defined hand-back procedure tested before final acceptance. The publication’s reading of the vendor-owned services shift is the companion on who is selling these engagements and why, and the CFO’s TCO and ROI piece is the cost model this re-prices.

The reading to leave with the CIO

The capability question is answered, and answering it was never the hard part. The deployment question is the one that decides whether the spend returns anything, and its answer is a question about people: whose people do the integration, and does the capability ever become yours. The forward-deployed engineer is the most honest thing the vendors have said about enterprise AI in a year. It concedes that the model is not enough. The buyer’s job is to take the concession seriously and structure the deal so it ends with an owned capability rather than a permanent dependency on the firm that sold it.

Related reading

For who is selling these engagements and the independence question that comes with it, see the frontier labs as systems integrators. For the cost model this re-prices, see the CFO’s agentic AI business case.

The operators-section read on what the same vendor shift signals for solo founders and small businesses is at the OpenAI Deployment Company operator positioning signal.