The AI Agent Passed Its Test. What Changed Since Then?

How GCC enterprises can keep AI agents dependable when business rules, models and integrations change.

An AI agent needs renewed evaluation when the conditions behind its approval change: the business rule it applies, the information it reads, the tools it can use, the model that runs it or the authority it holds. For a business owner, the practical question is whether the updated agent still completes the right work within the agreed boundaries. A successful demonstration from last month cannot answer that question on its own.

A procurement assistant may still produce a convincing recommendation after a supplier policy changes. A service agent may still confirm a booking after the booking system changes what “available” means. Both can sound competent while creating work the business must later correct.

For GCC enterprises moving from pilots into everyday operations, the next discipline is maintaining evidence that an agent remains fit for its task. Start with one live workflow, a record of changes and a small set of business cases that can be repeated. Expand the evaluation as the consequences and scope of the agent increase.

Why the original acceptance result has a shelf life

In a preprint submitted on 1 October 2026, researchers evaluated two related enterprise agent skills across 240 trials. They found that correct final results could coexist with deviations detected in the execution process. Those flags were not automatically confirmed operational defects; the study also leaves longitudinal testing under real API evolution for future work. Its useful lesson is to examine relevant actions as well as the final answer, without presenting the experiment as a universal failure rate. Read the study and its limitations.

• Read the study and its limitations

There is a practical balance here. A workflow may have several valid paths. Requiring one exact sequence can reject a useful solution for the wrong reason. Anthropic’s January 2026 engineering guidance makes this distinction and discusses repeated trials, different grading methods and human calibration. It is vendor guidance, not independent certification. Agent evaluation guidance.

• Agent evaluation guidance

The business should therefore identify the conditions that must always hold. Approval must precede a purchase. A customer confirmation must correspond to an accepted reservation. Restricted information must stay within the correct account. Other steps can vary when that flexibility does not compromise the task.

Decide which changes require another decision

Give each agent a named business owner and a technical owner. The business owner defines acceptable outcomes and consequences; the technical owner maintains the integrations, tests and release mechanism. Security or data owners join when access or sensitive information changes. In a smaller organisation, one person may hold more than one role, but the responsibilities should remain explicit.

Record a change when someone updates a relevant procedure, source document, model, prompt, tool, permission or downstream system. Include the old and new versions where available, the effective date, the affected task and the person responsible for evaluating the impact. This can start in the change-management system the team already uses.

Distinguish a change in wording from a change in meaning. Correcting a spelling error may need a simple check. Replacing “request received” with a status that the agent interprets as “request approved” requires a business test, even if the software change appears small.

The following is a proposed starting point, not a regulatory checklist or a complete test suite.

A supplier-controlled update deserves a place in this register too. Ask what can be versioned, which changes are announced and what happens when an earlier version is withdrawn. Where the organisation cannot hold a version, record that limitation and decide whether the task needs a more conservative operating mode.

Keep a reference for what “good” means

For each important case, retain the input, relevant policy version, expected business result and evidence used to judge it. Store the agent configuration and tool versions alongside the run. Use approved, minimised data or synthetic cases where possible; restrict access to any retained customer or employee information.

Keep two sets of expectations visible. One protects behaviour that must remain unchanged. The other describes the intended new behaviour. If a policy legitimately changes, an old result may no longer be correct. Preserve the old expectation for history and add the revised one with its effective date and owner’s approval. Quietly changing the expected answer until a test passes removes the value of the comparison.

Choose cases that expose consequences. Include the routine request, an ambiguous request, a missing prerequisite, a denied action and a previously observed failure. For a workflow operating in Arabic and English, include equivalent business requests in both languages where they are within scope. This checks the work the agent is expected to perform, rather than whether it can translate a greeting.

Repeat consequential or variable cases and report the number of trials and failures. One successful attempt is weak evidence for a task used repeatedly. The required depth depends on the cost of a wrong action and the variety of inputs; there is no universal sample size that makes an agent safe.

An illustrative example: a purchasing policy changes

Consider a fictional distributor operating in the UAE and Saudi Arabia. Its assistant prepares purchase requests and routes them for approval. The assistant can create a draft requisition but cannot commit a purchase order. This example is not a Bridges client case or a statement about procurement law.

The company changes its internal policy: orders from a newly onboarded supplier now require a vendor-master review before normal approval. A test based only on the final requisition could miss the change. The requisition might contain the right items and amounts while being sent into the wrong approval queue.

Build a small comparison around an established supplier, a new supplier awaiting review, a supplier whose review has expired and a request whose supplier identity cannot be matched confidently. Include a request that cites an old policy attachment. For each case, specify whether the draft may proceed, must wait or needs a human decision.

The release decision depends on more than a plausible explanation. The new supplier’s request should remain in the correct pending state; the reviewer should receive enough evidence to act; and the agent should not announce that the purchase is approved. If the supplier system times out, an unknown result should remain unknown until checked.

Test this in an isolated environment with safe records and simulated external effects. Do not send real orders to suppliers as part of a regression test. After the initial checks, an authorised limited rollout could allow the assistant to prepare drafts for human review while the revised routing is observed.

The outcome of the exercise is a release decision supported by recorded cases and a clear account of what still needs review.

Inspect evidence that can be verified

Capture what the system actually did: the sources it retrieved, the tools it called, the arguments supplied, the approvals recorded and the resulting business state. The agent’s final message is one item of evidence. It does not replace the reservation, requisition or case record in the system of record.

NIST’s ongoing evaluation-probes research explores checking agent claims against a trusted document collection and retaining a structured audit trail. Its experimental focus is factual grounding; it does not certify arbitrary actions or establish that a whole enterprise workflow is reliable. NIST project description.

• NIST project description

For a business workflow, use direct checks wherever the result is unambiguous: whether an approval exists, whether the destination account is correct, or whether the record remains pending. Use a clearly defined human review for judgement such as whether an explanation is adequate for a customer. A model-based evaluator may help triage these cases, but its scoring also needs validation.

Do not require access to a model’s hidden reasoning to establish accountability. Observable actions, source references, policy versions and confirmed outcomes provide the practical audit record. Avoid putting secrets or unnecessary personal information into the evaluation logs.

Make the release decision explicit

Prepare one short decision record before allowing the changed agent to act. State the intended change, the affected workflow, the test cases and versions used, the results by case type and the unresolved limitations. Name who is accepting the change and who can suspend it.

A useful release record answers five questions: what changed, what should remain true, what evidence was collected, what scope is approved and what would trigger a stop. Give it a review date or a condition that requires renewed approval, such as another policy or integration change.

Separate serious boundary failures from service-quality issues. A prohibited action or cross-account disclosure should block release in the proposed approach here. A slower but correct draft may be a tradeoff the owner accepts. A high overall score should not conceal a consequential failure in one small group of cases.

Choose between holding the change, releasing it with narrower authority or approving the defined scope. A missing result is not a pass. Record any exclusion, including a language, branch or tool that was not evaluated, so the next operator does not assume broader approval.

Keep the first live release observable and reversible where possible

After evaluation, start with the smallest useful scope the owner has approved. Shadow evaluation can compare proposed decisions while preventing the candidate from making external changes. A limited live rollout requires additional controls because it can affect customers and business records. Distinguish the two in the plan.

Define the stop condition before rollout. Examples include an unexpected permission request, a wrong routing decision or an accumulation of unresolved cases beyond the owner’s agreed limit. Ensure the fallback has staff and capacity; switching to a human queue is only useful if someone can operate it.

Reverting software does not undo a sent message, committed order or changed customer record. Identify which effects can be reversed, which need a compensating action and which require direct human resolution. Preserve the affected case references so the team can follow through.

NIST’s AI Risk Management Framework Playbook addresses monitoring after deployment, change management, incident handling and version history. These are voluntary US-origin resources that can inform an organisation’s approach; they are not a new UAE, Saudi or GCC-wide legal mandate. NIST Manage guidance.

• NIST Manage guidance

Measure whether useful work survives the change

Review completed business cases against all eligible cases started. Show exceptions, pending work and failed attempts separately. Otherwise, an apparent improvement can come from leaving difficult cases unresolved or removing them from the denominator.

Compare like workloads under the previous and candidate configurations where that comparison is feasible. Track human correction time, unresolved-case age and the cost of completed work, including review effort. A faster initial response is of limited value if staff spend longer repairing the result.

Separate failures caused by unavailable systems from incorrect agent decisions, while preserving both in the operational picture. Do not dismiss an integration failure merely because the model behaved correctly; the business still needs the task completed or safely handed over.

Bring confirmed incidents and near-misses back into the evaluation set. Retire obsolete cases through a recorded decision, and add cases for new services, customer groups or languages. This keeps the evaluation connected to the work rather than frozen around the original demonstration.

Questions leaders should settle

Bridges’ Intelligent Automation & Agentic AI, AI Strategy, Readiness & Enablement and Managed IT & Cloud Operations DevSecOps services connect workflow design, evaluation and ongoing operation. The scope should begin with the business task and the evidence needed to keep it dependable.

• Intelligent Automation & Agentic AI
• AI Strategy, Readiness & Enablement
• Managed IT & Cloud Operations DevSecOps

Related reading: Before an AI Agent Acts: Define Its Authority and Can Your Arabic AI Assistant Complete the Business Task?.

• Before an AI Agent Acts: Define Its Authority
• Can Your Arabic AI Assistant Complete the Business Task?

The register, purchasing scenario, release criteria and operating measures in this article are proposed practices and illustrative examples. They do not report client results or replace organisation-specific technical, security or legal review.