Your IT Governance Was Built for Software That Doesn't Change. Agents Change Daily.

You already have IT governance, and it is good at what it was built for: deterministic software, change-controlled releases, the same input producing the same output. It has served you well for decades, and the instinct to extend it to cover agents is reasonable.

However, an agent is none of the things that governance assumes. It is probabilistic, it drifts with every model update, and it acts on live context that no release note captures. Retrofitting change-control designed for fixed code onto something that changes daily does not hold, and pretending otherwise is how a governed-looking project produces an ungovernable system.

The mistake is not that IT governance is weak. It is that you are asking it to answer a question it was never designed to ask. Change-control asks "what changed, who approved it, and when did we ship it?" That question has no answer when the change is a model update you did not ship and the behaviour moved on its own.

The unit of governance has to change

Deterministic governance governs releases. Agent governance has to govern decisions.

This sounds like a subtlety. It is the whole thing. In a release-centric world, once a build is tested and shipped, every execution of that build is assumed correct because the build is correct. The unit you sign off on is the release, and the release is stable.

An agent has no stable release to sign off on. Two runs of the same agent on the same document can differ, and the model behind it may be different next week. So the thing you govern cannot be the build. It has to be each decision the agent makes: what it decided, under what authority, on what inputs, and against which policy. Governance moves from a gate you pass once to a discipline that runs continuously, on every decision, for the life of the system.

That is not a policy PDF. It is engineered control with an owner and an audit trail.

Agents earn autonomy, they do not start with it

The core mechanism is graduated autonomy. An agent does not go live autonomous. It climbs a ladder, and evals, the tests that measure whether it clears a threshold, are the trust gate at each rung.

Read the ladder carefully, because two properties make it more than a maturity chart.

First, a rung is earned, not scheduled. The agent moves up only when it clears the eval threshold for the next level, and the threshold is set in advance, on the process's own baseline. This is the opposite of a launch plan you rush through to hit a date.

Second, a rung is lost automatically. If drift monitoring detects that performance has moved off the threshold, the agent is demoted without waiting for a human to notice. Autonomy is not a permission you grant once and forget. It is a state the system continuously has to justify.

As the agent proves itself, humans move from approvers to exception handlers. That is a real efficiency gain, and it is bounded by liability by design. The autonomy matrix and the kill-switch are documented, tested, and carry an immutable override log. The blast radius of a "Full" agent is not "whatever it decides to do." It is a bounded, written scope, with consequential calls still routed to a person.

Evals are the trust threshold, not a launch checkbox

The word "eval" gets used loosely, so it is worth being concrete about what it is doing here.

An eval is not a one-time acceptance test you run before go-live and then archive. It is the standing measurement that decides, continuously, whether the agent deserves the autonomy it currently holds. It is what converts "we think it is working" into "it cleared the threshold at 09:14 today, and here is the score that authorized this rung."

This matters because probabilistic systems degrade quietly. A model update improves one behaviour and regresses another. A shift in the input distribution, new document formats, a new fraud pattern, moves the agent off the cases it was validated on. Without a live eval and drift monitoring, none of that is visible until it reaches a customer or a regulator. With them, the demotion is automatic and the record shows exactly when and why.

Evals plus drift monitoring are what let you say the sentence a risk committee needs to hear: the agent's authority is not assumed, it is measured, and it is revoked the moment the measurement drops.

This sits alongside your IT governance, not on top of it

The goal is not to replace ITIL. It is to name responsibilities so cleanly that no one assumes the other layer is covering a gap.

Your IT governance keeps doing what it is excellent at: infrastructure, access, deterministic releases. The agent governance layer sits beside it and owns the things deterministic governance was never built to hold, drift, per-decision evidence, and the autonomy ladder. Two systems, clean seams, no assumed coverage.

The failure mode to avoid is the quiet one: a project that looks governed because it went through the normal change board, and is ungovernable in practice because the change board has no way to see a model update or measure drift. It passed the wrong gate.

So the question to bring to your next review is not "did this go through change-control?" It is for a system that changes daily, who owns the drift, where is the per-decision evidence, and can we demote an agent automatically the moment it moves off its threshold? If the honest answer is "our release process assumes it stays tested," you do not yet have agent governance. You have deterministic governance pointed at a probabilistic system, and the two do not fit.

If you want to see what earned autonomy looks like on one of your processes, book a meeting.