Imagine an environment where more than 90% of changes are standard changes, executed by AI agents. Routine work moves quickly, human intervention becomes less frequent, and teams spend far less time coordinating individual implementations.
The quality of the system that authorizes, executes, verifies, and learns from those changes becomes central to their work.
The percentage itself should remain a scenario, rather than a target. A high standard-change rate tells us little about whether services are improving, risk is controlled, or people are having a better experience.
Standard Does Not Mean Unconditional
A standard change is preauthorized within defined conditions. When agents execute those changes, the conditions need to be clear enough to guide action reliably.
Consider an agent authorized to expand storage capacity. That action may be routine when capacity thresholds, costs, dependencies, and service conditions fall within agreed limits. The same action could be inappropriate during an incident, when the underlying problem is uncontrolled data growth, or when several agents are responding to the same signal.
The important question becomes: Does this execution still qualify for preauthorization under current conditions?
Practitioners need to define prerequisites, permitted scope, validation steps, and stop conditions. They also need to recognize when a previously reliable change model no longer fits its environment.
Own the Models That Agents Execute
As execution becomes automated, the instructions governing execution deserve more attention. Note: This is one of the areas that ITSM Academy's ITIL (Version 5) AI Governance course covers.
Someone must own each change model: its purpose, eligibility criteria, dependencies, permissions, expected outcomes, and recovery arrangements. That ownership includes reviewing evidence, testing revisions, and retiring models that are no longer appropriate.
This creates an important shift in the work. A person who previously coordinated many individual changes may contribute more value by improving the model those changes follow.
A weakness in one manual implementation may affect one execution. A weakness in a widely used model can be repeated at machine speed.
Understand the Combined Effect
Individually low-risk changes can create significant risk together.
Two agents might modify connected services at the same time. Several changes might consume shared capacity. A series of small adjustments might gradually move a service outside its intended operating conditions.
Teams therefore need visibility into dependencies, concurrency, sequencing, and cumulative effects. They need to determine how much change a service can absorb and when execution should slow or pause.
Assessing a change in isolation becomes insufficient when agents act across an interconnected environment.
Configuration information and service relationships become practical inputs to decisions about what may happen next.
Verify the Service Outcome
An agent can successfully complete an action while the service still fails to meet its purpose.
A deployment may finish without errors, yet users may be unable to complete a transaction. Access may be provisioned correctly according to the instructions, yet the employee may still lack what they need to work.
Verification should connect technical execution to service outcomes. Did the expected improvement occur? Are dependent services functioning? Can the affected people achieve their goals?
This is where service level management, experience management, and value stream thinking become especially useful. They help teams look beyond the completion signal to the effect of the change.
Make Recovery Part of the Design
Recovery arrangements belong inside the change model!!!!
Depending on the action, that may involve rollback, a compensating action, a safe fallback, or escalation to a person with the authority and context to intervene.
Teams should test whether these arrangements restore the service. Reversing a technical action may leave other consequences unresolved, particularly when data, access, or downstream activities have already changed.
The ability to pause execution also matters. Teams need clear conditions for stopping one agent, one change model, or a broader set of activities - and clear ownership for restarting them.
Preserve Accountability and Useful Evidence
Autonomous execution still requires human accountability.
Teams should be able to establish which authorization applied, what conditions were evaluated, what action occurred, and whether the outcome was verified. They also need to know who owns the change model and the resulting service outcome.
Evidence should support investigation and improvement. A large volume of logs offers limited value if practitioners cannot reconstruct a decision or understand its effect.
The goal is a usable account of what happened, with appropriate protection for sensitive information.
Learn From Exceptions - and Apparent Successes
Failed changes, near misses, and repeated human interventions provide valuable improvement opportunities.
They may reveal outdated knowledge, weak dependency information, unsuitable thresholds, or a change model that needs redesign. Problem management can help teams address these underlying conditions rather than repeatedly correcting individual executions.
Successful changes deserve scrutiny too. If an agent repeatedly expands capacity, should the team investigate demand, architecture, or a persistent defect? If the same corrective action runs every day, has automation made a recurring problem easier to tolerate?
A reliable automated workaround can still leave an important problem unresolved.
Govern Changes to the Agents
Changes to prompts, models, tools, permissions, integrations, and knowledge sources can alter future behavior.
A small revision to an agent’s instructions may affect many subsequent executions. Teams need proportionate testing and authorization for those revisions, including representative scenarios, exceptions, and recovery behavior.
They should also consider whether a revision changes the basis on which an existing change model was preauthorized.
Where Practitioners Can Add More Value
As agents take on more execution, practitioners can devote greater attention to service design, resilience, knowledge quality, dependencies, experience, and continual improvement.
Their expertise helps determine which actions are suitable for autonomous execution, under which conditions, and with what evidence of success. It also helps organizations recognize when a technically successful action has failed to create value.
That work requires a deep understanding of services, stakeholders, and consequences.
If agents executed most changes in your organization tomorrow, where would your team’s judgment be needed most - and are you building that capability today?
Building that capability starts with learning so that you can prepare your team to shape the decisions, services, and outcomes that AI will influence.
ITSM Academy’s ITIL (Version 5) AI Governance course can help your team explore how to govern AI responsibly and connect its use to organizational goals.
Complement that focus with ITIL (Version 5) Service to strengthen service management capabilities, ITIL (Version 5) Experience to keep stakeholder experience central, and ITIL (Version 5) Transformation to support the organizational changes ahead.
Comments