Treat anything that changes what an agent knows, uses or may do as a change. That means its brief, sources, tools, limits and model version. Each change is classified, replayed against the same past cases before and after, approved by the right people, released with a way back, and logged. Tightening a limit can move fast; widening one cannot.
What counts as a change, and who owns the process?
Conventional change control covers code and infrastructure. Agents change in more ways. A reworded instruction in the brief, a new folder added to its sources, a new connector, a raised depth, or the model provider releasing a new version can all change behaviour without a line of code changing. If those bypass change control, the agent you certified is not the agent that is running.
The process owner owns changes to their agent. The agent operations lead runs the change process. Risk approves significant changes. The platform team implements and can roll back. The general question of how limits are set and kept is answered in how do you control what an AI agent is allowed to do?
How should changes be classified?
- Tightening: lowering depth, removing a capability or source, narrowing a limit. Fast route; the owner approves, and testing confirms nothing else broke.
- Standard: wording changes to the brief or templates, new documents in an existing source, a minor model version. Replay tests and owner approval.
- Significant: a new capability, a higher depth, a new source system, a new tool or connector, a new model. Replay tests, owner and risk approval, and re-certification of the agent.
What are the steps?
- Person, requester: raises the change, describing what changes and why.
- Agent, depth 1: assesses impact, listing which capabilities read the changed brief section, source, tool or limit.
- Person, agent operations lead: classifies the change as tightening, standard or significant.
- Agent, depth 1: replays past cases for each affected capability on the current version and the changed version, and lists every case where the outcome differs.
- Person, process owner: reviews the differences. Each difference is either intended, acceptable or a reason to stop.
- Person, process owner, and for significant changes risk: approve. Significant changes need two people, a form of dual control.
- Person, platform engineer: releases the change with the previous version kept ready for rollback.
- Agent, depth 1: reports on the first days after release: holds, refusals and corrections by affected capability, compared with before.
- Agent, depth 3: records the change in the change log, linked to the test results and approvals.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Request | Nothing | none | Describing the change |
| Impact | Lists affected capabilities | 1 | Nothing |
| Classify | Nothing | none | Choosing the route |
| Replay | Runs old and new on the same cases | 1 | Choosing the cases |
| Review | Nothing | none | Judging each difference |
| Approve | Nothing | none | One or two named approvers |
| Release | Nothing | none | Deploying with rollback |
| Monitor | Reports behaviour after release | 1 | Deciding on rollback |
| Log | Writes the change log entry | 3 | Nothing |
Which decisions does a named person keep?
The classification, because routing a significant change as standard is the usual way control fails. The judgement on each difference in the replay. The approval. And the decision to roll back. The agent can assess, replay, report and log, but it should not approve changes to itself or to any agent it coordinates.
What record does it produce?
Each change leaves a log entry: request, classification, affected capabilities, replay results with differences, approvals, release time, rollback version and post-release report. The AI agent change log template has the columns. Because briefs, sources and limits are versioned, anyone can later see exactly which version applied when an action was taken.
Which controls matter most?
Pinned model versions. If the model provider can update the model under you, the agent changes without a request. Pin versions where you can, and treat a provider's change as a significant change.
Same cases, before and after. Replaying the same set on both versions shows what the change did. Testing only the new version tells you if it passes, not what moved.
Widening never takes the fast route. Under pressure, teams label new capabilities as fixes. Tie the route to what changed, not to how urgent it feels.
Rollback tested. A rollback that has never been tried is a hope.
What should you measure?
Changes by class, changes released without a log entry (the target is none), replay differences per change, rollbacks, and time from request to release for each class. If standard changes take weeks, people will find ways round the process, which is the tension discussed in how do you balance AI agent speed and control?
Where does it usually go wrong?
Brief edits are not seen as changes. Someone improves the instructions to fix one complaint, and behaviour shifts elsewhere.
Sources change silently. A shared folder used as a source gets new documents every week, and the agent's answers change with them. Version sources or route additions through review.
Emergency fixes skip testing. A quick change to stop a problem introduces another one. Allow fast tightening, but replay it as soon as possible after.
The certificate is not updated. A significant change goes live, but the certificate still describes the old agent. Re-certify the agent before widening takes effect.
Where Pryme fits
In Pryme, briefs, sources and bounds are versioned, and Attest replays the agent against your own cases so a change can be certified before it takes effect. Customers never change model weights; changes are made to the brief, sources, bounds and certification. See agent governance is a bound, not a model.
Questions people ask
Does every wording change need replay testing?
Any wording change in the brief can change behaviour, so yes, but the replay can be small for standard changes. Customer-facing template wording that the agent fills but does not interpret may need only a review.
Who approves a change to an agent that serves several teams?
Each process owner whose capabilities are affected. The impact assessment tells you who they are, which is why it comes before approval.
Should the change log be separate from the IT change system?
It can live in the same system, provided agent-specific fields exist: affected capabilities, replay results and certificate impact. What matters is that every change to an agent appears in one place.