Forward Deployed Engineering and FDE Programs
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.
Two Numbers in One Forecast
Gartner's 2026 outlook for AI delivery contains two numbers that appear to point 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.
Placed side by side, the pessimistic figure invites a quick conclusion: the approach itself is failing. This section and the ones that follow examine why that conclusion is tempting, why it is mistaken, and what a more careful reading implies for the people who will live with these systems after launch.
What do you think happens?
What is the seven-in-ten figure most likely telling us?
Reveal answer
It is best read as a forecast of future repair workload, not as proof that FDE programs are a flawed method.
The source frames the high projected failure figure as a forecast of the repair work that follows fast deployments, rather than as an indictment of the delivery method itself.
Tracing a Launched System
To follow the argument, trace one deployed system through time. At launch, the system works as it was built to work. Its inputs, its surroundings, and its results all line up with what the team designed. The source describes what happens next: a system that worked at launch gradually stops behaving well. The system's own code and configuration may not have been touched at all. What changes is everything around it.
Read the diagram as a state change, not a code change. The before column shows the state the team delivered. The after column shows the same system whose surroundings have moved, so the same logic now yields results that drift from what it was built to do.
What an FDE Program Is
Forward deployed engineering (FDE) is the method of delivering AI in which engineers work close to where the system will be used, and FDE programs are the organized ways providers build their AI delivery around that method. The source describes FDE programs as a core method for delivering AI and for compressing deployment timelines.
The source reports that more than 85 percent of technology providers are expected to have launched FDE programs by the end of 2026. That scale is why the method deserves careful study rather than dismissal. Adoption is broad, so the way these programs are judged affects many organizations at once.
The speed of FDE work is organized through teams called pods. The source says pods work on 45-day clocks, and many systems are built quickly under that schedule. This is how an FDE program shortens the path from an idea to a deployed system: the work is paced in short, fixed cycles with a deadline that keeps the build moving.
Why the Misconception Feels Convincing
The misconception runs like this: many AI projects will fail, FDE-led projects are among them, therefore the FDE model is an indictment of AI delivery and should be avoided. The reasoning is simple, and that simplicity is its appeal. It links a visible outcome, abandoned projects, to the method that produced them.
The flaw is that the chain stops too early. It never asks what happens to the systems that were not abandoned. Those systems were delivered quickly, and they will still change after launch. The high failure figure is therefore better understood as a forecast of the repair workload that is still ahead.
Following the Drift Loop
Drift is the gradual change described above, and it does not happen once. After go-live, the source explains that models change and the upstream systems that feed or surround the deployed system shift underneath it. Each shift can move the system's results further from its design, which is why the work recurs rather than ending at a single fix.
The source states that this remediation wave has not started yet. The workload is still ahead, not already happening. That timing matters for planning: organizations that launched quickly have not yet felt the full cost of the repair cycles that their deployed systems will require.
Tracing one deployment through two drift cycles
A team delivers a system in a 45-day pod cycle. Following the source's sequence, what happens to the system after go-live, and what kind of work follows?
- 1Step 1: Go-live
The system works as built, because its inputs and surroundings match the design at launch.
- 2Step 2: First shift
A model changes or an upstream system shifts. The deployed system's code is unchanged, yet its results begin to drift from what it was built to do.
- 3Step 3: Repair
Someone goes back into the system to diagnose and repair the drift. The source notes that drift is hard to diagnose and harder to repair without people who understand why the first deployment decayed.
- 4Step 4: Next cycle
Further model or upstream changes arrive, and the cycle returns to drift. Each cycle adds another round of repair work.
The deployment does not end at launch. Each drift cycle creates another round of repair work, which is the remediation workload the high failure figure is forecasting.
Why Internal Skills Decide Sustainability
The source ties the remediation problem directly to skills. The forecast says 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.
Internal skills, in this context, means people inside the organization who understand why the first deployment decayed. The source treats this understanding as the factor that determines whether FDE-led projects are sustained or dropped.
The connection to drift is direct. Drift is hard to diagnose without knowing how the system was built and why it was expected to behave as it did. Repair is harder still. An organization that took over the system after handoff without this understanding has the remediation workload but not the means to carry it out, and that gap is where projects are dropped.
Mistakes When Reading the Failure Figure
Common mistake Treating the high failure figure as proof that FDE programs are a flawed method
What it looks likeConcluding that because seven in ten agentic projects from FDE engagements may be dropped, the approach should be avoided.
Why it failsThe source reads the figure as a forecast of future repair workload, not as evidence that the method is flawed.
Do this insteadRead the figure as a signal about what the organization must prepare to repair after launch.
Common mistake Stopping the reasoning at abandoned projects
What it looks likeFollowing the chain from abandoned projects to the FDE method and never asking what happens to the systems that were not abandoned.
Why it failsThe surviving systems were also built quickly and will drift as models and upstream systems change.
Do this insteadFollow the surviving systems forward through drift and repair.
Common mistake Assuming a launched system is finished
What it looks likeBelieving that once a pod's 45-day clock ends and the system goes live, its work is complete.
Why it failsA system built on a tight clock is delivered before many of its long-term behaviors have been observed.
Do this insteadPlan for follow-up work after handoff, including monitoring for drift.
Common mistake Assuming drift means the code was changed by someone
Practice Reasoning About Drift
A team reports that its deployed system produced correct results at launch but now gives results that no longer match its design. Nobody has edited the system's code since go-live. Using the source's account of drift, explain what most likely changed, and state what kind of work the organization should expect and what internal capability it needs to carry that work.
Hints
- Ask whether the change is inside the system or in its surroundings.
- Recall how the source describes models and upstream systems after go-live.
- Think about who in the organization would need to understand 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 deployment timelines through pods working on 45-day clocks, and that speed is why their output needs careful follow-up.
- Deployed systems drift after launch because models change and upstream systems shift around them, even when the system's own code is untouched.
- The remediation wave is still ahead, and whether FDE-led projects are sustained depends on internal people who understand why the first deployment decayed.