iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI agent’s “done” message is a report, not proof that the requested change took effect. Check the run’s execution record, then read the destination system to confirm the change persisted. If the run failed or its connection dropped, inspect for completed side effects before retrying: some actions may already have happened.
What does “done” actually prove?
The final response tells you what the agent believes it accomplished. It does not, by itself, establish that a tool ran successfully or that an external system saved the change. A trace can show the sequence of model calls, tool calls, guardrails, and handoffs; tool inputs and outputs add detail about what the agent attempted and what the tool returned. But execution evidence is not automatically proof of persisted destination state.
For consequential work, use both kinds of evidence: inspect the execution record and independently check the relevant record, file, message, or other state in the system that was meant to change. Microsoft’s guidance likewise recommends checking expected tool calls and their inputs and outputs, while OpenAI describes traces as end-to-end records of agent execution (OpenAI agent evaluations; Microsoft tracing guidance).
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →How to verify an agent’s work
- Define the expected change. Identify what should be different and where it should appear: for example, the target record and field, the file and expected content, or the message and its delivery destination.
- Check the run or session status. Look at the run’s final status and its trace or equivalent execution log. A failed or interrupted run is not enough to determine whether earlier calls had effects.
- Inspect relevant tool calls. Confirm that the expected call occurred. Review its inputs and outputs, and identify calls that could have changed external state.
- Read the destination system. Use the system of record—not just the agent’s summary or a tool’s success message—to verify that the expected change is present and correct.
- Resolve uncertainty before retrying. Check what has already completed, then resume or repeat only work that remains unfinished. Do not blindly replay an action that may have succeeded.
Why a failed turn may still change something
A turn can fail after one or more tools have already acted. A later error, timeout, or disconnected stream does not roll back those earlier effects. OpenAI’s Errors and recovery documentation puts it plainly: “An error event or a disconnected stream doesn’t confirm the turn’s final state.” It directs developers to check completed actions before recovery (OpenAI errors and recovery).
#1 Best Overall
This matters most when actions are not safely repeatable. Retrying a message send, purchase, record creation, or destructive operation without checking can produce duplicates or conflicting changes. Treat an interrupted run as an unknown outcome until you inspect both its execution evidence and the affected system.
Approval and verification solve different problems
Approval controls whether an action may proceed. Verification establishes what actually happened. A review step before a consequential action does not prove that the action later completed or persisted; an after-the-fact state check does not provide prior approval.
Put approval at the side-effect boundary
When an action requires review, pause immediately before the tool that causes the side effect. OpenAI’s SDK approval flow can interrupt execution and resume the same run after a decision. Its guidance also recommends placing validation next to the tool when each custom tool call needs checks (OpenAI Agents SDK approvals).
A confirmation prompt is not necessarily an enforcement mechanism. If the agent is responsible for calling a function that asks for confirmation, the application depends on the agent to invoke that function. OpenAI warns that “Origin approval does not enforce confirmation before individual actions.” For browser-based work where review must be guaranteed, its computer-use guidance points to a controlled browser runtime or restricting the hosted browser to resources that cannot perform the consequential action (OpenAI computer-use guidance).
Rank #3
Confirm predicted changes before applying them
Some interfaces display an agent’s proposed state change before committing it. Microsoft’s AG-UI guidance describes requiring client confirmation before applying predicted changes; rejected changes are discarded rather than applied (Microsoft AG-UI quickstart). That confirmation is a gate on applying the proposal. After an approved change is applied, verify the destination state when correctness matters.
Make verification part of the workflow
Build checks around the operation’s expected outcome, not merely whether the model returned a confident message.
- Specify the postcondition. Define a checkable result, such as a particular field value, a file’s expected contents, or a visible status change.
- Keep execution evidence. Retain traces or equivalent records that let an operator inspect tool calls, inputs, outputs, and handoffs.
- Separate the write from the read-back. Use a distinct read of destination state to confirm persistence when the operation is consequential.
- Make recovery state-aware. Before retrying after an error, determine which effects already completed and avoid repeating them.
- Exercise failure paths. Test interrupted runs, tool errors, rejected approvals, and uncertain outcomes—not just successful end-to-end runs.
OpenAI recommends using traces and graders to debug agent behavior, then datasets and repeatable evaluation runs for benchmarks and comparisons. Microsoft recommends evaluation before publishing and after meaningful changes, followed by production monitoring of quality and safety signals (OpenAI agent evaluations; Microsoft tracing guidance). Turning real incidents into repeatable evaluation cases helps teams catch regressions when prompts, tools, or workflows change.
Free tools Windows power users keep installed
One-click scans. No signup required.
Questions to ask when reviewing a verification design
- Enforcement point: Does the approval or validation check sit directly at the tool that can cause the side effect?
- Evidence: Can an operator inspect the trace and tool inputs and outputs, and is there a separate read of persisted destination state?
- Consequential actions: Does execution pause for review before the action, then resume in a controlled way after the decision?
- Failure recovery: Does the workflow check for completed effects before retrying?
- Repeatability: Can the team turn failures into evaluation cases and compare behavior across versions?
These are design questions, not a measured ranking of agent platforms. Official guidance describes implementation patterns and platform-specific evaluation practices; it does not establish a universal success rate for verification methods.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
