Nobody breaks an agent on purpose. It breaks during a routine update: a price change on a Friday, a policy refresh before a holiday, a new FAQ document added because a customer complained.
This is the process that prevents most of it, and it needs no tooling beyond a version history and some discipline.
Rule 1: one variable per change
The temptation is to batch. "While I'm in here, let me update the prices, the hours, and the refund policy."
When the agent then gives a wrong answer about refunds, you have three candidate causes and no way to isolate them. Worse, you have to choose between reverting a change you needed (prices) to test one you did not (refunds).
Update one thing. Ask the test questions. Then the next.
It feels slower. It is faster than debugging a compound change at 6pm on a Friday.
Rule 2: retire, do not duplicate
When a policy changes, the instinct is to add the new version. Now the corpus contains two versions of the truth, and the agent selects whichever matches the question better — which is not a decision you control.
Two documents that disagree do not average out. They produce inconsistent answers, and the inconsistency looks random to the person on the phone.
The rule: when a fact changes, the old document leaves. If you need an audit trail, that belongs in a version history, not in the live corpus.
Rule 3: know what rollback restores
Most platforms offer some form of version history. Before you rely on it, answer three questions:
- Does it restore the documents only, or the agent's behaviour too?
- Does restoring an old version discard changes made after it, or merge them?
- How long is history retained?
The failure mode is assuming you can "just roll back", discovering mid-incident that the restore only covers content and the agent's configuration was also changed.
Rule 4: separate content from configuration
Content changes: prices, hours, policies, service descriptions. Configuration changes: the agent's role, tone, escalation rules, routing, which knowledge is bound.
These fail differently. A content change usually produces wrong answers on specific topics. A configuration change can alter behaviour across every conversation — sometimes subtly, in ways nobody notices for a week.
Do not ship both on the same day. When something breaks, you want one variable.
Rule 5: the pre-publish checklist
Five questions, two minutes:
1. What exactly am I changing? One sentence. 2. Which questions does this affect? Name them. 3. What are the expected answers now? If you cannot say, you are not ready to test. 4. How do I get back? Name the version. 5. Who is on the hook to check it after? A name, not a team.
If any answer is "I'll figure it out", the change is not ready.
Rule 6: the after-check
Most regressions are found by customers, not by the team that made the change. That is avoidable.
After publishing, ask the affected questions yourself — not the whole set, just the ones you flagged in step 2 — plus one unrelated question as a control.
If the control question changed behaviour, your change had a wider blast radius than you thought.
Rule 7: write down what changed
Not for compliance. For the next person, including future you.
A change log with three columns is enough: date, what changed, who checked it. When a customer reports a wrong answer three weeks later, this is the difference between a five-minute fix and an afternoon of archaeology.
A word on "just retrain it"
There is a widespread belief that an agent can be "retrained" on new information, as if it were a colleague who reads the memo.
In practice, an agent answers from the material you gave it at the moment of the question. New information does not propagate by exposure — it propagates by being written into the corpus and bound to the agent. Everything else is a claim about magic.
That is not a limitation to be embarrassed about. It is what makes the system auditable: you can inspect exactly what it knows, and change it deliberately.
The failure this prevents
The most expensive agent failure is not a wrong answer. It is a confident wrong answer about money — a price, a fee, a cancellation term — delivered to a customer who then holds you to it.
That failure is almost never caused by a bad model. It is caused by an old document that nobody retired, in a corpus nobody versioned, changed by someone under time pressure with no way back.
All five of those conditions are process, and all five are yours to control.
Disclosure: I work on RingBot, an Agent-as-a-Service platform where knowledge is bound to an agent and versioned so a change can be rolled back. The process above is deliberately tooling-agnostic; it applies to any agent platform, and to the ones that will replace all of us.
Related: the three causes of wrong answers, proving a change did not regress, rollback when a flow change breaks calls, and the cost comparison.
Top comments (0)