TL;DR
AI agent verification must establish what happened in the target environment, not simply whether a tool returned successfully. Separate request acceptance, configuration changes, runtime convergence, and service outcomes. Bind evidence to the approved resource, release, workload, and measurement window. Use explicit PASS, FAIL, PENDING, and UNKNOWN verdicts, enforced outside the planner. Start with a versioned verification contract for one bounded workflow, then test whether stale measurements, incomplete telemetry, or misleading health signals can produce a false success report.
On this page
- Define What the Agent Is Allowed to Claim
- Make Verification a Separate Runtime Responsibility
- Bind Evidence to the Resource and Revision
- Fresh Evidence Can Still Describe the Wrong Time
- Measure the Workload, Not Just a Healthy Endpoint
- Give the Runtime Four Verdicts, Not One Boolean
- An Implementation Contract for AI Agent Verification
- Walk Through a Verdict That Looks Successful
- Keep Correlation Separate From Durable Evidence
- Test False Success Before Expanding Autonomy
- Conclusion
- External References
Introduction
An AI deployment agent updates a staging application. The platform accepts the request, the execution trace contains no obvious error, and the service dashboard looks healthy. The agent closes the task and reports success.
The replacement instances have not become available. The dashboard is still describing traffic served by the previous release.
In this illustrative scenario, the API acknowledgment and dashboard may both be accurate. The architectural failure is that the agent combines evidence answering different questions and uses it to support a conclusion neither establishes.
This article develops the observation side of AI feedback into an implementation pattern: a contract that determines what the system must establish before declaring an action successful. The companion foundation, AI Feedback Loops: Cybernetics and Control Theory for Agents, is scheduled for September 16, 2026.
We will use a hypothetical rollout of catalog-api in staging. Assume an approved release, a declared deployment owner, controlled test traffic, and read-only verification access. The contract, measurements, and verdicts below are illustrative design examples, not results from a production deployment.
The question is not whether the agent sounds certain. It is whether the runtime has sufficient evidence for the claim it is making.
Define What the Agent Is Allowed to Claim
A single success: true field can hide several stages of an operation.
RFC 9110 makes one boundary explicit: HTTP 202 Accepted means processing has been accepted but has not completed. Other successful responses must be interpreted according to their operation. Successfully updating a desired configuration does not establish that the resulting application works.
For this workflow, separate four claims:
| Claim | Supporting evidence | What remains unproven |
|---|---|---|
| Request accepted | Target acknowledgment and operation identifier | Whether processing completed |
| Configuration updated | Authoritative readback of the approved change | Whether the runtime reached that configuration |
| Runtime converged | Completion evidence for the intended release | Whether the application meets its requirements |
| Outcome verified | Required service checks over an eligible observation window | Permanent correctness or freedom from every possible side effect |
These are assurance layers, not universal API states. An integration may expose several through one interface, but the workflow should not collapse their meanings.
Define the terminal claim before execution. For catalog-api, it might be: the approved release is serving the designated staging workload, its latency and error checks pass, representative requests return correct results, and the required guardrails remain satisfied.
That definition belongs to the service owner and approved workflow. The planner must not weaken it after discovering that the rollout is difficult to complete.
Authorization remains separate. An action can achieve its technical objective while exceeding its approved scope. A verification pass must not retroactively legitimize an unauthorized change.
Make Verification a Separate Runtime Responsibility
The model may propose an action, interpret observations, and explain a result. It should not be the sole authority accepting its own success claim.
In this design, a verifier reads authoritative state, measurements, and approved probe results. It evaluates a versioned contract. A workflow transition gate then enforces whether the task can complete, continue observing, or enter an escalation path.
Notice that the action record and environmental evidence meet at the verifier, not inside the planner’s narrative.
The planner receives the verdict and reasons. It cannot change the required window, substitute another resource, or remove a failing check to complete the task.
This does not require a separate platform for every function. Deterministic application logic may be sufficient for a narrow workflow. Higher-impact actions may justify stronger deployment and identity separation. The important boundary is that executing an action does not grant authority to redefine its acceptance criteria.
A model-assisted evaluator can help with semantic checks, such as whether generated content satisfies a rubric. However, rereading the planner’s explanation produces no new evidence about the environment. The evaluator must inspect the relevant artifact or observation, and ambiguous judgments need an explicit disposition.
Likewise, two verifiers reading the same stale backend do not provide independent confirmation. Assess independence by shared failure modes, not by the number of agents or dashboards involved.
Bind Evidence to the Resource and Revision
A service name is not enough to identify the subject of a verification decision.
For the proposed rollout, bind the operation to its environment, resource identity, approved release, and verification-contract version before execution. Use an immutable resource identifier where available. A newly created resource with the same display name should not accidentally satisfy an older operation’s checks.
Preserve the distinction between the intended artifact and the active runtime revision. A release label copied into a request shows intent. Verification must establish that the relevant runtime is actually using the approved artifact and that the measurements describe its traffic.
Kubernetes provides a concrete example. Its Deployment documentation defines completion using updated replicas, availability, and the absence of running old replicas. The same documentation demonstrates that Available=True can coexist with Progressing=False and ProgressDeadlineExceeded.
A workload can therefore retain minimum availability while failing to complete its intended rollout. For this article’s design, checking only the availability condition is insufficient.
The verifier should also detect superseding changes. If another deployment replaces release A with release B during measurement, do not attach A’s evidence to B. Invalidate the affected completion decision and reconcile the new state.
A Passing Verdict Has a Validity Boundary
Record the claim as “release A satisfied contract V during window W,” not “the service is healthy.”
Before a later workflow relies on that verdict, check that its target and required conditions still apply. A resource replacement, configuration change, or expired freshness limit can invalidate reuse without making the original historical record false.
This is the difference between preserving evidence of a completed check and treating that check as permanent permission to proceed.
Fresh Evidence Can Still Describe the Wrong Time
A query executed now can return an aggregate containing pre-change behavior. Collection time does not establish when the underlying events occurred.
OpenTelemetry’s Logs Data Model distinguishes Timestamp, the source event time, from ObservedTimestamp, when the collection system observed the event. The architectural lesson extends to this verifier: retain measurement times and window boundaries rather than treating the arrival of a result as evidence of its applicability.
For the staging example, suppose the rollout is verified as converged at 10:02:15 UTC. The contract requires five minutes of subsequent test traffic. The diagram assumes clock uncertainty has already been accounted for.
A healthy five-minute aggregate queried at 10:03 does not satisfy that contract. Most of its observation period precedes convergence.
In the implementation, begin after the latest plausible convergence time allowed by the approved clock-error bounds. Require a full measurement window, an acceptable delay between its end and the verdict, and usable coverage throughout it.
Coverage needs its own evidence. For controlled staging traffic, reconcile the test client’s dispatched attempts with their recorded outcomes and check collection health. A full-looking dashboard is not a completeness check.
If the selected window cannot be evaluated reliably, do not silently choose a later, healthier one. A new attempt may be appropriate, but it needs an explicit rule and must retain the earlier result. Otherwise, repeated measurement becomes a way to search for a pass.
Measure the Workload, Not Just a Healthy Endpoint
Google’s Monitoring Distributed Systems distinguishes internal instrumentation from checks of externally visible behavior. It also separates latency, traffic, errors, and saturation. Applied here, platform readback and client-path checks answer different questions.
For catalog-api, the approved test client sends a defined catalog-read workload through the intended staging ingress. The probe suite checks expected response content, not merely an HTTP success code. Infrastructure measurements support diagnosis and guardrail checks; they do not replace the application result.
Make the Denominator Explicit
Define an eligible attempt before collecting results. In this example, each dispatched test request receives an identifier and an outcome: successful response, defined failure, or unresolved observation.
Count timeouts and the other contract-defined failures in the error numerator. Use all eligible attempts as the denominator. Do not calculate reliability only from requests that reached an application log, because the test is meant to assess the client-visible path.
When an attempt’s outcome is missing, preserve that uncertainty. Missing records are not successful requests, and excluding them can make the result look better than the evidence supports.
Measure successful-request latency separately from failures, while retaining failure information for diagnosis. The latency threshold and error threshold must both pass; one does not compensate for the other.
Do Not Average Percentiles
Here, p95 means the 95th percentile of duration across the defined successful-request population.
Prometheus documents why averaging precomputed instance quantiles does not produce a valid service-wide percentile. Its histogram approach supports aggregation before estimating the percentile, with accuracy dependent on the representation used.
Approve the aggregation method alongside the threshold. A minimum request count makes a window eligible for this contract; it does not independently establish statistical confidence. A staging test also demonstrates behavior under its defined workload, not every production traffic pattern.
Give the Runtime Four Verdicts, Not One Boolean
A verifier must distinguish an observed failure from an inability to determine the result. It must also distinguish normal waiting from a broken observation path.
Use the following proposed state model:
| Verdict | Meaning | Permitted workflow behavior |
|---|---|---|
| PASS | Every required check passes on valid, applicable evidence | Complete the scoped task |
| FAIL | Trusted evidence establishes a required-condition failure or critical breach | Block dependent writes and enter approved recovery or incident review |
| PENDING | Execution or measurement is legitimately incomplete within its deadline | Continue bounded, read-only observation |
| UNKNOWN | Required evidence is missing, stale, conflicting, unbound, or inconclusive at the deadline | Preserve uncertainty, block dependent writes, and escalate |
PENDING is not a holding place for every problem. A healthy collector waiting for an observation window to finish is different from a failed collector that cannot provide the required evidence.
Define precedence per check. A verified critical breach remains a failure even when another source is unavailable. Preserve both facts. Conflicting observations about the same condition need reconciliation, not a majority vote between dashboards.
Monitor critical abort conditions during execution. Do not wait for the final window to finish when a separately defined stop condition has already been established. However, do not fail a percentile test early merely because an incomplete window looks unfavorable unless the contract explicitly defines that early-abort rule.
Amazon’s Making retries safe with idempotent APIs explains another important uncertainty: after a timeout, an operation may have happened despite the missing response. An ambiguous execution result therefore requires reconciliation rather than an assumed failure.
UNKNOWN does not mean “nothing happened,” and it does not authorize another mutation.
Blocking dependent writes means preventing this workflow from building further changes on an unverified assumption. It does not mean shutting down the service or disabling its established controllers. Recovery actions still require their own authority.
An Implementation Contract for AI Agent Verification
The YAML below describes a proposed contract for the staging rollout. It is not a Kubernetes manifest, an OpenTelemetry configuration, or an executable vendor policy.
Its purpose is to make acceptance criteria inspectable before implementation. Replace the illustrative thresholds, traffic profile, probe suite, and deadlines with approved local definitions. Resolve the resource and release bindings before execution.
contract_id: catalog-rollout-verification-v1 scope: environment: staging service: catalog-api resource_uid: bind_before_execution expected_release: bind_from_approved_change evidence: readers: [cluster-reader, telemetry-reader, test-client] require_authenticated_sources: true require_valid_clock_bounds: true max_current_evidence_age_seconds: 30 planner_summary_is_evidence: false convergence: require_expected_release_readback: true require_platform_rollout_complete: true service_window: start: after_verified_convergence_and_clock_margin duration_seconds: 300 selection: first_full_window traffic_cohort: catalog-read-test-v1 measurement_boundary: approved_test_client min_successful_requests: 1000 max_successful_request_p95_ms: 500 max_error_ratio: 0.01 required_probe_suite: catalog-read-v3 require_all_client_attempts_accounted_for: true require_complete_source_coverage: true on_superseding_change: invalidate_completion_decision constraints: require_authorized_execution_receipt: true required_guardrail_profile: catalog-staging-guardrails-v1 verification: deadline_seconds_from_dispatch: 1200 known_critical_breach_takes_precedence: true on_pass: complete_with_scoped_verdict on_pending: bounded_read_only_polling on_unknown: block_dependent_writes_and_escalate on_fail: block_dependent_writes_and_request_recovery_review
The implementation must define what each reader returns and how its identity and scope are checked. The probe suite and guardrail profile must resolve to versioned tests, not remain unexplained names. Missing mandatory results prevent PASS.
Reject unresolved bindings, unsupported keys, invalid units, and malformed observations. Never convert a missing numeric value to zero. A parser accepting the YAML says nothing about whether the runtime enforces its rules.
The freshness bound applies to current-state evidence and the end of the completed measurement window, not to historical execution receipts. Persist the dispatch time and operation record so a restart does not reset the 20-minute deadline. Rate-limit polling separately.
At the deadline, emit FAIL when valid evidence establishes failure. If the result is still inconclusive, emit UNKNOWN rather than extending the deadline automatically. A human-authorized exception should be recorded as an exception, not relabeled as a technical PASS.
Walk Through a Verdict That Looks Successful
Consider an illustrative evaluation using that contract. The approved release is active, rollout completion is verified, and the first eligible five-minute window is fully collected. No superseding change occurs, all required probes pass, and the required guardrails are satisfied.
The test client records 1,200 eligible attempts: 1,180 successful responses and 20 failures. Successful-request p95 latency is 420 milliseconds.
The latency result is below the 500-millisecond limit, and the successful-request count exceeds the 1,000-request minimum. Nevertheless, the error ratio is 20 divided by 1,200, approximately 1.67 percent. The contract permits at most 1 percent.
The correct verdict is FAIL. An illustrative machine-readable result could be:
operation_id: staging-rollout-042 contract_id: catalog-rollout-verification-v1 verdict: FAIL reason_codes: - ERROR_RATIO_EXCEEDED checks: expected_release: PASS rollout_complete: PASS evidence_coverage: PASS successful_request_latency: PASS request_error_ratio: FAIL required_probes: PASS guardrails: PASS next_step: recovery_review_required
That output gives the planner useful diagnostic information without granting permission to repeat the deployment or weaken the threshold.
Now change the scenario. The client confirms 1,200 dispatched attempts, but only 1,180 outcomes are available and the remaining 20 cannot be reconciled. There is no trustworthy evidence that they all succeeded or all failed.
Assuming no other check establishes failure, the result is UNKNOWN, not a zero-percent error rate and not an inferred 1.67-percent failure rate. The collection problem must be resolved before the runtime can establish the outcome.
Finally, suppose every check passes. The supported claim is that this release met this contract under this workload and window. It does not prove that the deployment caused an improvement, nor that future production traffic will behave identically. Preserve that distinction before the incident record becomes a reusable operating lesson.
Keep Correlation Separate From Durable Evidence
OpenTelemetry context propagation can correlate activity across service boundaries. Its sampling documentation also makes clear that traces or spans may not be processed or exported when they are not sampled.
For this architecture, use tracing to investigate the workflow, but retain a durable action and verdict record independently of optional trace retention.
Connect the operation identifier to its approved target, execution receipt, contract version, evidence window, source references, verdict, and reason codes. Preserve the evaluated measurements or a suitably protected snapshot. A saved query alone may return different results later because the underlying data or evaluation time changed.
The executor should not be able to erase failed attempts or overwrite the verifier’s record. At the same time, auditability does not require unrestricted retention of every prompt, customer payload, or secret. Keep the necessary metadata and apply access and retention controls to referenced artifacts.
A trace identifier is useful correlation data. In this design, it is not an authorization credential or proof that a result came from a trusted source.
Test False Success Before Expanding Autonomy
The most valuable verifier tests are the cases in which a plausible success report would be wrong.
| Injected condition | Expected behavior under this contract |
|---|---|
| Request accepted, rollout still legitimately progressing | PENDING within the deadline, without resubmitting the mutation |
| Healthy measurements belong to the previous release | Reject them as completion evidence; collect correctly scoped evidence |
| Window includes pre-convergence traffic | Reject it for the required post-change evaluation |
| Required collector loses observations | UNKNOWN unless other valid evidence already establishes failure |
| Latency passes but error ratio exceeds its limit | FAIL with the specific failed check preserved |
| Known critical breach occurs while another source is unavailable | FAIL, with the separate evidence gap retained |
| Another deployment supersedes the target | Invalidate completion for the original operation and reconcile |
These are proposed acceptance tests, not executed results. Include a valid passing case as well; a verifier that rejects everything is not a useful operating control.
Test the real readers, identities, persistence, and transition gate. A model conversation that promises to respect UNKNOWN does not prove that a downstream write is blocked.
A practical rollout starts with read-only comparison against existing human-reviewed changes. Investigate disagreements between the verifier and the operator, then enforce the gate for one bounded staging workflow. Expand only after its failure handling has been demonstrated.
Assign the service owner responsibility for acceptance criteria, the platform team responsibility for evidence and execution integration, and the governance owner responsibility for authority and exceptions. Give the verifier an operational owner: its outage is a loss of automated decision capability, even when the application remains healthy.
Track inconclusive verdicts, time to verification, rejected evidence, and later-discovered false passes. Repeated UNKNOWN results should trigger instrumentation or contract review, not quiet removal of checks.
Verification adds latency and operational cost. Apply it proportionately to consequence and reversibility, but do not promise autonomous completion where the outcome cannot be adequately observed. Post-action checks also cannot prevent an irreversible side effect that has already occurred; pre-action controls remain necessary.
Conclusion
Reliable AI agent verification makes success a bounded, testable claim. The runtime must establish which resource changed, which release is active, what evidence applies, and how the service behaved during the required observation window.
Start with one action class and one versioned contract. Define the request population, failure denominator, freshness rules, and verdict semantics before execution. Then test whether stale, missing, or misleading observations can produce a false PASS.
Keep verification separate from authorization, and keep both outside the planner’s ability to redefine on demand. The operational benefit is not a more confident agent. It is a workflow that can distinguish completion, failure, legitimate waiting, and uncertainty without concealing the differences.
The next installment, AI Agent Stability: When Retries Become the Incident, examines the correction side of the loop. Knowing that an outcome failed is useful only when the next action remains bounded.
Before an agent declares success, require evidence for the outcome it is claiming, not just a receipt for the action it attempted.
External References
- RFC Editor: RFC 9110: HTTP Semantics
- Kubernetes: Deployments
- Google: Monitoring Distributed Systems
- OpenTelemetry: Logs Data Model
- Prometheus: Histograms and summaries
- OpenTelemetry: Context propagation
- OpenTelemetry: Sampling
- Amazon Builders’ Library: Making retries safe with idempotent APIs
Test whether an AI model responds to the evidence that matters. Use controlled incident variations to expose shortcuts, leakage, brittle recommendations, and...
1 thought on “AI Agent Verification: Prove the Outcome, Not the Tool Call”