Who Changes It After They Leave?

Your AI vendor shipped on time.

The agent works. The demo was great.

Then the process changes, and nobody in your company can change the agent.

I ask one question before any vendor builds AI for a client: who changes it after they leave?

Running the system is the easy part. Changing it is where the cost hides. A new rule. A new system upstream. A new regulation. Every process you automate will move. The real question is who does the work when it moves, and what each change costs you.

The model is old. The name is new.

Vendors now sell “forward-deployed engineers”. Their engineers sit with your teams, build fast, and move on to the next client. The idea is old. Embedded vendor experts have been part of enterprise IT for years. What changed is the speed of AI, and how much of your business logic now sits inside systems your own people did not build.

Speed is the selling point, and often it is real. The risk starts the day the vendor team leaves.

What the analysts see

Gartner published a clear warning on this model. It predicts that 7 in 10 enterprises will abandon agentic AI built by vendor forward-deployed engineers within a few years. The reasons are simple. Costs climb, and the enterprise cannot evolve the system on its own.

Two more points from Gartner stayed with me. First, these engagements often fail in their structure before they fail in the technology. Second, the measure of success is the enterprise’s ability to run, improve and scale the system. The end of the implementation proves very little.

Gartner also warns about “FDE washing”: ordinary consulting sold under the new label, sometimes at premium rates. Fair warning. Labels are cheap.

Gartner’s guidance for AI leaders names another risk: talent atrophy. Your team becomes the operator of a black box instead of its architect. Forrester describes a similar trap. Highly tailored solutions deepen dependence on the vendor and make every future change expensive.

Follow the incentives

Gartner also expects fewer than 1 in 5 of these engagements to turn recurring customer needs into features of the vendor’s core product. So most of what gets built for you stays custom. Custom work that only the vendor understands is a renewal waiting to happen.

I do not blame vendors for this. Their model rewards return visits. Your contract should reward independence. That is the buyer’s job, and it is decided before signature, when you still hold the pen.

Go-live is the wrong finish line

I spent 25 years in enterprise IT operations and automation, at HP, IBM and DXC. I helped lead an automation estate of more than 3,000 bots. One lesson from those years is simple.

Go-live proves the system works. The first change after the builders leave proves who owns it.

A system that only its builders can change belongs to its builders. You pay for it. They hold it.

That is why I treat automation as a living asset. It needs a named owner, a change process, a known cost per change, and people inside the company who understand how it works. Without those, you bought a demo with a long contract.

Why agents make this harder

With classic automation, most of the logic sat in a workflow or a script. A good engineer could open it, read it and fix it.

With AI agents, the behaviour is spread out. Part of it sits in prompts. Part of it sits in the model version, the tools the agent can call, the data it reads, and the tests that decide if an answer is good enough. If those pieces live in the vendor’s heads and the vendor’s repositories, your team cannot change one of them safely. A small change can break something nobody is watching.

So the transfer is bigger than a handover document. It is the prompts, the tests, the data rules and the habit of changing the system without fear.

And the changes will come from places you do not control. Model providers retire old versions, so someone must retest every prompt and every tool call. An upstream application gets a new screen or a new API. A regulator asks for a new check. A business team wants a new rule by Friday. Each of these is small. Each of them needs a person inside your company who can open the system and change it without breaking it.

The Five Locks: three open at once

I use the Five Locks to check whether a company owns its AI: model, data, talent, cost and exit. A vendor build tests three of them at the same time.

Talent. Can your people change the system without the vendor in the room?

Cost. What does each change cost when only the vendor can make it? You find out at the first change request.

Exit. Can you end the contract and still run the system the next morning?

If one of these locks is open, the vendor holds the key.

Five questions before day one

Here is the checklist I would put in front of any buyer, before signature.

1. Who on my team owns this system after go-live? A named person. A team name is not an owner.
2. Who owns the code, the prompts, the data and the evaluation tests? Write it in the contract before work starts.
3. What is the exit date, and what must my team prove before it? Agree it on day one. Do not extend it because the team is not ready. Gartner gives the same advice.
4. Do my engineers build next to theirs every week? Watching a monthly demo transfers nothing.
5. Can my team ship one real change alone before the vendor leaves? Test it before exit day. A failed test means the transfer is not done.

Five yes answers, and you own it. One no, and you rent it.

Signs you are renting

You can check this today, on systems already live. Every change request goes back to the vendor, even small ones. Nobody on your side can explain why the agent gave a specific answer. Your team has no admin access to the repository or the evaluation tests. The cost of changes grows at each renewal. If two of these are true, you are renting the system.

How to write it into the contract

The five questions only work if the contract makes them real. Here is what I would ask for. Your people get access to the code, prompts and tests from day one. The last few changes before exit are led by your engineers, with the vendor watching. Part of the final payment depends on one change shipped by your team alone. And the exit date has a test attached, written before the work starts.

None of this is aggressive. A vendor who plans to deliver real ownership will sign it quickly. Have your lawyer check the wording for your country.

What a good vendor does

A good vendor plans its own exit from week one. It asks for the name of your owner early. It writes the runbook together with your people. It hands over the tests along with the code. It is happy when your team ships a change without calling.

If a vendor resists any of the five questions, that is your answer.

This applies to us too

I run a company that builds AI for clients. So this test applies to us first. If a client cannot change what we built, we did not finish the job.

Buy the speed if you need it. Many companies do. Just buy it with the exit written in.

Think about the last AI system a vendor built for you. If they left tomorrow, who would make the next change?