Gartner predicts that 70% of enterprises will abandon agentic AI built by a vendor's embedded engineers by 2028, because they can't evolve it on their own and the costs keep climbing.
Most buying conversations are about which vendor. The better question is who inside your company owns the thing in month thirteen.
If nobody on your side can change it, you are renting it
Gartner is talking about a model it calls forward-deployed engineering, where a vendor's engineers work inside your company to build and deploy a solution with you. It can be the right call. Gartner's own advice is to use it only for problems that need deep product expertise, fast adaptation or close integration with your systems.
The trouble starts when nobody on your side is positioned to take over. Unless your side of the handover is written into the scope, the system gets built around the vendor's ability to run it, not yours. Gartner puts scope and incentives at the center of getting this structure right, and that is where the work belongs.
A result that stops when the builder leaves was never yours
I spent two years running an AI implementation firm, so I have sat on the vendor's side of this table. The test below is the one I would want a buyer to hold me to.
My test for any engagement is whether the people left behind can run it, change it and explain it to the board. The Asia digital business I ran is the example I know firsthand. I took it from $15M to $100M in annual run rate in eighteen months, against a three-year expectation, and hit my own forecast. Then I taught the company to run it without me. I still hold to that: a business that needs its builder in the room is not finished.
The same test applies to a vendor's AI build. If the system only works while their engineers are in the building, you have bought a service, whatever the contract calls it.
Put the exit in the contract on day one
Gartner's guidance comes down to four moves.
Name one executive who answers for the business outcome, not the technology. Without that person, nobody is in a position to say the vendor's work is done.
Write knowledge transfer into the contract as a deliverable with a date, next to IP rights and exit responsibilities. A handover that is only a hope tends not to happen.
Pair the vendor's engineers with your own people who know the work, so the learning stays after they leave.
Set the exit plan at the start, then follow it. If your team isn't ready at month twelve, the plan was weak, and a vendor extension doesn't fix that.
When renting is the right call
Some work you should never own. If you need a capability once, like a one-time data migration, renting is fine, and a clean handover document may be all you need. If the process isn't core to how you compete, an outside team running it indefinitely may be the right answer, provided you've priced that dependency honestly and you can leave.
The case to worry about is the core workflow you intend to improve for years, run by people who work for someone else.
Ask who on your payroll could change the system alone
Before the next vendor meeting, ask who on your payroll will be able to change this system without help in a year, and what they need to learn between now and then. If the answer is vague, the structure needs work before the build does.
I work with mid-market leaders on decisions like this one, and I'm glad to talk it through.
John Wyatt · John Wyatt's page · All posts · RSS