Changing an AI agent's model or prompt? How to regression-test it before release

Why does a small change break a working agent?

An AI agent's behaviour comes from several parts at once: the model, the instructions, the tools it may call and the data it reads. Change any one of them and the agent can behave differently on cases it used to handle well. Nothing in the change itself warns you which cases moved.

Some changes are yours, such as a reworded prompt or a new tool. Others arrive from outside: the model provider retires a version, the platform updates its defaults, or the ERP team renames a field. A release check has to cover both kinds.

Large firms watch agents more than they test them. In KPMG's survey of 314 US leaders at firms with $1 billion or more in revenue (24 July–25 August 2026), 70% used AI monitoring dashboards.¹ The share building controls into their agents alongside monitoring and evaluation fell to 30%, from 43% two quarters earlier.¹ Our view: a dashboard tells you about a bad change after customers meet it, and a regression test tells you before.

AI agents in large US firms, Q3 2026

Watching agents is common; testing them is not

62%building, deploying or developing AI agentsKPMG, Jul–Aug 2026

70%use AI monitoring dashboardsKPMG, Jul–Aug 2026

30%build controls into agents alongside monitoring and evaluationKPMG, Jul–Aug 2026

Model changes arrive on the vendor's schedule, not yours

The model under your agent changes when the provider decides, so the regression run has to be ready before the notice arrives.

OpenAI's ChatGPT release notes record GPT-6 Sol becoming the model for paid tiers from 7 October 2026, with GPT-6 Luna reaching Free and Go users from 8 October 2026.² A team whose agent follows the provider's default changed model that week, whether or not anyone noticed. A team that had pinned an exact version chose its own week.

More agents at scale means more places for a vendor's schedule to land. McKinsey's State of AI 2026 survey covered 1,719 participants in 97 countries between 4 May and 8 June 2026.³ In it, 40% of respondents at organisations with revenue above $1 billion were scaling AI agents in at least one function.³ At organisations with $1 billion or less, the share was 22%.³

Our view: open a change request the day a retirement notice arrives, with the regression run as its opening task. A team with a current set answers it in a week; a team without one spends the notice period building the set.

What counts as a change?

Anything that alters what the agent sees, decides or can do counts as a change. The table sets out the usual ones and what each should trigger.

Illustrative. Our classification of common agent changes.

Permission changes deserve extra care, because many firms have no written rule to test against. In Gartner's survey of 297 cybersecurity leaders in the second quarter of 2026 (geography not stated), 54% said their organisation had no defined approach to limiting AI agent access, or relied on predefined human access.⁴ Write the access rule first, as in our least-privilege checklist for ERP and CRM agents, then test the change against it.

Build the regression set from your own history

A regression set is a fixed list of real past cases, each with the outcome the agent should reach. Build it from your own records, not from invented examples, because real cases carry the odd formats and missing fields that break agents.

If the agent is not live yet, our pre-launch test method for a support agent covers building the launch set from tickets and marking it blind; this post assumes the agent is already running.

Take three kinds of case. Routine cases are the everyday work, in roughly the mix the agent sees. Hard cases come from the exception queue, where the agent or a person struggled; our guide to exception queues explains how to keep that record. Must-never cases test the actions the agent may not take alone, such as paying a supplier or changing a price.

Large firms already write that last list. In KPMG's Q3 survey, 49% had defined high-risk uses where agents may not make decisions on their own.¹ Each item on such a list should become at least one test case.

Write the expected outcome, not the expected wording

Record what should happen: the account coded, the order held, the case escalated to a named queue. Do not record exact sentences, because the wording of a model's reply varies even when the result is right.

Keep the set in your own repository beside the prompt, so it stays yours if the vendor changes. Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineering.⁵ It published the prediction on 29 September 2026 and described those enterprises as trapped by costs and unable to evolve the agents on their own.⁵ A test set you own is what lets a replacement vendor, or your own team, prove that a rebuilt agent matches the old one.

Start with a few dozen cases and add one every time a production error is found. After a few months, the set describes your business better than any generic benchmark.

How do you keep the regression set fresh?

Refresh the set from production transcripts every month, so it describes the agent's current work rather than the work it did at launch.

Three feeds keep it current. Every case the exception queue sends to a person becomes a candidate, because the agent found it hard. Every production error a customer or colleague reports becomes a case with the correct outcome written down. And a random sample of routine cases, drawn each month, keeps the mix close to real traffic as the business changes.

Retire cases as well as adding them. A case about a product line you no longer sell teaches nothing, and a set that only grows takes longer to run and to mark. Strip names, contact details and payment data before any transcript leaves the production system.

Our view: a set of 150 to 300 cases is enough for one agent with a single job, and the refresh matters more than the size. Mark each case with its date, its source and the version that passed it, so a later failure shows whether the case moved or the agent did.

Which production cases to add, and how many

Cost of a wrong action →

Must-never and hard casesKeep every one you find; none is retired while the rule stands.

Core transactionsEvery variant you see, refreshed each month from the queue.

OdditiesA handful for the odd formats; retire them when they go stale.

Routine workA monthly random sample in proportion to live traffic.

How often the case arrives →

How do you compare the old and new versions?

Run the same cases through both versions and compare them side by side. Run each case several times, because the same model can give different results on the same input, and score the worst run rather than the best.

Compare the same five things on every case: the outcome, the actions taken, the hand-overs, the refusals, and the cost and time per task. The next section sets out how to score each one, and the cost column is where a model that is cheaper per call but needs more calls shows up.

Set the release rule before you look at the results. A sensible default: any failure on a must-never case blocks the release, routine accuracy may not fall, and any change in cost needs an explanation. A model can help grade free-text replies, but check actions and amounts with plain rules.

A release check for an AI agent change

1. Freeze

   Record the current model, prompt, tools and rules as the baseline version.

2. Run both

   Put every test case through the old and new versions, several times each.

3. Compare

   Outcomes, actions, hand-overs, refusals and cost per task, case by case.

4. Decide

   Apply the release rule you wrote before the run; the business owner signs.

5. Release in stages

   Drafts first, then a small share of live work, then all of it.

Log the version with every action the agent takes, so that any later error traces to the version that made it. Our audit log field list includes the model and prompt version for this reason.

Score beyond pass or fail: actions, hand-overs, refusals and cost

Score each case on five dimensions, because a reply can read well and still take the wrong action or skip a hand-over.

Outcome correctness is whether the result matches the expected outcome you wrote down. Action correctness is whether the agent called the right tools with the right values and nothing more. Hand-over correctness is whether it escalated the cases that should reach a person and kept the ones that should not. Refusal and policy adherence is whether it declined what the rules forbid, including instructions hidden in content it reads. Cost and latency per task catch a version that is right but slow or expensive.

Illustrative. Our scoring sheet for a regression run.

Customers have set the bar for the hand-over column. In Gartner's survey of 3,566 B2B and B2C customers (February–March 2026; geography not stated), 87% said a route to a human agent is essential when companies use GenAI for service.⁶ A new model that answers more questions itself can quietly narrow that route.

Rerun the adversarial cases with every change as well. OWASP's register of risks for applications built on large language models places prompt injection at the top and describes the indirect form, where the instruction arrives inside a document or message the agent reads.⁷ A model change can reopen a hole an earlier prompt had closed. Our view: the pass mark for this group is no successful attack at all, on every run.

The release gate: draft mode, a canary share and a kill switch

Passing the set opens a staged release behind a switch, with the previous version pinned and one person able to restore it. Live work always contains cases the set does not.

Start the new version in draft mode, where it prepares work that a person checks and submits, while the old version keeps running. Move a small share of live work to it, then all of it once a week of results looks normal. Read the daily digest closely in that week; our guide to supervising background agents describes what the digest should show.

Our view: start the canary at one case in ten, hold it for a full week including a weekend, and widen to half before going to all. The kill switch is one setting that routes every case back to the pinned version, and the owner can flip it without asking.

Keep the previous version pinned and restorable in minutes. Where the provider lets you, name an exact model version rather than an alias that moves on its own. Note each provider's retirement dates in the agent's runbook, so a forced change becomes a planned one.

Write the rollback trigger before the canary starts: a must-never action attempted, routine accuracy below the baseline on any day, or cost per task above the agreed ceiling. A rollback is a planned step, so it needs no meeting.

A release week for an agent change

1. Day 1

   Freeze the baseline; run the full set on both versions, three times each.

2. Day 2

   Compare the five columns; apply the release rule; the owner signs or sends it back.

3. Days 3–5

   Draft mode: the new version prepares work, a person checks and submits.

4. Week 2

   Canary at one case in ten, the digest read every day, kill switch ready.

5. Week 3

   Half, then all of the work; the old version stays pinned for a month.

6. Monthly

   Scheduled rerun of the full set, even with no change planned.

The evidence pack finance and compliance will accept

Keep one record per release that shows what changed, what was tested, who approved it and what it cost.

The pack has six parts:

• The baseline and new version identifiers for the model, prompt, tools and rules.
• The regression set version and case count.
• The comparison results per dimension, with every failing case listed.
• The written release rule and the decision made against it.
• The owner's sign-off, with a date and the canary plan.
• Cost and latency per task before and after, from the same cases.

Store the pack with the audit log, so an action taken months later traces to the release that allowed it. For a customer-facing agent, compliance wants two more things: the disclosure that the customer is talking to AI still appears after the change, and the hand-over route still works.

Our view: a release that cannot produce this pack in ten minutes has not been controlled, however good the test results were.

Who signs off, and how often?

The agent's business owner signs each release, because they judge whether the work is right. The person who built the change runs the test and presents the comparison. In a small firm these can be two people and an hour.

Rerun the full set on a schedule even when you changed nothing, monthly at first. Providers and platforms change things, and a scheduled run catches drift before a customer does. Our view: put the monthly run in the owner's calendar rather than the builder's, because the owner explains a bad week.

The failure record shows the cost of skipping this. Gartner predicted in June 2025, more than a year before this post, that over 40% of agentic AI projects will be cancelled by the end of 2027.⁸ It named escalating costs, unclear business value and inadequate risk controls as the causes.⁸ A regression run is the cheapest control on that list.

Release discipline is part of what separates pilots from scaled use. Gartner surveyed 1,303 leaders at organisations with $50 million or more in revenue between January and April 2026 (geography not stated); 22% had scaled AI across multiple business units or adopted an AI-first approach.⁹ Our pilot-to-production checklist places the release check in a fuller operating model.

A disclosure: Sigzen AI builds agents for clients at published fixed prices and hands each one over with its test set and release rule, so weigh our view with that in mind. Our AI automation page describes how we scope that work.