Summary: Deloitte’s 2026 enterprise AI report puts only 25% of organizations at 40% or more of AI pilots moved into production. The Cohere article argues vendor FDEs should co-build with customer engineers, train internal champions, and leave reusable tests and practices. The intended measure is whether the engagement increases the customer’s ability to operate independently.
Where enterprise AI stalls is no longer the lab. It is the climb from experimentation to production. Deloitte’s 2026 State of AI in the Enterprise report put the figure at just 25% of organizations that have moved 40% or more of their AI pilots into production. Forward-deployed engineers (FDEs) from model vendors can work inside that gap—what matters is what they leave behind: capability, or dependency.
What separates vendor FDEs from third-party help
A vendor FDE works inside your technical environment while remaining tied to the team that builds the underlying models. Product knowledge runs deeper that way, and research and engineering stay within reach. One Cohere customer’s agent kept failing because its instructions pointed at tools that did not exist; the FDE rebuilt the agent and changed the Slack integration so it could handle larger contexts. Third-party providers seldom get that kind of view into root causes—building workarounds or escalating back to the vendor is usually all they can do.
What this buys you is not simply a faster escalation path. It is a wider set of options for making a deployment work without engineering around the product.
The lock-in worry is real, but not inevitable
Part of the dependency is baked into the technology choice: reach for a vendor’s models or APIs and architectural lock-in follows, no matter who does the deploying. The risk specific to FDEs is operational dependency. Let critical system knowledge stay with the vendor’s engineers and your team loses the ability to diagnose problems or modify the system safely—owning the deployment without the capability to operate it.
Capability-building as the default
Cohere’s approach builds knowledge transfer in from the start rather than bolting it on. FDEs walk through architecture, integration, deployment, testing, and troubleshooting alongside customer engineering teams. They run enablement sessions for major features and train internal champions. On technical ground such as Model Context Protocol, FDEs help developers settle into stronger implementation patterns.
Reusable practice is the other half of the work: deployment, load testing, connector development. FDEs also help customers stand up test suites that verify core functionality as model versions and configurations shift. Handing over what is known about today’s deployment is not the end state. The customer should come away able to operate, evaluate, and extend the AI system independently, for as long as it runs.
What this means for your build-vs-buy decision
When you weigh FDE support, put one question on the table: what kind of dependency will the engagement leave behind? The strongest ones turn deep product expertise toward shrinking your reliance on that same expertise over time. Close vendor involvement should leave you more operationally independent, not less.
That fits the wider move toward right-sizing AI for enterprise needs, where the point is to build internal capability rather than outsource your thinking. Teams picking structured data extraction tools face the same test: pick tools that strengthen your team’s ability to operate independently.