Did the Agent Really Finish? How to Verify the Result Without Trusting Its Final Answer

An action is not the result

An agent can answer “Done” even though the goal has not been achieved. It can also issue a tool call, receive a response saying the request was accepted, and still leave the work pending or incomplete. These are different claims, and they require different evidence.

It helps to distinguish three states. First, the agent attempted an action—for example, it sent an instruction to change a record. Second, the system that received the request accepted or responded to it. Third, the final state requested by the person exists and meets the agreed conditions. Only the third state, on its own, shows that the goal was achieved.

This distinction matters because a success response may refer to only one part of the process. “Request received” does not necessarily mean “change saved”; “test run” does not mean that every requirement for the change has been met; and “booking requested” is not the same as a confirmed booking. The agent’s answer can summarize what happened, but it should not become the only evidence of what happened.

Agent evaluation is concerned with checking whether systems that take actions can complete work reliably. This article has a narrower focus: deciding what evidence is sufficient to accept a particular task as complete. The recommendations and examples below are a practical method, not a claim that there is one universal signal that works for every agent or tool.

Step 1: Turn the request into an observable final state

Before carrying out a task, restate the request as a description of how things should look when the work is finished. “Update the record” is ambiguous: it does not say which field should change, what value is expected, or whether other data must remain untouched. “Make the code change” does not specify the expected behavior or which conditions must continue to hold.

A useful description identifies the affected object, the desired state, the conditions that must be preserved, and any relevant limits. You do not need to turn every request into a lengthy specification. You do need to resolve ambiguities that would change the decision about whether the task is complete.

The observable result should be expressible without relying on the agent’s intentions. Instead of “the agent handled the booking,” specify what would need to exist before you could say it was confirmed. Instead of “the agent fixed the code,” define the expected behavior that should work and which checks are relevant to the change.

Also define what is out of scope. If the request was to update one field, do not assume the agent was supposed to modify other fields, notify other people, or review the entire history. This boundary helps avoid two opposite errors: accepting a partial task as complete and expanding the assignment without authorization.

Step 2: Agree on acceptance criteria before acting

Acceptance criteria spell out what must be observable for the request to count as complete. It is better to define them before carrying out the action: afterwards, it is easier to mistake a convenient output for adequate proof or lower the bar to justify a partial result.

A useful criterion is specific and checkable. “The record is correct” leaves too much room for interpretation. “The status field shows the agreed value for the identified record” names both a state and an object. If it also matters that other fields remain unchanged, that should be stated as an additional criterion.

Not every requirement can be checked with a single signal. A change may require that a value exists and that another attribute has not been altered. A booking may require both confirmation and correct details. A code test may cover important behavior without proving, by itself, that every requirement in the request has been implemented. The list should reflect the actual conditions of the request, not just the ones that are easiest to measure.

For open-ended requests, clarification may be needed first. If there are several reasonable interpretations and the difference affects what counts as an acceptable result, the agent should not silently choose one and later treat it as the only possible interpretation. The agreed criteria also determine when a task is only partly complete and what information needs to be communicated.

Step 3: Choose evidence that supports the claim

Evidence should answer the specific question: what allows us to say that the desired final state exists? A tool output may be suitable for determining whether a request reached a particular component, but not necessarily for proving that the result was persisted or meets every requirement. Do not assign a signal more meaning than it actually has.

When possible, check the state through a relevant read of the affected system or a check that evaluates the result directly. For some work, evidence may be an automated test; for other work, it may be a visible confirmation in the source that manages the state. “Independent” does not always mean “from a different provider.” It means that the agent’s own claim that it completed the task is not being used as the only proof.

Independence also comes in degrees. Asking the agent again whether it finished may simply repeat its claim rather than verify it. Consulting a record view can provide an observation of the state, but you need to know what that view represents and whether it refers to the right object. A separate source may offer more of a cross-check, provided it actually measures the requested result.

The evidence must be linked to the right criterion and object. A successful code test does not automatically establish requirements it does not cover. A booking confirmation is useful only if it refers to the requested booking and its details match what was agreed. If you cannot establish that link, state the uncertainty instead of filling the gaps with assumptions.

Step 4: Separate execution from verification

The component that performs an action and the component that checks its result have different roles. In a simple workflow, the same agent may call a tool and then query the affected system. Even so, the second operation must provide an observation of the state, not merely repeat that the first operation succeeded.

In higher-impact systems, it may be preferable for verification to follow a different path from execution, or for a person to review it. Separation reduces the risk of treating one response as both the action and its proof. This is not an absolute rule: the appropriate degree of separation depends on the risk, the ambiguity of the task, and the quality of the available signals.

Automation may be sufficient when the criteria are clear, the check covers the relevant result, and possible errors have limited consequences. Human review becomes more important when instructions allow several interpretations, consequences are significant, evidence is inconclusive, or contextual judgment is needed that an automated test does not represent.

Requesting human review does not automatically make a conclusion correct. The reviewer needs to see what was requested, which criteria were agreed, and what evidence was observed. Approval without those elements can become another unsupported “yes.” Review should resolve a specific question, not be a formality disconnected from the result.

Three worked examples

The following examples illustrate the method using hypothetical criteria. They do not describe a specific tool or product, and the available signals vary by system. In each case, the key is not to elevate an acceptance response into proof of completion without checking what that response means.

For a record update, the request may be to change a particular field. The issued action demonstrates an attempt; an acceptance response may indicate that the system received the request. To declare the work complete, observe the right record and check the agreed value. If the request also required other data to be preserved, include that in the verification. If the system shows only that the change is pending, the result does not yet meet a criterion that requires the value to appear in the record.

For a code change, the task is not defined by the fact that a patch was produced or a success response was returned. Before carrying it out, clarify the expected behavior and which conditions are part of the assignment. Then use checks relevant to that behavior and review criteria the checks do not cover. A test finishing without errors provides evidence about what that test ran; it does not automatically prove every functional or quality requirement in the request.

For a booking, the difference between requesting and confirming is decisive. The agent may send a request and receive a response that does not clarify whether the booking was confirmed. The evidence must let you identify the relevant booking and compare the details with what was agreed. If there is only a pending request, or the necessary details cannot be confirmed, the final message should say so rather than present the booking as completed.

Partial, contradictory, or unverifiable results

If only some criteria are met, describe the result as partial. Do not turn “the action was accepted” into “the task is finished” to offer a more convincing sense of closure. Avoid the opposite extreme too: if valid evidence supports some requirements, state which ones rather than presenting all the work as unknown.

If two signals conflict, pause before drawing a conclusion until you clarify what each one measures and which state it refers to. A positive response may refer to receipt of the request while another observation shows that the final state has not yet changed. This may not be a true contradiction; it may be a difference in process stage. But until the difference is resolved, it does not support a complete success claim.

If there is no suitable way to observe the result, the right conclusion is that it could not be verified—not that the agent necessarily failed or necessarily succeeded. Communicate the action that was attempted, the response observed, and the criterion still pending. A lack of evidence about the final state does not, by itself, establish what that state is.

Keep the description of the result proportional to the evidence. “Request sent” differs from “request accepted”; “change observed in the field” differs from “all requirements checked”; and “selected tests completed” differs from “no problems remain.” A precise message helps the recipient decide whether to wait, review, or accept the task.

A checklist for designing a workflow

Agent evaluation may consider whether a system that performs actions completes work reliably, and tests can help interpret particular executions. But a score, an execution status, or a tool response does not replace defining the result that matters for a particular task. The team must translate the request into observable criteria and connect each conclusion to the evidence that supports it.

Before accepting or reporting a task as complete, work through this checklist. If you cannot answer a question, that does not always mean the task failed; it does indicate that you should limit the claim, obtain the missing evidence, or request a review appropriate to the impact.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.