How to roll back an AI agent after a bad change

Drop the affected capabilities to depth 1 first, then restore the last certified version of whatever changed: brief, sources, bounds, connector or model. Replay the restored version against its certification cases before depth returns. Then use the verdict records to find every action taken under the bad change and have a person review each one. Rollback needs every element versioned.

What counts as a change to an agent?

An agent's behaviour depends on several things that can change separately. Its brief, which says what it does and how. Its sources, which say what it knows. Its bounds, which say what it may do. Its connectors, which decide how it reaches your systems. And the model it runs on, which a provider may update. A change to any of these can change what the agent does, sometimes in ways that only show on certain cases.

A bad change is one that makes the agent worse at its job: a brief edit that makes it skip a check, a new source that contradicts an old one, a widened bound, a connector update that returns fields in a different order, a model update that changes its reasoning on edge cases. Rolling back means returning the changed element to its previous version.

The agent owner decides to roll back. The agent operations team performs it. The certification lead confirms the restored version before depth returns.

What are the steps?

1. Anyone: reports the signs. A reviewer, a monitoring alert, a customer complaint or the agent's own drift checks.
2. Agent owner: lowers affected capabilities to depth 1 at once. The agent keeps reading and can draft, but acts on nothing in those capabilities. This follows the rule that a failed run costs depth the same day.
3. Agent operations: identifies the change. The change record shows what moved and when. If several things changed together, treat them as one change and restore all of them.
4. Agent operations: restores the previous version of each changed element from version control.
5. Certification lead: replays the restored agent against the certification cases for the affected capabilities, plus the cases that revealed the problem.
6. Agent owner: restores depth up to the level the previous certificate supported, if the replay clears every gate and the certificate is still in date. Otherwise the agent stays at depth 1 until recertified.
7. Agent, depth 1: lists every action taken under the bad change, from its verdict records, between the change and the rollback.
8. Process owner: reviews each listed action and decides whether it needs correcting, reversing or telling a customer.
9. Agent operations: records the incident, the rollback and the review, and holds the bad change until it is fixed and recertified.

The question-and-answer version of this is in how do you roll back an AI agent?; this playbook is the operational sequence.

Which controls make rollback safe?

Everything is versioned. Brief, sources list, bounds, connector configuration and model version are each stored with a version and a date. Without this there is nothing to roll back to.

Changes go through a change record. Each change names what moved, who approved it and which capabilities it affects. Evidence: the change record.

Certificates are tied to versions. A certificate is evidence about one configuration of the agent. When the configuration changes, the certificate does not automatically cover it. Evidence: the version the certificate was issued against.

Model versions are pinned. If your model provider can update a model without notice, the agent can change without anyone approving it. Pin the version where you can, and treat any provider update as a change that needs recertification.

Depth can be lowered instantly, per capability. Evidence: the time the depth change took effect.

Work can always return to people. Rollback assumes people can carry the work while the agent is at depth 1. The case for keeping that possible is made in handing work back from an agent must always be possible, and the procedure is in taking work back from an AI agent.

What are the signs a change has gone wrong?

• Reviewer edits jump on a draft type after a change.
• Refusals by one bound change sharply, up or down. A sudden fall in refusals after a bound was widened is a warning, not good news.
• The held queue empties or floods.
• Drift checks fail on a certification gate, such as grounding or escalation.
• Complaints mention a new kind of error.
• Downstream teams report rework on the agent's output.

How do you stop it happening again?

Release changes gradually. A new brief or source can go to a small share of cases first, with the old version handling the rest, and widen as evidence builds; the method is in how to roll out an AI agent gradually. Replay every change against the certification set before release, not after. And keep changes small: a release that changes the brief, the sources and the model together is hard to diagnose and hard to roll back partly.

Where does it usually go wrong?

There is no previous version. The brief was edited in place. Version every element from the first deployment, as part of train, shadow, certify, widen.

Depth is restored before replay. The team is confident the old version worked and skips the check. But the world may have changed: sources were updated, a system field changed. Replay anyway.

Actions under the bad change are ignored. Rolling back fixes the future. Customers affected in between still need a person to review what happened to them.

Rollback becomes the fix. The bad change is shelved and forgotten. Whatever the change was meant to do still needs doing, properly.

Where Pryme fits

In Pryme, each capability's depth can be lowered at once, and the verdict records show every action taken between a change and its rollback. Certificates are issued against a specific configuration, so a changed agent is not covered until Attest has replayed it.