Most advice about AI agents ends at launch. In practice, launch is when the changes begin. A customer asks something the agent could not answer, so someone adds a sentence to the instructions. A price list changes, so a document is replaced. The vendor offers a new model, or the team wants the agent to look up an order status. Each of these is small. Together, made without discipline, they are how a good agent slowly becomes an unpredictable one.
This article is for the owner or manager of a small or mid-sized company that already runs an agent and wants to change it without breaking what works. The regular review of results is covered in maintaining an AI agent after launch, and the first switch-on in staged rollout. Here we deal with the everyday question in between: how do we change a live agent safely?
Why small changes are risky
An agent's behaviour comes from several parts that interact: the instructions, the documents it reads, the tools it can use and the model underneath. Change one part and an unrelated answer may shift. A new rule saying "always offer a discount to unhappy customers" may also change how the agent answers a simple delivery question. A replaced document may contradict an older one that is still in the knowledge base.
Unlike ordinary software, the effect is not always visible from the change itself. You find out by trying it. That is why the discipline below is mostly about testing and about being able to go back.
1. Give every change an owner and a reason
Decide who may change what. A workable minimum for a small company:
- Requester: anyone who has a reason, usually the reviewer or the person handling cases.
- Change owner: the process owner you named at launch. They decide whether the change goes ahead.
- Second pair of eyes: for changes that touch money, legal wording or customer data, another person reads the change before it goes live.
Each request should fit into four lines: what we change, why (with one or two real cases), what we expect to improve, and what could get worse. If the requester cannot say what could get worse, the change has not been thought through yet.
Separate the types of change by risk. Fixing a typo in a document is not the same as giving the agent a new tool. A simple rule is that anything that lets the agent do something new, such as send, refund or update a record, needs the full process, while wording and document fixes can use a shorter one. The NIST AI Risk Management Framework asks organisations to manage AI systems throughout their life, not only at deployment (NIST AI RMF); a clear owner for changes is the smallest practical version of this.
2. Test on the same cases every time
Build a set of 30 to 50 real cases, as you did when you checked reliability before production. Include typical questions, awkward ones, cases that should be handed over to a person and cases the agent should refuse. Keep the expected outcome next to each case.
Before a change goes live:
- Run the set on the current version and record the results.
- Run it on the changed version.
- Compare case by case. Look at what got worse, not only at what got better.
The comparison with the current version matters. People remember the three cases they wanted to fix and forget the twenty that worked. If a change fixes three cases and breaks two, you need to see that before the customers do.
Add the case that triggered the change to the set. Over a few months the set grows into a record of everything the agent has learned to handle, which makes later changes safer.
Treat the three kinds of change a little differently:
- Instructions: run the whole set. A new sentence can change tone and decisions far from where you meant it.
- Knowledge: check that the agent finds and uses the new document, and that it no longer quotes the old one. Look for two documents that say different things.
- Tools: test the happy path and the failures: wrong order number, missing permission, a slow system. Check what the agent says to the customer when the tool fails. Keep permissions as narrow as possible and try the tool with test data first.
3. Switch on gradually
Even after a good test, real customers ask things you did not imagine. Limit the damage by limiting the exposure. The idea is the same as canary releases in software operations, where a change goes to a small share of traffic first and is compared with the rest (Google SRE Workbook).
For a small company this can be simple:
- Switch on for one channel, such as the website chat but not the email.
- Or for a share of cases, such as one in ten, or only for a part of the day when someone is watching.
- Or in shadow mode, where the changed version prepares answers that a person compares with the live ones, but customers do not see them.
Decide before the switch-on how long you watch and what stops it. For example: after three working days, if the share of cases handed over to a person grows by more than a few points, or if two reviewers independently mark a serious error, we go back. Pick thresholds that suit your volume; with ten cases a day you will need longer to learn anything.
Where the change can be separated from the rest of the setup, a simple on/off switch helps. Software teams call this a feature toggle (Martin Fowler). It lets you turn a new behaviour off without replacing everything else.
4. Be able to go back in minutes
A rollback plan is not a document; it is a tested ability. Before any change, answer:
- Is the previous version of the instructions, documents and tool settings saved and easy to restore?
- Who can restore it, and who is the second person if the first is away?
- How long does it take? If it is more than a few minutes, the change is riskier than it looks.
- What happens to cases handled by the changed version? Do any need a second look?
Keep versions with dates, not only the latest text. If your agent is built on a vendor platform, find out whether it keeps a history of instructions and knowledge and whether you can restore it yourself. If not, keep your own copy outside the platform.
Also agree who may decide to go back. During an incident, it should not require a meeting. Give the process owner and one deputy the right to roll back at once and inform the others afterwards.
5. Keep a short change log
A change log is a list, not a report. One line per change is enough:
- date and time,
- what was changed (instructions, document, tool, model),
- who requested it and who approved it,
- the test result and how it was switched on,
- how to go back.
The log pays off the first time quality drops and nobody knows why. Instead of guessing, you look at what changed in the last two weeks. It also helps in the weekly or monthly review, because you can connect a change in results with its cause. If your agent affects customers or employees in ways that fall under regulation, such as the EU AI Act, a record of changes is also useful evidence of how the system is managed; ask your legal adviser what applies to you.
6. Watch the days after a change
A change is not finished when it is switched on. For a few days afterwards:
- read a sample of conversations every day, not only the reported errors,
- watch the share of handed-over cases, repeated questions and customer complaints,
- ask the people on the team whether anything feels different.
Then close the change in the log: kept, adjusted or rolled back. A change nobody closes tends to stay in a half-tested state.
7. Plan the big changes differently
Replacing the model, switching vendor or giving the agent a major new responsibility is not a small change. Treat it like a new launch: run the whole test set, begin in shadow mode, tell the team and, where it matters, the customers. Vendors may also change a model behind the scenes. If your agreement allows that, ask for notice in advance and rerun your test set whenever the vendor announces an update.
A short checklist
- Name a change owner and a deputy, and write what needs a second reviewer.
- Describe each change in four lines: what, why, expected gain, possible harm.
- Keep a set of 30 to 50 real cases and compare the changed version with the current one.
- Test tools for failures, and check the old and new documents for contradictions.
- Switch on for one channel or a small share of cases, with stop criteria set in advance.
- Keep the previous version ready and make sure two people can restore it.
- Keep a one-line-per-change log and close each change after a few days.
- Rerun the test set when the vendor updates the model.
An agent that is changed with care keeps getting better. One that is changed in a hurry will work well on the day of the change and worse a month later, and you will have no record to explain why.
