This is a story about distance and technology.
Somewhere right now, a company is six weeks into an AI deployment that looked excellent in the demo.
Imagine, your system is live, the vendor has been paid and the operations team has quietly figured out how to route around it because nobody was close enough to the operation during the build to know that this is not how work actually gets done here.
MIT’s NANDA initiative spent 2025 studying 150 executive interviews, 350 employee surveys, and 300 public AI deployments, and arrived at a number that should give every AI buyer pause: 95% of enterprise AI pilots stall before they ever change a number on profits. The core issue, according to MIT, is not the quality of the models but a flawed enterprise integration, the persistent gap between what AI can theoretically do and what it actually does inside a specific organization, with its specific history, its specific data, and its specific way of getting things done.
The Forward Deployed Engineer is the role that exists to close that gap. Understanding what it means is increasingly inseparable from understanding why so many AI projects fail in the first place.
Why AI could make this problem worse
Traditional enterprise software could, to a reasonable degree, be specified in advance. You mapped the requirements, built to them, caught the gaps during testing, and patched before launch. The failure modes were predictable enough that a disciplined process could anticipate most of them, and the software behaved the same way in your environment as it did in everyone else’s.
AI doesn’t work that way, an agentic AI system behaves differently for every customer because its outputs are shaped by that organization’s documents, its historical decisions, its exception logic, and the operating tone of its people. That cannot be configured with checkboxes. Someone has to look at the actual data, write the prompts and tools and guardrails against it, and iterate until the outputs reflect the organization’s reality rather than a clean theoretical version of it.
The gaps surface in production, after the model has been running long enough to encounter situations that nobody documented because nobody thought of them as edge cases. As they were just how things work around here the model trained on clean data runs into five years of inconsistent records.
So you ended building a recommendation engine that will suggest outputs that operators will not act on because the reasoning behind them is invisible to the people being asked to trust it. None of those are failures of the model but of the environment the model was built against.
No amount of pre-project discovery fully prevents this because organizations tend to describe their operations the way they wish they ran rather than the way they actually do, and the gap between those two things only becomes clear to someone who is embedded long enough to see it firsthand.
What the role actually involves
A Forward Deployed Engineer is not a consultant who shows up for the kickoff and reappears at the handoff. The entire point of the model is sustained proximity, staying connected to the real operation throughout the build, not just at the beginning and end of it.
In practice, the role spans pre-sales technical scoping, post-sales implementation, system integration, workflow configuration, evaluation and monitoring, and ongoing iteration. These overlap, recurse, and often run simultaneously inside environments with legacy infrastructure and regulatory constraints that were never fully documented by the organizations that built them.
In the early stages, that proximity means learning the operation before touching the system. Not running stakeholder interviews and synthesizing the output into a requirements document, but actually watching how people do their jobs: where they slow down, what they have quietly stopped relying on, which processes on the org chart bear no resemblance to the ones in practice. That kind of knowledge does not come from documentation, it accumulates through presence, and it cannot be rushed.
The build then happens in short cycles that stay connected to the real environment, not a staging server running clean test data, but the actual system, with the actual messiness, with the actual people who will eventually live inside it. Problems surface in days rather than after launch, which changes the economics of every fix that follows.
The dimension of the role that tends to be most underestimated is translation. Engineers and data scientists understand what a model can do. Operations teams understand what the business needs to do. Those two things are not automatically the same, and the distance between them is where a large share of AI projects quietly lose their way. A Forward Deployed Engineer works both sides of that gap and owns the outcome across both. OpenAI’s FDE team has documented what that ownership looks like at scale: 20 to 50% efficiency improvements across enterprise deployments in finance, manufacturing, and telecommunications. At Morgan Stanley, an AI assistant deployed through the FDE model reached a 98% adoption rate among wealth advisors and generated a threefold increase in research report usage, and again, the model itself was not different from what any competitor could access, the difference was in the deployment.
What happens when this model is absent
The failure pattern is familiar to anyone who has been through an enterprise software implementation. An external team builds in isolation, demos a clean version of the system, and hands it over and for a few weeks, sometimes longer, it appears to have worked. Then the edge cases start and the workarounds accumulate.
Your operations team finds ways to route around the system rather than through it because the system doesn’t quite fit the reality of their work, and nobody is available or incentivized to close that fit. Eventually someone concludes the implementation didn’t deliver what was promised, and they’re correct, but the actual failure happened much earlier, in the absence of anyone close enough to the operation during the build to prevent it.
MIT’s research found that companies using identical AI models see dramatically different results. The failure consistently happens during the transition from pilot to production, which is precisely the moment that proximity to the operation becomes most valuable and is most often missing.
Why this is the conversation the industry is having right now
Hiring interest in Forward Deployed Engineers grew 800% between January 2025 and mid-2026, according to the Financial Times. A16z called it the hottest job in tech. OpenAI grew its FDE practice from two engineers to 39 in a single year. Anthropic, Scale AI, Databricks, and Salesforce all formalized versions of the model for their own enterprise practices. In March 2026, Accenture launched a dedicated forward deployed engineering practice in partnership with Microsoft explicitly to help organizations move AI out of the pilot phase and into production environments where it changes how work actually gets done.
That convergence is not a coincidence and it is not a trend. It is the market responding to what the failure numbers had already made clear: the self-serve model of AI deployment, where the vendor ships the platform and the customer figures out the rest, does not work for complex production environments.
The question worth asking before you sign anything
When evaluating an AI implementation partner, the most useful question is not what they plan to build. It is how they plan to be inside your operation while they build it, specifically who will be present when your system encounters data it was not designed for, and what happens next.
A team working from a distance will produce something. A team embedded in your environment will build something calibrated to how the work actually gets done. Six months after launch, that difference is the whole story.
Oktana is a Salesforce Summit Consulting Partner and AI development firm. If you are thinking through what a real AI implementation looks like for your environment, we’d like to talk.
