How to re-certify an AI agent after its brief changes

Treat every brief change as a new candidate. The certificate is tied to a specific brief version, so a changed brief has no certificate until it earns one. Classify the change, find the capabilities it touches, add cases for any new behaviour, and replay the new version while the old one stays live. Switch only when every gate clears.

Why does a brief change need re-certification?

The agent brief is where behaviour lives: the role, the instructions, the sources, the connections and the bounds. Change any of these and you have a different agent, even if it carries the same name. A certificate earned by the old brief proves nothing about the new one.

Small changes are where this is most often missed. A sentence added to the instructions to handle a complaint, a new source document, a connector given one extra field. Each can shift behaviour on cases nobody was thinking about. The safe rule is simple: no brief version runs above depth 1 without a certificate earned by that version.

The capability owner owns re-certification. Whoever changed the brief proposes; the owner decides what must be re-proven and approves the switch.

What are the steps?

1. Person, author: records the change. What changed in the brief, why, and the new version identifier. The agent brief template keeps the parts separate, which makes this easier.
2. Person, owner: classifies the change. Role and scope, instructions, sources, connections, or bounds.
3. Person, owner: maps it to capabilities. Which certified capabilities use the changed part. A shared source can touch many.
4. Person, owner: extends the case set. If the change adds behaviour, add cases that exercise it, including cases where the new behaviour should not apply.
5. Platform: replays the new version. Against the existing set and the new cases, while the certified version keeps running live.
6. Platform: compares with the previous run. Gate by gate, case by case. Cases that passed before and fail now are regressions and get read first.
7. Person, owner: approves the switch. If every gate clears, the new version goes live at the lower of its evidenced depth and the role's ceiling.
8. Platform: retires the old certificate. It stays on file, tied to the old version, for the record.

What decisions does a named person keep?

Scope of the re-run. The owner decides which capabilities are re-run. The default should be generous: every capability that uses any changed part. Narrowing it needs a reason on file.

New cases. If the change adds behaviour that has no filed history yet, the owner approves constructed cases, following the approach in certifying an agent without real data. The certificate says which cases were constructed.

Floors for new scope. If the change widens what the agent does, existing floors may not fit. New floors are set before the run, not after seeing results.

The switch. Going live with a new version is the owner's decision, with their name on it.

What record does it produce?

Each certificate names the brief version it was earned on, the case set version, the floors and the scores. The change record links the old and new brief versions and states what changed. The comparison shows every regression and how it was resolved. Together they let anyone answer: what is running now, what proved it, and what changed since the last certificate.

That chain is also the answer to a supervisor who asks how you control change in an agent. It is the same discipline a bank applies to model changes, applied to the whole agent rather than the model alone.

What should you measure?

• Brief versions running live without a certificate. Should be none.
• Regressions per re-run. Shows how much risk each change carried.
• Time from change proposed to change live. If it is long, people will be tempted to skip the process.
• Changes classified as minor that produced regressions. Evidence for keeping the default scope wide.

Where does it usually go wrong?

Hotfixes. A complaint arrives, someone adds a line to the instructions, and it goes live that afternoon. If the platform ties certificates to versions, the hotfix runs at depth 1 until proven. That is inconvenient and correct.

Source updates treated as content, not change. A policy document is revised and uploaded. The brief's wording did not change, but its sources did. Source updates are brief changes.

Re-running only the new cases. The new behaviour passes; an old behaviour breaks. Always replay the existing set too.

Two changes at once. A new source and a new instruction go in together, a regression appears, and nobody can tell which caused it. Where you can, change one part at a time, or replay each change separately before combining them.

Floors adjusted to fit the result. If the new version scores lower and the floor is lowered to match, the certificate has lost its meaning.

The re-certification trigger checklist lists the changes that should start this process. For the first certification of a capability, see how do you certify an AI agent?, and for the framework, what it means to certify an agent.