Build capability, not dependency

Running a system is the easy part. Changing it is where the cost hides. Every process you automate will move: a new rule, a new system upstream, a new regulation.

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.

With AI agents it is harder than with classic automation. Behaviour is spread across prompts, model versions, tools, data and the tests that decide if an answer is good enough. If those live in the vendor’s heads, your team cannot change them.

Before day one, and in the contract:

• Who on my team owns this system after go-live? A named person, not a team name.
• Who owns the code, the prompts, the data and the evaluation tests? Write it in the contract.
• What is the exit date, and what must my team prove before it?
• Are the last changes before exit led by my engineers, with the vendor watching?
• Does part of the final payment depend on one change shipped by my team alone?

Signs you are renting: every change goes back to the vendor, nobody on your side can explain an answer, and the cost of change grows at each renewal.

OG runs a company that builds AI for clients, so the test applies to IAC.AI first: “If a client cannot change what we built, we did not finish the job.”