AI Agents
AI agents for IT change management: prepare the change, not approve it
The change advisory board does not fail because it lacks judgment. It fails because it rubber-stamps changes nobody had time to assess. An AI agent can fix the preparation, risk scoring, and scheduling, and leave the go/no-go where it belongs. A practitioner walk through what to automate, what stays human, and why the CMDB decides whether any of it works.
A routine config push went out at 9pm on a Friday, approved by a board that never read the rollback plan. By 9:20 the payments service was down, and the postmortem found the change collided with a release nobody had checked the calendar against. The change advisory board had approved it in forty seconds, because it approves everything in forty seconds.
That gap is the real state of most change management. The board is not short on judgment. It runs short on prepared changes: requests that arrive with the blast radius known, the rollback tested, the freeze calendar checked, and the risk scored on something better than the implementer’s optimism.
The approval meeting became a formality because the preparation never happened, and a formality approves a Friday-night outage as readily as a safe change.
An agent earns its place in that gap, and it loses it in one specific spot. The agent should do the preparation and approve the clearly low-risk, pre-authorized changes. It should not be the thing that decides a high-risk go/no-go. In build terms: the agent makes every change arrive decision-ready, and a human still owns the decision that carries real downside.
The three jobs worth automating
Change management has a lot of motion and a little judgment. Automate the motion.
The first job is triage and enrichment. A change request lands as a paragraph of intent.
An agent turns it into a complete record: classify it as standard, normal, or emergency; identify the configuration items and services it touches; check whether an implementation plan, a test plan, and a rollback plan are attached rather than promised; and flag missing pieces back to the requester before anything moves. Most of the delay in change management is this, done by hand, days late.
The second job is collision and window checking. The agent reads the change calendar and the freeze windows and answers a question the board rarely has time to: does this change overlap another change on the same service, and does it fall inside a blackout the business declared for quarter-end.
A calendar collision is the cause of a surprising share of change-related incidents, and it is pure lookup, the kind of deterministic check an agent should never get wrong.
The third job is risk scoring, and it is the one worth building carefully. The score should not be a vibe from the model. It should be a deterministic function of facts: blast radius, whether the rollback was tested, the recent failure rate of the configuration items in scope, whether the change lands in business hours, and whether it is an emergency bypassing normal review.
public with sharing class ChangeRiskScorer {
public class Request {
@InvocableVariable(required=true) public Id changeRequestId;
}
public class Result {
@InvocableVariable public Decimal riskScore; // 0–100
@InvocableVariable public String band; // LOW / MEDIUM / HIGH
@InvocableVariable public String reasons;
}
@InvocableMethod(label='Score change risk'
description='Deterministic risk score the agent cannot argue with')
public static List<Result> score(List<Request> reqs) {
Set<Id> ids = new Set<Id>();
for (Request r : reqs) ids.add(r.changeRequestId);
List<Result> out = new List<Result>();
for (Change_Request__c c : [
SELECT Id, Blast_Radius__c, Rollback_Tested__c, Is_Emergency__c,
In_Business_Hours__c, CI_Recent_Failures__c
FROM Change_Request__c WHERE Id IN :ids
]) {
Decimal s = 0;
List<String> why = new List<String>();
s += (c.Blast_Radius__c == null ? 0 : c.Blast_Radius__c) * 4;
if (c.Rollback_Tested__c != true) { s += 25; why.add('rollback not tested'); }
if (c.Is_Emergency__c == true) { s += 20; why.add('emergency change'); }
if (c.In_Business_Hours__c == true){ s += 15; why.add('in business hours'); }
s += (c.CI_Recent_Failures__c == null ? 0 : c.CI_Recent_Failures__c) * 5;
Result res = new Result();
res.riskScore = Math.min(s, 100);
res.band = res.riskScore >= 60 ? 'HIGH' : res.riskScore >= 30 ? 'MEDIUM' : 'LOW';
res.reasons = String.join(why, '; ');
out.add(res);
}
return out;
}
}The point of putting the score in Apex rather than in the prompt is that the number has to be the same every time, and auditable. The agent calls this action, reads the band and the reasons, and uses them to route. It does not get to reason its way to a lower score because the requester sounded confident.
The decision between what the model reasons and what the platform decides deterministically is the whole game in a governed agent, and change risk is firmly on the deterministic side.
Where the human stays
Three decisions do not move to the agent, and saying so plainly is what keeps the build credible.
The go/no-go on a normal or emergency change stays with a person or the board. The agent assembles the evidence and makes the recommendation defensible; a human accepts the downside. On a change that can take down payments, that decision is not one to optimize away.
Standard changes are the exception that proves the rule. A standard change is one the organization has already decided is low-risk and repeatable, with a pre-authorized procedure. There the agent can approve and schedule on its own, because the human decision was made in advance when the change type was approved.
The skill is drawing that line correctly: too wide and you have automated away real review, too narrow and the agent is a clerk that still needs a meeting for a password-policy tweak.
And anything touching a regulated or safety-critical system stays human by policy, regardless of score. The agent can still prepare it. It cannot approve it. The same human-in-the-loop discipline every production agent needs applies to the one process where a wrong autonomous call is a Friday-night outage with a regulator’s name on the incident report.
The build on Salesforce, honestly
The pieces exist. A change request is a record, routing is an approval and orchestration problem Flow already solves, and the agent is a topic with a handful of actions: the risk scorer above, a calendar-collision check, a plan-completeness check, and a routing action that submits to the right approver or auto-approves a standard change.
Agentforce’s approval patterns cover the submit-and-wait half, and the agent sits in front of them doing the assembly.
Salesforce has also shipped a product aimed squarely here. Agentforce IT Service is an agent-first ITSM built on Service Cloud, and change management is part of the pitch. The employee-agent and request side is strong. Use it where it fits.
The honest caveat is the same one that post raised, and it is not a small one.
The CMDB decides everything
Change management runs on knowing what a change touches. The risk score above has a Blast_Radius__c and a CI_Recent_Failures__c field, and those are only as good as the configuration management database behind them.
If your CMDB does not know that this server hosts the payments service, and that the payments service has three downstream dependencies, the agent’s impact analysis is confident fiction.
The weak point sits here, and it is worth being direct about before anyone promises a change agent. Salesforce’s discovery and CMDB story is thinner than the ITSM incumbents’, so the configuration and dependency data the agent reasons over is exactly the data most orgs have not built.
An agent grounded on a stale CMDB does not fail loudly. It approves a change whose blast radius it got wrong, which is the failure mode you were trying to automate out of existence.
So the first project is not the agent. It is the data foundation the agent stands on: accurate configuration items, real service maps, change history tied to the CIs it touched. Get that right and the agent’s enrichment and scoring become trustworthy.
Skip it and you have built a faster way to rubber-stamp, which is the problem, not the fix. The reason so many agent projects fail is almost never the model and almost always the data underneath it, and change management is a pure example.
Guardrails that survive an audit
An agent that touches change approval will be audited, so build for that from the first sprint.
Log every agent decision as a record: what it scored, why, what it auto-approved, what it routed, and to whom. Auditors reviewing an agentic process expect an inventory of what the agent did and the change records to prove it, and a transcript is not a substitute for a structured, queryable trail. Make the agent’s reasons a field, not a paragraph in a log.
Keep the agent’s write scope narrow. It updates the change request, submits for approval, and schedules against the calendar. It does not execute the change. Separating the agent that prepares and routes from the automation that deploys keeps a bad decision from becoming a bad action, the same separation that keeps a fleet of agents from turning into shadow IT.
What good looks like
The board still meets. It just stops being a rubber stamp, because the changes arrive assessed, scheduled clear of collisions and freezes, with a rollback the agent confirmed exists and a risk score it cannot fudge. The board spends its forty seconds on the high-risk change that deserves forty minutes, and the standard changes clear without a meeting at all.
A good change agent looks like this. It does not approve the risky change and it does not replace the people who should. It deletes the preparation gap that made the approval meaningless, so when a human says go, they are saying it to a change somebody, or something, read.
Understanding the basics
Can an AI agent approve IT changes on its own?
Only for standard changes, the pre-authorized, low-risk, repeatable kind the organization already decided to approve by procedure. For normal and emergency changes, the agent prepares the request, scores the risk, checks the calendar, and routes it, but a human or the change advisory board makes the go/no-go. The autonomous approval is safe only where the human decision was made in advance.
What parts of change management should an agent automate first?
Triage and enrichment, collision and freeze-window checking, and risk scoring. Those are high-volume, mostly deterministic, and currently done by hand too late to matter. Classifying the change, confirming the implementation, test, and rollback plans are attached, finding calendar collisions, and producing an auditable risk score give the board prepared changes without touching the approval decision itself.
Why does the CMDB matter so much for a change agent?
Because impact analysis is only as good as the data it reads. If the configuration management database does not accurately map which systems host which services and how they depend on each other, the agent’s blast-radius and risk assessment is guesswork dressed as analysis. A change agent built on a stale or incomplete CMDB approves changes whose real impact it got wrong, so the data foundation has to come before the agent.
How do I keep an AI change agent auditable?
Log every decision as a structured record, not a free-text transcript: the risk score, the reasons, what was auto-approved, and where normal changes were routed. Keep the agent’s write scope to preparing and routing the change rather than executing it, so a wrong decision cannot become a wrong deployment. Auditors expect an inventory of the agent’s actions and change records that prove them.
Thinking about putting an agent in front of your change process, and not sure whether your configuration data can carry it? Talk to us. Getting the data foundation right before an agent reasons over it is exactly the work that decides whether this helps or just rubber-stamps faster.
