Enterprise Architecture
Vendor-built agents: who keeps control?
Gartner forecasts that 70% of enterprises will abandon, by 2028, the agents built for them by their vendor's engineers. The cause is not the technology: it is the absence of handover.
On 29 September 2026, Gartner published a forecast worth reading for its cause rather than its headline number: by 2028, 70% of enterprises will abandon agentic AI systems built for them by their vendor's forward-deployed engineering (FDE) teams, trapped by soaring costs and unable to evolve them on their own.
What we are talking about
The FDE model sends the vendor's engineers into the customer's organization to build, bespoke, what the product does not yet do. It works: it ships fast, it bypasses internal queues, it produces a convincing demonstration in a few weeks. That is precisely what makes it dangerous — initial speed masks the absence of handover.
The failure mechanism
There is nothing technologically surprising about it, and it repeats from one engagement to the next:
- The system exists only in the heads of the engineers who have left. No architecture documentation, no written decisions, no tests that explain the intent.
- Scope drifts. Every new need goes through a change order, because the internal team cannot intervene.
- Intellectual property was not settled up front, and becomes an issue when the company wants to take back control.
- Cost becomes recurring without becoming product. Gartner notes that, through 2028, fewer than 20% of FDE engagements will turn recurring customer needs into capabilities built into the vendor's core product. In other words, the company funds bespoke development it will still be paying for next year.
The recommendation from the Gartner analyst quoted in the release, Mukul Saha, points the same way: a successful FDE engagement is decided by the structure of the engagement — scope, incentives, governance, ownership, project co-ownership, knowledge transfer and an exit strategy defined from day one.
This is not an AI problem
It is the classic pattern of the integrator building a system nobody can take over, applied to a new technology. Three things make it worse in the case of agents. First, the dependency surface is wider: model, orchestration, tools, memory, guardrails. Second, behaviour is not deterministic: taking over an agent means understanding why it decides, not only what it executes. Third, running cost is variable and grows with usage, as we detailed regarding cost per task.
The six points to write down before signing
- Who owns what is produced — code, prompts, evaluation sets, training or fine-tuning data — and under what licence.
- The handover criterion, framed as a test and not an intention: someone from the internal team modifies a capability and puts it into production, alone, before the engagement ends.
- Architecture decisions written as you go, not an end-of-project document drafted in a week.
- The evaluation set that says whether the agent does its job properly. It is worth more than the code: it is what lets you change model or provider without rechecking everything by hand.
- The exit: what happens if you stop, which data is returned, in what format, and within what time. Reversibility is decided in the contract, not at the break-up.
- Measured value, with a business indicator defined before the start. An agent kept because it was expensive is not a success.
What I recommend in practice
Calling on the vendor's engineers is often the right choice: they know the product better than anyone and save months of wandering. What has to change is how they are employed. Have them work with an internal team rather than instead of it; bound the engagement to a capability delivered and handed over, not to an open scope; and accept a slightly slower start in exchange for real autonomy at six months.
It is the same logic that distinguishes an interim technical leadership from extra delivery capacity: the question is not who writes the code, but who remains able to evolve it (see Fractional CTO or full-time). And it is why, in agent projects, I recommend dealing with governance and architecture before the demonstration — the subject of the article on agents in production.
- Gartner forecasts 70% abandonment by 2028 for agents built by the vendor's engineers.
- The cause is the absence of handover: documentation, ownership, internal team autonomy.
- Fewer than 20% of FDE engagements will become capabilities of the standard product: bespoke stays bespoke.
- The success criterion is testable — an internal person ships a change to production, alone, before the engagement ends.
- The evaluation set is worth more than the code: it is what makes changing model possible.
Sources
Related reading
Does this challenge sound familiar?
A first conversation to assess it together, at no cost.