Why Your SI Contract Needs Change Control for Agentic AI Tools

Changes to the Agents Producing Your Deliverables Deserve the Same Attention as Changes to the People

More of what your SI delivers is now produced by its agentic tools, not just its people. Those tools will change during your program. You have a right to know when they do, and to understand what that change means for the risk you are accepting in what they produce. You may also learn when the SI’s cost to deliver has come down.

If you have spent any time in manufacturing, you have dealt with prior notification of change. A supplier can’t change a material, move a production line or switch a sub-supplier without telling the customer first. In automotive, medical devices and food, the customer often has to requalify the part before the change goes into production.

What is easy to miss is that most of those notifications are about the process, not the part. The customer approved a part made a specific way. Change the way it is made and the risk in the part changes, even if the drawing is identical.

SI delivery is starting to look a lot like a manufacturing process, and most clients have nothing like this in their contracts.

Why Do Changes to an SI’s Agentic Tools Affect Your Risk?

Take a simple example. Accenture, like every major SI, is building agentic tools to generate code and test it. None of those tools will run in your environment. But the code they generate will, and the testing they perform is what tells you that code is ready.

The same is true for configurations, data mappings, test scripts, documentation and, increasingly, design work. More and more of what the SI hands you is produced or checked by its agents, with people reviewing the result.

Now suppose the SI changes the model behind its code-generation agent, rewrites the prompts that govern it, or changes how its testing agent decides what to test. The deliverable may look the same. The way it was produced is different, and so is the risk that comes with it. A new model may introduce different kinds of defects or security weaknesses. A change to the testing agent may change what “tested” actually means. You accept the output based on assumptions about how it was made, and those assumptions just changed.

How Is Agent Change Control Similar to Key Personnel Clauses?

None of this is a new principle. Clients have negotiated key personnel clauses for decades. If the SI wants to replace the lead architect or the program manager, you expect to be told, and on key roles you expect to approve the replacement. Many clients also ask whether the team has the right training and certifications, because that tells them something about the quality of the work.

If agents are doing a growing share of the work, they are part of the delivery team. Replacing the model behind a code-generation agent is not that different from replacing your lead developer. The client should know when it happens and understand what it means for the work.

What Can SI Buyers Learn from Manufacturing’s Prior Notification of Change?

I would be less than candid if I said prior notification of change was only about quality. In manufacturing, large customers also used it to see inside their suppliers’ processes. If a supplier found a way to make the part for less, the customer wanted its share. And a customer that understood how the part was made walked into the next negotiation with a much better sense of the supplier’s margins.

The same dynamic applies here. When an SI’s code-generation or testing agents improve, its cost to deliver falls. Under a time-and-materials or fixed-fee structure, the client may never see that change unless it has a way to know about it. The SI deserves a return on the tools it has invested in. The question is how that return is shared, and for how long. Knowing when the tools that produce your deliverables change is one of the few ways a client can have that conversation with facts instead of assumptions.

Risk is the reason to ask. Insight into the economics is what comes with it.

How to Answer the SI’s “You Are Buying Outcomes, Not Methods” Objection

Expect the SI to say that how it delivers is its business, and that you are buying outcomes, not methods. There is some truth in that, particularly under fixed-fee or outcome-based pricing.

But the client is the one who lives with the output. The code, configurations and data mappings stay in production long after the warranty period ends. Acceptance criteria, testing and warranty terms were all written with assumptions about how the work would be produced. When the production method changes, the client’s risk changes, whether or not anyone told the client.

There is also the isolation point. The SI can’t maintain a separate version of its delivery tools for each client. A change to its code-generation or testing agents is a change for every client using them at once, including you.

Why Any SI Client Can Request Change Control for Agentic Delivery

A lot of buyers will read this and decide they don’t have the leverage to ask. In one sense they may be right. An SI is not going to design a change-control process just for a $20 million engagement.

But I’ll bet a dime to a dollar that its billion-dollar clients already have one. Large banks, insurers and life sciences companies have regulators who expect changes by third parties, and to models, to be controlled. Those clients have the leverage to require change control from their SIs and a regulatory reason to do it.

Because the SI can’t isolate its tools, it can’t isolate the process that governs them either. Whatever change control it built for its largest, most regulated clients covers the same agents that will be producing your deliverables. So the smaller buyer isn’t asking the SI to build anything. It is asking the SI to extend something that should already exist for another client, which costs the SI very little.

If the SI can’t point to a change-control process even for its largest clients, you have learned something important about how its agentic delivery is managed.

What Should an SI Change Control Clause Cover?

The obvious move is to write a detailed change-notification clause. I wouldn’t start there. The buyer can’t see inside the SI’s delivery tools well enough to decide which changes are material or how they should be tested. The SI can.

Manufacturing works the same way. Customers don’t write their suppliers’ change processes. They require suppliers to run change control that meets the customer’s requirements, and then they audit it.

Here, the buyer should define the risks it needs covered. It should know when the tools producing its deliverables change in a material way, whether that is the underlying model, the instructions, the testing approach or the level of human review. It should understand how a change affects the quality, security and test coverage of what it receives. Changes should be validated before they are used on the buyer’s work. And the buyer should have the right to adjust testing or acceptance when the way the work is produced changes.

The SI then shows how its process covers those risks. The buyer approves it, it goes into the contract, and it gets revisited as more of the work shifts from people to agents.

How to Evaluate an SI’s Change Control Process

How an SI responds tells you a lot about how its agentic delivery is actually managed. A strong answer will explain how its delivery tools are versioned, how changes are classified and validated, how human review works and when it changes. A weak answer will look like a release newsletter, or like a process someone wrote the week you asked.

The SI may say it can’t tell you which client prompted a change. That is a fair confidentiality position, but it isn’t a reason to refuse. You don’t need to know why. You need to know what changed and how it affects your work.

Both sides have legitimate interests here. A credible process shows the SI’s tools are managed with discipline and gives it a legitimate basis for pricing them. It gives both parties facts, not assumptions, when the conversation turns to who benefits from productivity gains. And it helps avoid the dispute that comes later, when both sides are arguing over what was delivered and what the contract allowed.

Ask for Change Control Before Signing or Before Scaling a Pilot

If you are about to sign, make this part of how you select the SI. If you are already in a pilot, make it a condition of scaling. Either way, ask before most of your deliverables are coming out of the SI’s agents, and don’t let the size of your program talk you out of it.

You would expect to be told if the SI replaced your lead developer. You should expect the same when it replaces the agent doing the developer’s work.

UpperEdge is an independent advisory firm. We don’t sell software, services or implementation work, so the only thing we optimize for is your outcome. Contact our team to build change governance into your agentic AI agreements before your SI’s agents are doing most of the work.