When an Agent’s Acceptance Rule Was Wrong

Google’s October 28, 2026 Agents CLI guide recommends versioning evaluation inputs and expectations separately. That recommendation belongs to Google, not to this article. Original guide

Our question begins after a more uncomfortable discovery: what if the acceptance rule was wrong? A team may have rewarded an agent for an action that its business should not permit. Correcting the rule can lower yesterday’s score without changing yesterday’s behavior. It can also expose consequences that a new score alone cannot repair.

Open Market Notes develops the following hypothetical maintenance-workflow example to examine that problem. This is an independent operating proposal, not a measured experiment or a claim about a deployed Google system.

A correction has two audiences

Imagine an assistant that prepares equipment-maintenance work orders. Its evaluation initially treats a complete work order as success. The business later recognizes that work involving a particular restricted area must first receive authorization. An agent that completed such an order promptly may have satisfied the old test while violating the intended operational boundary.

One audience is the engineering team choosing its next version. Another is the operational owner responsible for work already processed. The first needs a prospective acceptance rule. The second needs to know whether any past output crossed the boundary. Treating both questions as a prompt-tuning exercise risks leaving the second unanswered.

The discovery does not establish that a real-world incident occurred. A prepared order may never have been submitted; a human may have rejected it; a simulated test may have had no external effect. The first task is to establish which of those states the evidence supports, not to turn an evaluation failure into an allegation of operational harm.

Preserve the historical result and add a new judgment

The CLI documentation allows stored traces to be graded again without rerunning the agent. Evaluation documentation

Our proposed correction record would retain the original result with its original meaning, attach the revised judgment and explain the reason for the change. It would not overwrite the past as if the corrected rule had always existed. A reader should be able to see that an old “pass” was accurate as a report of the old test, yet inadequate as evidence of acceptable business conduct.

This distinction matters for accountability. The developer did not necessarily ignore a documented requirement; the requirement may have been missing or ambiguous. Conversely, an omitted test does not grant permission to ignore a known business restriction. The record should separate what the product required, what the test actually checked and what the operator did. Blame cannot be inferred from a changed label alone.

Ask a counterfactual that the records can answer

A useful bridge has two parts. Reassessing the saved interaction asks: would the new rule accept this observed behavior? Replaying the case with a revised agent asks a different question: can the proposed repair produce an acceptable next action under the reconstructed conditions?

These are not interchangeable. The revised agent’s request for authorization cannot prove that the old agent asked. Nor can it establish that authorization would have been granted. If the historical trace contains only a final work-order summary, a missing permission record may mean the check was absent—or simply that logging omitted it. Mark that distinction as unresolved until another authorized record settles it.

The repair should therefore have a constrained objective in this example: stop at the approval boundary and identify the missing authorization. It should not be graded on an imagined approval outcome. The case can test a controllable next step without manufacturing the downstream business decision.

Reconstruction also needs an explicit boundary. A current equipment record may reflect changes made after the original request. Replaying against it is useful for testing today’s workflow, but does not recreate what the old agent knew. If historical inputs are unavailable, say so; leave the retrospective conclusion narrower rather than filling the gap with a plausible story.

Technical correction does not close the operational case

A better prompt can change future behavior. It cannot withdraw an order already submitted, notify an affected supervisor or determine whether work began. Those actions belong to an authorized operational process, not to an evaluation script.

For the hypothetical maintenance team, a correction record would link to a separate disposition: no external action occurred; an authorized reviewer confirmed the order was appropriate; the order was withdrawn; or the status remains unresolved. These are proposed categories, not observed events. The point is to prevent “fixed in the next release” from being mistaken for “past consequences resolved.”

There is a competing risk: excessive retrospective review can consume resources needed for urgent repairs. A proportionate response would prioritize the newly identified restriction, relevant time window and observable external actions. It should not assume every old failure requires the same investigation. A named owner must justify that scope and any remaining uncertainty.

Define closure before chasing a better score

For this proposed process, closure would require more than passing a revised test. The business owner accepts the corrected rule; engineering demonstrates the permitted next step; someone authorized resolves or explicitly retains responsibility for affected historical cases. Each sign-off answers a different question.

The approach has limits. It requires access controls around operational records, a defensible retention policy and time to review ambiguous evidence. Exact replay may be impossible after a tool or model changes. These constraints are reasons to qualify a conclusion, not to present an approximate reconstruction as certainty.

The practical gain is a clearer boundary between improving a system and correcting a past decision about it. A scoring rule can be repaired immediately. Trust is repaired only when the organization can explain what the correction establishes, what it leaves unknown and who owns the unfinished work.