Continuous evaluation
AI Agent Drift and Regression Testing
Separate workload change from confirmed regression, preserve known failures as tests and connect operating signals to controlled release decisions.
AI agent drift is a change in the operating environment, inputs or behaviour that may affect results. A regression is a previously satisfied requirement that no longer holds. The two can overlap, but they call for different evidence: detecting a changed workload does not prove quality declined, and a stable input distribution does not prove that a new release is safe.
For teams running agents after handover, the useful question is which requirement changed, which cases are affected and which controlled response is justified. This guide builds an AgentOps testing loop around a scheduling example, a change matrix and a reproducible regression record.
Start with a failure you need to prevent from returning
Imagine an illustrative interview-scheduling agent that proposes available appointment times and prepares calendar invitations for approval. It does not rank candidates or make hiring decisions. An earlier defect applied the organiser's timezone to a remote participant, producing an incorrect local time in the invitation.
The team fixed that defect and added a test. Weeks later, the calendar connector changes its representation of offsets. The agent code remains unchanged, yet the same business error can return. A regression suite tied only to application commits would miss the relevant change boundary.
The regression record should preserve the masked request, intended time, source timezone, connector response, expected invitation and acceptance condition. Record why the original case failed and which evidence established the correction. A test named “timezone check” is too vague to support diagnosis when several calendars and languages are involved.
Distinguish five sources of movement
| Change source | Observable signal | Required follow-up |
|---|---|---|
| Workload | More cross-timezone or Arabic requests. | Check coverage and outcomes for the new segment. |
| Knowledge or policy | Approved scheduling rules change. | Revise expected answers with the policy owner. |
| Model or instructions | A behaviour or configuration version changes. | Run comparable trials against frozen cases. |
| Tool contract | A calendar response field or permission changes. | Run contract and end-to-end effect checks. |
| Evaluator | A rubric or judge version changes. | Bridge old and new measurements on identical cases. |
These categories prevent premature diagnosis. A rise in Arabic volume is a workload shift, not evidence that Arabic performance is poor. A fall in a judge score may be an evaluator change. A drop in confirmed invitations may be a permission outage rather than a model reasoning problem.
Use task and attempt traces to connect the observed result to the actual versions and services used. A release label alone is insufficient if a live knowledge source, model alias or tool configuration can change independently. Keep the evidence needed to establish what ran, while respecting data minimisation.
Maintain a small fixed core and a growing challenge set
The fixed core contains stable requirements that must continue to hold: correct participant identity, timezone interpretation, approved availability, no invitation before required approval and no duplicate calendar effect. Include the previously failed case in the core with a clear expected outcome.
The challenge set adds recent incidents, near misses, new formats and cases that reviewers found difficult. Label its purpose and selection method. A deliberately adversarial collection is useful for finding weaknesses, but its failure rate is not an unbiased estimate of everyday production performance.
Keep a held-out set for release decisions and protect it from routine instruction tuning. If developers repeatedly optimise against the same cases, retain those as useful regression checks while refreshing independent evidence. The Anthropic primary guide to agent evaluations distinguishes task trials and grading, including capability and regression uses. The practical design here combines stable obligations with newly discovered operating risks.
Include cases that should stop or defer, not only cases with a completed invitation. For example, ambiguous participant identity should lead to the agreed clarification route. If the test rewards completion at any cost, it can select a release that appears more capable while violating the actual workflow.
Freeze the right things for a fair comparison
Compare candidate and reference versions on the same task inputs, source snapshots and evaluation contract where feasible. Preserve the environment configuration and tool fixtures. If the purpose is to test a live connector change, deliberately vary that connector while holding other components stable and record the limitation.
Run side-effecting tests in an isolated destination or with an explicitly controlled execution mode. A replay must not invite real candidates again. A mocked calendar can establish request shape but cannot prove real permissions or downstream behaviour; reserve a limited integration test for those properties.
Repeated trials reveal variability, but they do not create new independent business cases. Report both the number of cases and trials per case. If one rare scheduling case fails intermittently, inspect its repeated outcomes rather than hiding it inside a large total of mostly easy trials.
The outcome-evaluation contract should define what counts as success. Use exact comparisons for identifiers and times, source-aware checks for policy interpretation and human review for material ambiguity. A language model's statement that an invitation was correct is not a substitute for the calendar record.
Use sentinel checks between formal releases
Some changes arrive without your deployment. A supplier can update a service, a source owner can revise availability rules and a permission can expire. Schedule low-impact sentinel checks against stable conditions and watch the relevant dependency versions or responses. A sentinel is a narrow warning signal, not a full assurance claim.
For the scheduling example, a synthetic calendar identity can test a known timezone conversion in a controlled environment. Keep it separate from live candidate records and avoid creating misleading business appointments. Confirm that the check still reaches the intended path rather than a permanently cached result.
Combine these checks with production outcome sampling. A fixed sentinel may continue passing while a new user segment fails. Conversely, one broken synthetic credential can fail the sentinel while production is healthy. Triage the signal before changing the model or interrupting all service.
Investigate movement with a comparison worksheet
Use a short worksheet for each material change: observation window, affected segment, task count, original baseline, changed components, missing evidence, suspected mechanism and next discriminating test. State what result would weaken the hypothesis. This helps avoid repeatedly changing instructions because they are the easiest component to edit.
Suppose Arabic scheduling errors increase after a calendar upgrade. Compare the same Arabic cases against old and new connector fixtures. Then compare English cases with the same timezone pattern. If both languages fail with the new fixture, a connector interpretation defect becomes more plausible than a language-specific model defect.
That is an investigative inference, not proof from correlation. Confirm the mechanism with a minimal reproducible case and the destination record. If source labels or reviewer criteria also changed, evaluate those separately. Record uncertainty so the release owner knows whether the proposed correction addresses a demonstrated cause or a working hypothesis.
Set response rules by consequence and confidence
A confirmed unauthorised invitation may justify immediate containment even with little statistical evidence. A small movement in a low-consequence wording score may call for additional labelled cases. Separate hard release blockers from trends that need investigation and from informational workload changes.
Route a confirmed regression through release control with the failing requirement, affected versions and acceptance test for the fix. If a previous version is considered, use versioning and rollback procedures to check compatibility and existing calendar effects. Returning code to an older state does not withdraw invitations already sent.
For continuing incidents, preserve the affected task population and assign reconciliation ownership under incident recovery. Do not wait for a perfect root-cause explanation before preventing additional harmful effects. At the same time, avoid broad changes that destroy the evidence needed to distinguish the cause.
Keep the suite credible as the workflow changes
Tests become stale when policies legitimately change. Require the policy owner to approve revised expected outcomes and preserve the reason. Mark retired requirements explicitly. Quietly editing expected answers until a release passes turns regression testing into a record of implementation behaviour rather than business obligations.
Review test flakiness separately from agent failure. A broken fixture, missing test permission or unavailable evaluator should produce an identifiable test-infrastructure outcome. Repeatedly rerunning until green without recording failed attempts hides variability and makes the evidence difficult to trust.
Measure coverage by important requirements and failure mechanisms, not merely case count. A thousand variations of a simple time request may leave approval expiry untested. Assign an owner to gaps, and retire redundant cases when they consume time without adding distinct evidence.
When a corrected case returns to the passing set, retain its original failure evidence and the repair decision. A later regression may have a different technical cause but violate the same business requirement. Comparing the mechanisms helps decide whether to strengthen the interface contract, expand the test family or revise the operating control. Do not delete the incident case simply because the immediate repair is complete.
Ask for the change-to-test trail
A buyer should request an example linking an operating change to a failed test, a diagnosed mechanism, a controlled correction and a verified outcome. Ask how incidents enter the suite, how Arabic cases are reviewed and how tests remain safe when tools write to external systems.
Discuss agent drift and regression assurance with a masked failure record, the current release bundle and the requirements that must never silently change. The useful result is an owned testing loop that detects relevant deterioration and supports a justified operating decision.
FAQ
Your questions, answered.
Can an agent regress without a new application release?
Yes. Model routing, live knowledge, tool schemas, permissions and evaluator configuration can change independently of application code. Record the components actually used and test important contracts between releases. A stable deployment identifier does not establish stable behaviour when the surrounding operating environment can move.
Is a change in input distribution enough to prove agent drift caused harm?
No. It establishes that the workload changed, which may reveal a coverage gap or require more evaluation. Inspect outcomes for the affected segment and compare plausible causes. A rise in cross-timezone requests, for example, does not itself prove scheduling quality declined; the destination records and acceptance checks must show that.
How should previous agent incidents become regression tests?
Preserve a masked reproducible case, the violated requirement, expected outcome and evidence that confirmed the fix. Test the failure mechanism rather than copying a vague incident description. Use safe fixtures or isolated destinations for external actions, and keep the case when it protects a requirement that remains valid.
Why keep a held-out agent evaluation set?
Repeatedly tuning instructions against the same cases can overfit the observed examples. A held-out set provides more independent release evidence. The tuned cases still help detect known regressions, but they should not be presented as wholly independent validation. Refresh coverage when workloads and requirements legitimately change.
How do we distinguish a flaky test from an intermittent agent defect?
Inspect whether the variation comes from the test fixture, permissions, evaluator or the agent itself. Preserve every attempt and the relevant configuration. A broken test environment needs its own status, while genuine intermittent failure remains a product risk. Rerunning until a pass without recording failures conceals the distinction.
When should expected regression-test results be updated?
Update them when an authorised requirement or policy change justifies a new result, with approval from the responsible owner and a preserved explanation. Do not alter expectations simply to make a candidate release pass. Keep the old requirement history so reviewers can distinguish an intentional change from an accidental loss of capability.