The confident “done” problem
Consider a fictional order-workflow scenario.
A user asks an AI agent to create a draft order from an approved product document. The agent reads the document, prepares the order parameters and replies confidently: “Done — draft order created.” It also returns an order ID.
The user continues the process as if the order exists. But the available evidence confirms only document access. It does not establish that the order system was invoked or that a draft-order object was created.
That does not prove that no invocation occurred or that no order exists somewhere in the backend. It establishes something narrower and operationally important: the available evidence does not support the completion claim.
What evidence would show that the action actually happened? In this article, I refer to that as execution evidence.
A completion statement is a claim
The agent’s completion statement is a claim, not, by itself, execution evidence.
The statement is evidence of what the agent said. It may also contain or link to other evidence. But fluent language can collapse several different operational events into one confident sentence: deciding to use a tool, constructing a request, sending it, receiving a response and changing a business object.
Those events are not interchangeable. If a team relies on the final answer alone, it may treat a proposed or attempted action as an accomplished business fact.
For a low-consequence lookup, that mistake may be inconvenient. For an order, payment, access change or customer notification, it can alter the next human or automated decision.
From claim to verified outcome
The practical evidence chain is:
Claim → Invocation → Acknowledgement → State Change → Verification
The stages are a practical model, not a universal implementation contract.
Two recent preprints examine related boundaries from complementary directions. Research on verify-gated completion treats completion as an admission decision within a governed runtime, while work on evidence tracing and execution provenance examines how claims, tool activity and supporting evidence can be reconstructed across an agent workflow. This article develops the problem at the practical decision layer. It translates these concerns into a compact test for agent actions with external consequences: separate the agent’s claim from the invocation, qualify the target system’s acknowledgement, establish the provenance of any identifier or receipt, and verify the resulting business state. The result is a practical decision model for determining when an agent’s “done” is sufficiently supported to guide the next human or automated action.
A claim is the agent’s statement about what happened. An invocation is evidence that a tool, connector or API call was attempted with particular parameters. An acknowledgement is a response from the relevant system indicating receipt, acceptance or, in some architectures, completion.
An acknowledgement may mean different things depending on the response contract. For example, HTTP 202 Accepted means that a request was accepted for processing, not that processing completed; by contrast, 201 Created can indicate that a resource was created. The evidential value of an acknowledgement therefore depends on the action and the target system’s semantics. RFC 9110, Sections 15.3.2–15.3.3
State Change denotes the business-state change being claimed: for example, that a draft-order object now exists. Its place in the diagram does not mean that the change has already been proved. Verification is the step that establishes the relevant resulting state through evidence independent of the agent’s unsupported assertion.
Different actions require different evidence
The evidence threshold should reflect both the action being claimed and the consequence of being wrong.
For a read-only lookup, useful evidence may include the invocation parameters, the returned content and the identity or version of the source. The main question is whether the answer can be traced to the requested source under the relevant conditions.
For a state-changing action, the team may need more: the identity of the actor or service, executed parameters, target-system response, a receipt with known provenance and evidence of the resulting object or state. A transactional action such as a payment is a consequential form of state change, so the cost of an unsupported completion claim is higher.
For an asynchronous action, initiation and completion are naturally separated. A job or operation ID may show that work was registered, not that it finished successfully. Google’s long-running operation model, for example, distinguishes an operation name from its done state and exposes a response or error only when the operation is complete. Google Long-Running Operations
This is a professional review principle. Its application will vary by tool, workflow and decision context.
An identifier is not automatically a receipt
The fictional agent returned an order ID. That may look persuasive, but the existence of an identifier does not answer three essential questions:
- Who generated it — the agent, the connector, a simulator or the target system?
- Which execution event is it linked to?
- Can the relevant target-system object or state be verified?
A trace ID can correlate operations across services. A target-system order ID can identify a business object. An identifier invented in natural-language output may identify nothing outside the conversation. These identifiers have different provenance and evidential value.
A plausible format does not establish provenance: an identifier may still have been generated in the agent’s response rather than by the target system.
Distributed tracing can help reconstruct an execution path across services.
OpenTelemetry traces and W3C Trace Context support correlation between related operations, but a trace identifier remains a correlation mechanism: it is not a business receipt and does not by itself prove that the intended state changed. OpenTelemetry Tracing API, W3C Trace Context
The safe rule is simple: ID exists does not automatically mean action completed.
When the evidence chain is incomplete
If the available evidence establishes only an attempt, the claim should remain bounded to an attempt. If an asynchronous request has been accepted but is still processing, pending may be accurate. If completion cannot be established from the available evidence, not verified may be more accurate than completed.
These are descriptive terms for the reader rather than a prescribed state machine. The governing principle is more important than the labels:
If the available evidence does not establish completion, the completion claim should remain bounded to what the evidence actually supports.
An unverified action is not necessarily a failed action. Treating it as one can lead to an incorrect follow-on decision.
A related but separate question arises where human approval is required: the approved scope and parameters should remain traceably connected to the action that was actually executed. An approval record alone does not establish that the approved action and the executed action were identical. That authority question deserves separate treatment; it should not displace the execution-evidence problem here.
Why this becomes an operational risk question
Execution evidence is not merely a logging preference. It affects whether people and systems can rely on an agent-performed action as real business state.
If the claim is wrong, a customer may be told that an order exists when it does not. The same action may be initiated twice. An access change may be assumed to have taken effect. Recovery teams may be unable to reconstruct which parameters were sent or which system accepted them.
The action and the consequence of being wrong should shape how much uncertainty is tolerable. That is where execution evidence connects architecture to risk, consequences and controllability.
Before relying on an agent-performed action, a decision owner should be able to ask:
- What exactly did the agent claim?
- Was a tool invoked, and with which parameters?
- What did the target system acknowledge?
- What identifier or receipt was returned, and who generated it?
- Can the relevant outcome or state be independently verified?
Ask for reconstructable evidence
If your team relies on agent-performed actions, the first question is whether completion can be reconstructed from evidence.
A scoped Operational AI Risk Review can examine whether the available evidence supports reliance on an agent-performed action before deployment or increased autonomy. The Evidence page explains how documented, synthetic, observed and runtime evidence are kept distinct.