70% of FDE agents abandoned
the handover gap

On a Friday afternoon, an operations lead at a manufacturer wanted to change one rule: any payout above 20,000 yuan needs two signatures. The rule had been written into the workflow the year the agent went live, and changing it should have taken half an hour. IT asked him to wait, because the vendor that built the thing had pulled out three months earlier, the code had no matching tests, and nobody could say whether the edit would bend some other judgment. He chose not to change it.

Nothing about that afternoon shows up in an annual report. It shows up as a process parameter frozen in one quarter and a spreadsheet the business keeps off to the side. The real change surfaces a year or two later: the agent still sits in the budget, and it no longer takes part in any decision.

Why that rule would not move

Model capability has little to do with it, and code quality has less. An agent behaves according to four things: the model, the prompts and tools, the permissions it can reach, and a standard for what counts as a correct judgment.

A vendor hands over the first three because they have a shape. Config sits in a repository, permissions sit in a table, the model has a name in the contract. The fourth usually stays behind, because it is not a file. It is what an embedded engineer accumulated over eight months inside one business: which edge cases deserve caution, which errors are cheap enough to tolerate, where the rule the client states differs from the rule the client actually runs. That judgment is scattered across every review they sat in, every explanation they gave, every threshold they adjusted on the spot.

The result is lopsided. You hold the system and not the ability to judge whether the system is right. The next business request leaves two paths: change it and be unable to prove nothing broke, or do not change it. Most organizations pick the second, because nobody sends a follow-up in two weeks about a change that never happened.

That is how abandonment actually happens. It is not a decision. It is a pile of postponed edits that eventually gets named. Gartner lists two causes, soaring cost and an inability to evolve; they are the same cause at two readings. In year one it looks like every change arriving with a new quote. In year two it looks like a budget line nobody touches.

How to read the seven in ten

On 29 September 2026, Gartner published a prediction: by 2028, 70 percent of enterprises will abandon agentic AI built by vendor forward-deployed engineering, trapped by rising costs and unable to evolve the system themselves. The same release carries a second number that explains the first: through 2028, fewer than 20 percent of FDE engagements will turn recurring customer needs into capabilities in the vendor core product.

The second number explains the first. Forward deployment was supposed to be a two-way street. The customer gets a working system, the vendor gets reusable capability. When fewer than one engagement in five completes the return trip, most projects are one-offs inside the vendor too, and the next similar request starts from a blank quote. The cost curve the customer sees is the structure working as designed.

Gartner has a name for the failure: FDE washing, meaning implementation services, solution engineering or AI consulting sold under a forward-deployed label at a premium, without the delivery depth to justify it. The analyst quoted in the release puts it plainly: some providers use the term thoughtfully, others because it sounds more strategic.

One caveat matters for anyone citing this. The material is a prediction from an analyst firm, not a statistical result, and neither 70 percent nor 20 percent should be repeated as something that already happened. What is usable is the three-phase structure, because that part is executable: scope and incentives before signing, embedding customer people during delivery, and executing an exit plan written on day one rather than extending because the internal team is not ready.

Three deliverables, one of them an asset

Split the deliverables apart and the difference is easy to see.

Code is readable, but reading code does not tell you why a judgment was correct. It records what was done, not why it was decided that way. An engineer who inherits it can only run it as it stands.

Prompts and tools are editable, and editing them is fast. The problem comes after the edit: nobody can show that some other judgment survived intact. One change to an agent touches dozens of scenarios at once, and a person can hold three or four in mind.

An eval set is the only thing that can still answer the breakage question once the vendor is gone. It is built from individual judgment records, each with at least four fields: the input at the time, the output the system produced, the version the human finally used, and the type of correction. With those four fields a change can be tested. Drop any one and the record is useless within six months, because you can no longer tell a changed business opinion from a system that broke.

The load-bearing word is individual. Test cases derived from a design document cover the failures you imagined. The ones that hurt are the ones you did not. An eval set has to grow inside the customer environment, fed by customer traffic and customer history. Otherwise it is a demo artifact.

One organizational question needs an answer early: who maintains it. Keep the set in a vendor repository and it leaves with the vendor. Hand it to an IT team with no business context and within six months nobody knows why a record used the version it did. What works is a named owner on the business side and a named maintainer on the engineering side, reviewing new samples together each quarter and writing new error types into the taxonomy. People are part of the asset, and that part does not fit in a contract.

Three clauses worth arguing over

If the argument holds, the center of gravity in an FDE contract moves toward three places. None of them is novel. The difficulty is getting them into an acceptance action instead of a signature page.

The first is that a milestone is accepted by a handover test, not a demo. Two people from the customer team, without calling the vendor, add a new rule to the eval set, run it, and explain why the result passed or failed. No test, no payment. The whole thing takes under an hour, and it is more reliable than any acceptance report because it measures whether capability moved rather than whether features shipped.

The second is that intellectual property has to name the judgment standard, not just the code. Who owns the eval set, the error taxonomy and the thresholds has to be settled at signing. A contract that only assigns code leaves the expensive part on the vendor server.

The third is that the exit plan is written the day you sign, not during the renewal conversation. This matches Gartner advice to execute the exit as planned instead of extending. The reason is practical: by renewal time the information is asymmetric, and the more anxious the customer, the worse the terms.

There is also an internal metric that never makes it into a contract and beats one. Every quarter, count the changes the customer team completed without vendor support. If that count falls, delivery is degrading even while the feature list stays on schedule.

When forward deployment is the wrong buy

The same logic does not cover every case, and saying so keeps it from turning into a pitch.

Skip it when the need is generic. Standard CRM integration, standard reporting migration, standard data cleanup: a traditional implementer is cheaper and more predictable, because they have done it many times. The premium in forward deployment buys fast adaptation to unfamiliar problems, and spending it on familiar ones is waste.

Skip the full handover ceremony for one-off tools whose errors roll back instantly. Internal knowledge search, meeting notes. Break it and rerun it. Building an eval set and a maintenance routine for that costs more than the risk.

The precondition most often skipped: somebody has to be able to take over. Without two people who understand both the business and the system, handover only postpones the problem by a quarter. The eval set gets built and then nobody reads it. In that state, hiring first works better than buying first.

Our judgment

Our judgment is that enterprises have been buying the wrong thing from forward-deployed engineering. They think they are buying an agent that works. The only part worth buying is the ability to change it. The agent expires as the business moves; the ability to change it does not. Acceptance should therefore be graded on modifiability, not on feature completion.

The claim is testable in under a day. First, list the judgments the agent currently makes in place of a person. The list rarely runs past twenty items: allow or block, classify or escalate, fill in or leave blank. Second, for each judgment type, pull twenty real inputs from historical records into a fixed set of under a hundred items. Third, name two people, have them run the set independently, record the pass rate, and forbid them from calling the vendor.

One of two things comes back. Either your team can carry it, and the agent is an asset, or nobody can explain why a particular judgment type is set the way it is, and that type is where the first incident lands after the vendor leaves. Learning that today is cheaper than learning it next March.

The question we would leave a buyer with: if your vendor pulled out next Monday, who on your team could tell you whether changing this rule breaks another judgment? If a name comes to mind, the handover happened. If not, it never started, and what remains is a feature list.

References

Gartner, Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028, 29 September 2026 (prediction, not survey data; three-phase framework, the under-20-percent product feedback figure, the definition of FDE washing)

Gartner, The Forward-Deployed Engineering Playbook (research note, client access required)