Drift in Deployed AI Systems
The high projected failure figure is best read as a forecast of future repair workload, not as proof that FDE programs are a flawed method.
A Discouraging Number Worth Questioning
Gartner's 2026 outlook contains two numbers that seem to pull in opposite directions. The first is optimistic about adoption: most technology providers are expected to have built their AI delivery around forward deployed engineering, usually called FDE programs. The second is pessimistic: a large share of enterprises are expected to abandon agentic AI projects that came out of those same FDE-led engagements. Put side by side, the pessimistic figure invites a quick conclusion, namely that the approach itself is failing.
This article follows a mechanism rather than a verdict. It traces what happens to a system after it is built quickly, what changes around that system over time, and what kind of work an organization must do once the launch is over. By the end, you should be able to explain why the high failure figure is better read as a forecast of future repair work than as proof that FDE programs are a flawed method.
What FDE Programs Are
FDE programs are programs built around forward deployed engineering, a method for delivering AI in which engineers work inside the setting where the system will run. The source describes FDE as a core method for delivering AI and for compressing deployment timelines.
The speed is organized in a specific way. The source describes teams called pods that work on 45-day clocks, and many systems are built quickly under that schedule. The compression of timelines is the reason FDE programs exist. A system that might otherwise pass through a long sequence of separate stages is instead built inside one tight, repeated cycle.
The same tight clock that makes FDE programs fast also means a system is delivered before many of its long-term behaviors have been observed. Speed and follow-up needs come from the same design choice.
How a Working System Starts to Drift
Drift is the term for what happens when a system that worked at launch gradually stops behaving well. The source gives a specific cause: models change, and the upstream systems that feed or surround the deployed system shift underneath it. The deployed system may never have been edited. Its surroundings have moved, so its results no longer match what it was built to do.
The diagram below traces this progression. Read it from left to right and notice that nothing in the middle stages requires anyone to touch the system. The change happens around it, and the problem only becomes visible when its outputs stop matching its purpose.
Tracing One Deployed System Over Time
A launched system whose surroundings change
An FDE-built assistant performs well at launch. Nobody edits its code for a year. Why might its results still get worse, and what does that imply for the organization that owns it?
- 1Record the launch state
The system was built quickly, inside a tight schedule, and passed its launch checks. Its behavior at that moment is the baseline.
- 2Let the surroundings move
The models it depends on change, and the upstream systems that feed it are updated. The deployed system itself is never touched.
- 3Notice the mismatch
Its outputs no longer match what it was designed to do. The result is not a crash but a quiet decline, which is harder to spot.
- 4Count the work ahead
Someone must now diagnose the cause and repair the system. That repair is the remediation workload the launch quietly created.
The system did not fail at launch. Its decline came from change in its surroundings, so the organization inherits a maintenance obligation that the fast delivery did not eliminate.
The Remediation Loop
Once drift appears, the work does not finish with a single repair. The cycle has several stages: the system is monitored, drift is detected, the cause is diagnosed, the system is retrained or repaired, and then it is redeployed. After redeployment, monitoring resumes, because the surroundings can keep changing. That is why the loop keeps recurring after launch rather than ending once.
Reading the Failure Figure Two Ways
The misconception runs like this: many AI projects will fail, FDE-led projects are among them, and therefore the FDE model is an indictment of AI delivery that should be avoided. The reasoning links a visible outcome, abandoned projects, to the method that produced them, and then stops without asking what happens to the systems that were not abandoned.
The more careful reading treats the figure as a forecast. The source states that systems delivered quickly are handed over to drift, and that the remediation wave this produces has not yet started. The pessimistic number, read this way, describes work that is still ahead of organizations, not proof that the method cannot deliver.
Common mistake Treating an abandonment forecast as evidence about the delivery method alone
Why it failsThe figure reports what happens after handover as well as what happens during build, so it cannot be explained by the build method alone.
Do this insteadAsk what happens to the systems that were not abandoned, and what maintenance work they will need.
Common mistake Assuming a system that worked at launch will keep working
Why it failsModels change and upstream systems shift, so a system can decline without being edited.
Do this insteadPlan for monitoring and repair as a permanent part of the deployment.
Common mistake Assuming the remediation work is already happening, when the source says the wave has not yet started
Predicting the Seven-in-Ten Figure
What do you think happens?
Before reading on: what is the seven-in-ten figure most likely telling us about the work waiting for organizations after many fast, outsourced-style deployments are handed over?
Reveal answer
That a repair workload will arrive after handover
The source reads the figure as a forecast of future repair workload. Systems delivered quickly are handed over to drift, and the remediation wave has not yet started.
Why Internal Skills Decide Survival
The source ties the remediation problem directly to skills. It says that seven in ten enterprises will be forced to drop agentic AI projects that came from FDE-led engagements. The stated reasons are a lack of internal skills to sustain those projects and, in some cases, cost.
The skill that matters is specific. It is held by people inside the organization who understand why the first deployment decayed. Without that understanding, drift is hard to diagnose and harder to repair. An external FDE team may build the system, but ownership of the monitoring and repair loop has to move to internal staff for the system to keep working.
Practice: Tracing a Handover
An organization receives an FDE-built system after a 45-day build cycle. Six months later its outputs have quietly become less useful. Trace the path from launch to the current state, naming which change happened to the system itself and which happened around it. Then state who inside the organization needs to understand the cause for the system to be repaired.
Hints
- Ask whether the system's own code changed, or whether the models and upstream systems around it changed.
- Think about which stage of the remediation loop requires understanding why the first deployment decayed.
Key Takeaways
- The high projected failure figure is best read as a forecast of future repair workload, not as proof that FDE programs are a flawed method.
- FDE programs compress AI deployment timelines by building systems on tight clocks, such as the 45-day pod cycles described in the source, which means long-term behavior is often not yet observed at handover.
- Deployed systems drift when models change and upstream systems shift around them, even if the system itself is never edited, and this produces a remediation loop of monitoring, detection, diagnosis, repair, and redeployment.
- The remediation wave described in the source has not started yet, so the workload is still ahead of organizations.
- Whether an FDE-led deployment survives depends on internal people who understand why the first deployment decayed, since they are needed to diagnose and repair drift.