How do you update an AI agent without breaking it?

Treat every change as a new version of the agent. Edit a copy, never the live brief. Rerun the full certification case set, not only the cases the change was meant to fix. Release to a small share of work, compare against the previous version, and keep that version one click away. Change one thing at a time.

Why do small changes break agents?

Because an agent's behaviour comes from the interaction of its brief, sources, connections, bounds and model. A sentence added to the brief to fix one complaint can change how the agent reads a dozen other cases. A source that gains a new field can shift what the agent treats as the most recent fact. Nothing in the change looks risky, and the failure shows up somewhere else.

This is why fixing the failed case and moving on is the most common way agents break. The case you fixed passes. The cases you did not look at are where the damage is.

What kinds of change are there, and what does each need?

Two rows deserve emphasis. Adding a capability, such as letting the agent update customer records in a CRM when it previously only read them, is not an update to an existing capability. It is a new one, and it starts at the bottom. And a model version change is never minor; whether it voids the certificate is covered in does a model update void an agent's certificate.

What are the steps, and who takes them?

1. Process owner: writes the change request: what changes, why, and which outcomes should be different. Evidence: a change note.
2. Platform owner: creates a new version of the bundle from the current certified version. Evidence: version numbers for old and new.
3. Agent, new version, test environment: runs the full case set. Evidence: gate scores for both versions side by side.
4. Process owner: approves or rejects on the comparison, looking for any gate that fell. Evidence: the decision, filed.
5. Platform owner: releases to a small share of live work, a tenth or less. Evidence: routing configuration and start time.
6. Team lead: watches edit rate, holds and escalations for the new version against the old over at least a week. Evidence: a short comparison.
7. Process owner: moves to full share or rolls back. Evidence: the decision and time.

What does a safe update look like?

Say a pension administrator's agent drafts replies to members asking about transfer values at depth 2. Members complain that replies are too formal, so the owner asks for a warmer tone.

The new brief adds three example replies in the desired tone. On the full rerun, tone improves and most gates hold, but refusal falls: in the examples, the warmer wording included reassurance about timescales, and the agent starts promising timescales in cases where a transfer is under review. The owner rejects the version. The examples are rewritten without timescales, the rerun clears every gate, and the new version goes to a tenth of replies for two weeks before full release. Without the full rerun, the first version would have reached every member.

Which controls keep updates safe?

• No edits to the live version. Every change creates a new version.
• The previous certified version kept ready for immediate return.
• Model version pinned and changes treated as recertification events.
• Full reruns, never partial ones.
• One change per release, so cause and effect stay clear.
• A change log linking each version to its test results and approver.

The full sequence is in our guide to deploying an AI agent.

Where Pryme fits

In Pryme, a change to an agent's brief, sources or model is checked by Attest against your own cases before it carries depth. A run that clears no depth drops the agent to depth 1 the same day, so a bad update limits itself. Because we never change model weights for a customer, every update is a change you can read, test and reverse.