The Flaw in Forward Deployment
Why technical capability isn't the constraint enterprise AI actually faces
An application of the Why Change Fails series at workthatholds.com
Enterprise AI deployments follow a pattern that has become predictable enough to examine as a system problem rather than a series of individual failures.
A vendor builds a proof of concept. The technology performs. The engagement is logged as a success. Three to six months later, the system has degraded, drifted or stopped being used. The customer calls with a complaint that sounds like a technology failure. It is usually not.
The technology worked. The organizational conditions required to sustain it were never established. Published data on this pattern is consistent: IDC research found 88% of AI proofs of concept fail to reach production deployment, and RAND Corporation’s 2024 study found AI projects fail at roughly double the rate of non-AI IT projects.[1][2] In both cases the failure point is reliably the organizational transition rather than the technology itself.
The major AI vendors have recognized that a gap exists between what agentic AI can do in a controlled demonstration and what enterprise organizations can absorb in production. Their institutional response, the Forward Deployed Engineer, is a reasonable answer to a real problem. The purpose of this piece is to examine what that answer gets right, what it misses and what a more complete model would require.
The Three Problems the FDE Model Addresses
The Forward Deployed Engineer (FDE) is not a new concept. Embedding technically skilled practitioners with customers to accelerate deployment has been a feature of enterprise technology sales for years. What is new is the scale at which the leading AI vendors are deploying the model and the convergence with which they are doing it.[3][4][5][6] When the major players move in the same direction at roughly the same time, the shared problem they are solving is worth examining.
Three problems drive the model. They are related but distinct, and the FDE addresses them unevenly.
Speed. The traditional enterprise deployment model requires agreement on scope, team assembly and a signed statement of work before any technical work begins. A competitor who can start building on day one has a significant advantage in a market where customers are still evaluating options. The FDE is, at its core, a competitive response to the sales cycle problem.
Skill. Most enterprises do not have the internal capability to stand up a production-grade GenAI deployment. They have teams who understand the vocabulary, have run pilots and experimented with consumer tools. Most do not have teams who can architect multi-agent systems, design evaluation frameworks, manage model behavior in production or build the feedback loops that keep outputs aligned to intent over time. The FDE imports that capability.
Value fit. Inside most enterprises, the people closest to AI tools gravitate toward problems that are technically interesting rather than problems that are strategically important. The result is a proliferation of pilots that address edge cases, internal tooling and experimental applications that will never justify the investment required to scale. The FDE, at best, helps redirect effort toward use cases that align to real business priorities and are worth building toward production.
The FDE model addresses the first two problems reliably. The third receives more uneven treatment. Identifying a use case that genuinely matters to the customer’s business requires a different kind of conversation than the one that moves a deployment forward, and it is structurally in tension with the speed problem the FDE also exists to solve.
All three share a common assumption: the job is done when the proof of concept works. None of them address what happens after the FDE leaves.
What the Job Descriptions Reveal
The published job postings from the major AI vendors offer a window into what each believes the FDE role is actually for. Read across vendors, the signal is consistent.
The shared profile: production experience with large language models, advanced prompt engineering, agent development and evaluation frameworks. The most sophisticated postings add language about scoping work, sequencing delivery and measuring success through production adoption and measurable workflow impact. That framing is closer to what actually determines whether a deployment produces durable value. But it is still a delivery capability. The FDE is expected to measure workflow impact, not to assess whether the organization has the conditions to sustain that impact.
The hiring criteria is the most direct evidence of the diagnosis. When the screening requirements center on code, LLM architecture and prompt engineering, the model has already decided what the problem is: a technical build gap. That diagnosis is partially correct, but for most enterprises struggling with AI adoption, the build constraint isn’t what’s holding them back.
Across all of them, the requirement to assess organizational readiness before building begins is absent. None ask whether the intended outcome is defined specifically enough to govern the system over time. None address who owns the result after the FDE departs. None require evaluation of whether the workflows being augmented have been redesigned to absorb a new capability, or whether the organization has the practices to maintain what it has been handed.
The FDE is hired to win the engagement. Getting to a working proof of concept and securing adoption is the job. Whether that proof of concept becomes a production system that holds is someone else’s problem. That boundary is not incidental. It reflects a theory of the problem that stops at the close.
Where AI Deployment Differs from Software Deployment
Before examining what the FDE model misses, it is worth acknowledging what it reflects accurately: the current deployment complexity is partly a function of where AI sits on the technology adoption curve.
New, disruptive technologies that do not fit cleanly into existing paradigms have always required more intensive engagement at the proof of concept stage. Early ERP deployments, the first wave of cloud migrations, the initial rollout of service-oriented architectures: all required embedded practitioners, extended scoping and significant organizational work before value could be demonstrated. As those technologies matured and deployment patterns became repeatable, the model shifted: RFI and RFP processes replaced custom engagements, implementation templates replaced bespoke builds, and in some cases the proof of concept was skipped entirely because the deployment risk had become well understood. The FDE model, in this reading, is a maturity response. It will evolve as AI deployment becomes more templated.
That reading is partially right.
The proof of concept model works well for traditional enterprise software because the deployment question and the value question are largely the same: does the technology work in this environment? If yes, adoption follows a predictable path. The product has documented behavior, known integration requirements and repeatable deployment patterns. Once it is working, it keeps working. Maturity reduces the cost of answering that question. It does not change the nature of the question.
GenAI presents a different question, one that does not get easier to answer as the technology matures.
A proof of concept demonstrates that the model can produce an output. It does not establish whether the organization can define what “good output” looks like consistently enough to govern it over time. It does not determine whether the workflows the output is meant to improve are ready to absorb a new capability. It does not assign ownership of the ongoing tuning, monitoring and correction the system requires. It does not create the feedback loop that catches drift before it compounds.
The maturity path is real for narrow AI tools that return a result and stay in place. Those do follow the pattern of earlier enterprise technologies. Deployment complexity decreases as patterns become repeatable and implementation becomes templated. Agentic AI follows a different path. A mature, widely deployed agentic system still requires someone to own the outcome, still requires the workflow to have been redesigned around the new capability, still requires active monitoring to catch drift. Those conditions do not become easier to ignore as the technology matures. In some respects they become harder, because the scale of agentic deployment grows while the organizational attention given to any single system shrinks.
The organizational conditions problem has been present in enterprise technology adoption for decades. It has largely been absorbed by the friction of slow deployment cycles, long implementation timelines and the tolerance organizations have had for mediocre technology outcomes. AI removes much of that friction. Deployment is faster, outputs are immediate and the gap between a working proof of concept and a drifting production system is measured in weeks rather than years. The organizational problem that could be ignored in previous technology cycles can no longer be deferred.
This is what the FDE model has not yet fully reckoned with. Some of what FDEs do today will be templated away as AI matures. The organizational readiness work will not.
What Successful FDE Engagements Have in Common
Not every FDE engagement follows the failure pattern. The engagements that produce durable value share a set of characteristics that are organizational rather than technical.
In the engagements that hold, someone established four things before any technical scoping began: the specific business outcome the deployment was meant to produce, the person accountable for that outcome after the FDE’s departure, the workflow changes required for the output to produce value and the mechanism by which the organization would detect drift from the original intent.
The FDEs who ask these questions are not doing so because their job description specifies it. They are asking because experience has taught them that a technically successful deployment landing in an organizationally unprepared environment will not hold. These are organizational design questions. The job description treats them as someone else’s problem.
The vendors winning sustained customer relationships beyond the proof of concept are the ones where the embedded practitioner has come to understand that standing up the system is not the end of the job. Making sure the organization can own what it has been handed is.
Four Prerequisites Before the First Line of Code
A model designed for the actual problem would treat organizational readiness as a prerequisite for technical scoping, not an afterthought following deployment. That prerequisite assessment centers on four questions.
What is the outcome? The business result the deployment is meant to produce, stated specifically enough that someone could evaluate, six months from the launch date, whether it was achieved. A use case is not an outcome. If the customer cannot answer this question before scoping begins, the proof of concept will demonstrate that the technology works and establish nothing else. The FDE should not build until there is a clear answer.
Who is accountable after the engagement ends? The person responsible for whether the deployment produces the stated outcome: not the project manager, not the executive sponsor, but the individual whose job it is to ensure the system continues working and producing value once the vendor has left. If no one holds that accountability at the start, the system will be maintained by whoever is available. That is how working systems become broken ones.
What changes in how work gets done? AI either augments existing workflows or replaces them. Either way, something about how people work must change for the output to produce value. If that change has not been designed before building begins, the new capability will be used around the edges of the existing process and produce marginal results regardless of how well it was built.
How will drift be detected? AI systems require active monitoring. The relevant questions: who is responsible for comparing what the system is producing against what was intended, at what frequency and with what authority to intervene when drift is detected. If no one owns this function before the FDE leaves, the system works at launch and fails quietly over time.
These questions do not require an organizational consultant to ask. A technically skilled practitioner can ask and help answer them. The prerequisite is treating them as conditions for starting, not issues to address if problems emerge later.
The Structural Problem the FDE Model Has Not Resolved
The FDE model exists because the gap between what AI can do in a controlled environment and what an enterprise organization can absorb in production is real and large. Embedding technically capable practitioners with customers is a legitimate response to that gap.
The gap the FDE model has not resolved is primarily organizational. The technology works. The proof of concept succeeds. What fails is the organizational side: definition of purpose, ownership structure, workflow redesign and monitoring discipline. These are the conditions that determine whether a working proof of concept becomes a production system that holds.
The structural reason is straightforward. The proof of concept is where the sale closes. Organizational readiness work, the work that actually determines whether the deployment holds, happens after the contract has been signed. There is no incentive to make it part of the FDE’s scope. There are real incentives to keep it out: it slows deployment, introduces friction into the customer relationship and surfaces organizational problems the customer may not want named.
The vendors who change this will not do so primarily because it serves their customers, though it does. They will do so because the failure pattern ultimately damages the relationship and the renewal. The vendors who treat customer success as the measure of done will build something that compounds over time. The ones who continue measuring success at proof of concept delivery will keep winning the deployment and losing the account.
The FDE role is the right instinct. What it defines as success is the wrong question.
Notes
[1] IDC Research in partnership with Lenovo. Lenovo CIO Playbook 2025. Finding: “88% of observed POCs don’t make the cut to widescale deployment. For every 33 AI POCs a company launched, only four graduated to production.” Cited in CIO Magazine, March 25, 2025.
[2] RAND Corporation. “Why AI Projects Fail” (RRA2680-1), 2024. Based on interviews with 65 data scientists and engineers. Finding: more than 80% of AI projects fail, roughly double the failure rate of non-AI IT projects. Note: broader scope than POC-to-production specifically.
[3] Palantir Technologies. “Beyond Founder Mode: Mission Mode.” Palantir Blog, November 12, 2025. https://blog.palantir.com/beyond-founder-mode-mission-mode-b81bfa5a8d82. Describes Forward Deployed Engineering as a novel approach generated from Palantir’s need to work inside complex mission-driven organizations.
[4] FDE Academy. “How Palantir Invented the Forward Deployed Engineer Model.” April 13, 2026. https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model
[5] Pragmatic Engineer. “What are Forward Deployed Engineers, and why are they so in demand?” November 3, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
[6] Netguru. “What Is a Forward Deployed Engineer? The Complete Guide.” June 4, 2026. https://www.netguru.com/blog/forward-deployed-engineer-role-guide