AI Vendor Evidence Gap Notes #15
An AI agent has completed acceptance testing. Its job is to update customer records, but every write operation requires human approval. The test report covers both approved and rejected requests, with execution traces showing whether the update was performed or blocked.
A few weeks later, the team upgrades the underlying model. The approval service and tool permissions remain unchanged, so the development team considers the previous acceptance report still valid.
That may be a reasonable position. Before relying on the report for the updated agent, though, I would want to see whether the model change affected any execution paths that the original tests were meant to cover.
Claim
“We only upgraded the model. The approval logic hasn’t changed, so we don’t need to repeat acceptance testing.”
There is some logic behind this. Software teams routinely use change impact analysis to decide which regression tests need to run. A minor component update should not automatically require the entire system to be tested again.
The difficulty with AI agents is that execution paths are not always fixed. Even when tool definitions and permissions remain unchanged, a different model may select tools differently, reorder steps, or handle failed calls in ways the previous version did not.
Why it sounds sufficient
Suppose approval is enforced by a separate backend service and every write request must pass through it. A model upgrade should not directly change that approval rule.
In that case, some of the earlier control evidence may remain applicable. The relevant question is whether the updated agent still operates within the same enforced boundary.
For example, the original agent might use one API to update a record, while the new version may choose an alternative tool after an API failure. If that alternative path was already available but never exercised during the original tests, the unchanged approval configuration tells us little about how the new execution behaves.
What it actually proves
The original acceptance report still has value. It establishes what happened under the previous model, configuration, and test conditions. If the recorded traces show that a rejected approval prevented a write operation, upgrading the model does not invalidate that historical observation.
The question is how much of that evidence still applies.
I would start with the differences between the two versions: model, system prompt, available tools, permissions, and relevant workflow configuration. Then I would compare those differences against the original acceptance scenarios.
In A Successful Demo Is Not an Acceptance Test, I discussed why acceptance evidence needs to cover the conditions that matter beyond the normal execution path. The same principle applies when deciding what needs to be tested again.
For the customer-record example, I would pay particular attention to approval rejection and API failure handling. A successful update through the normal path shows that the agent can still complete the task, but it says little about whether approval remains enforced during retries or alternate tool calls.
Where an independent backend control demonstrably covers every available write path, some existing evidence may remain sufficient. That conclusion should be supported by the relevant configuration and execution-path evidence rather than assumed from the absence of an intentional control change.
What it does not prove
Running a few successful workflows after the upgrade does not necessarily establish that regression testing covered the effects of the change.
Anthropic discusses this distinction in Demystifying Evals for AI Agents. Its discussion of regression evals focuses on whether agents continue to perform tasks they could previously handle. OpenAI’s Evaluate Agent Workflows also describes using execution traces and grading criteria to examine tool selection, handoffs, and workflow regressions.
These approaches are useful for organizing tests, but the resulting evidence still needs to correspond to the system being reviewed.
An updated agent might complete more tasks successfully while introducing a control problem in a less common execution path. Comparing overall success rates would not necessarily reveal that.
The execution record matters here. As discussed in AI Audit Logs: What Events Are Missing?, logging capability alone does not establish that the events needed to reconstruct a workflow are available. For regression testing, reviewers need enough detail to understand whether the expected approval, tool, retry, and final-state events occurred.
I would not require full retesting after every model change. I would first identify which previously tested assumptions could have been affected, then select the scenarios that need fresh evidence.
Weak-answer pattern
Two responses tend to appear together in this kind of review:
“The approval logic wasn’t modified.”
“We ran the tests again after the upgrade, and everything passed.”
Both statements may be accurate. Neither tells me enough about the evidence on its own.
The first needs supporting configuration and execution-path information. The second needs the test scope and results. Without those records, it is difficult to determine whether the updated agent introduced an alternative path that the regression tests did not exercise.
I would rather see a short explanation of which acceptance scenarios were affected, which were retested, and why the remaining evidence was considered applicable.
Evidence request
For an agent that has already passed acceptance testing and subsequently changed, I would request:
Provide the differences in model version, prompt, tool definitions, permissions, and relevant workflow configuration. Identify which previously tested behaviours and control paths may be affected.
For affected scenarios, provide regression test results and execution traces, including applicable approval rejection, tool failure, and retry conditions. For scenarios not retested, explain the basis and limitations for continuing to rely on the original evidence.
The purpose is to connect the change to the testing decision, rather than request another complete test cycle by default.
Review note
Where some regression testing has been completed but coverage remains limited, I would record:
The original acceptance evidence supports the observed behaviour of the previous system version under its recorded test conditions. Regression testing following the model change covers selected affected scenarios, but execution evidence for certain alternate paths and exception conditions remains unavailable. The current evidence does not establish whether those paths continue to satisfy the original approval requirements.
This preserves the earlier testing result while identifying the part of the current system that remains unverified.
Usage boundary
The importance of that gap depends on what the agent is allowed to do.
For an agent that produces recommendations subject to further human review, some behavioural variation may be manageable within the existing workflow. An agent with production write access creates a different concern, particularly if an untested retry or alternative tool path could affect business records.
If the updated agent can use a write path that has not been covered by current evidence, I would keep that path outside the evidenced operating scope until the relevant control behaviour has been checked. The review record should make clear which operations are supported by current-version evidence and which remain subject to further testing.
Over time, models, prompts, and tools will continue to change. An acceptance report therefore needs to remain associated with a particular system version, configuration, test environment, and evidence date.
Otherwise, the report may still be complete and historically accurate, while nobody reviewing it later can confidently establish which version of the agent it describes.
Boundary
This material is for evidence structuring, review preparation, and evidence-oriented testing discussion. It does not provide legal, regulatory, audit, procurement, certification, or implementation advice.