An AI agent proves completion by producing a durable receipt that connects the exact request to the action taken, the resulting state and an independent verification. This is narrower than preventing an agent from declaring victory too early. A policy determines when a completion claim is allowed. This guide defines the interoperable evidence record that another person or system can inspect after the run.
Bind the receipt to the exact request and target
Start with a request identifier and a target-state specification. A request to update a CRM record should name the record, field, permitted value and relevant version. The agent narrative is not the target. The target is the state that must exist in the system of record after the action.
Record the action attempt separately from the result. A successful tool response may confirm only that an API accepted a command. Read the exact field back from the system that owns it and compare that value with the target state. The company-memory article supports the same principle: a useful answer needs traceable sources and controlled access, not just fluent text.
Handle version changes explicitly. If the record changed after the request was created, the receipt should show the version the agent read, the version it attempted to write and the version verified afterward. A mismatch may require a retry, a new decision or a controlled failure. It should never be hidden behind a generic success message.
Use a portable completion-receipt schema
The receipt should be compact enough to store and specific enough to audit. Include the request identifier, target identifier, requested state, action identifier, tool response, read-back value, timestamps, verifier identity and final status. If the task fails, include the failed condition, recovery owner and whether any partial change must be reversed.
- Requested: the exact business state authorized by the requester.
- Attempted: the action, tool and parameters used within that authority.
- Observed: the state read back from the authoritative system.
- Verified: the comparison result produced independently of the agent narrative.
- Resolved: the final status, failure detail and recovery responsibility.
Separate evidence from interpretation. The raw tool result and read-back belong in the evidence layer. A short human-readable summary can explain them, but it must not replace them. The checks for invented agent metrics are relevant because every claimed success rate should be recomputable from receipts that match real target states.
Verify independently and disclose failure honestly
The verifier can be a deterministic read-back, a separate checker with narrower permissions, or a person for high-impact work. It must not rely only on the same narrative that declared completion. For a compound task, create a receipt for each material outcome and a parent receipt that explains whether all required outcomes passed.
Test the receipt against retries and partial execution. A second attempt should reference the first receipt, show what changed and avoid presenting duplicate side effects as two successful outcomes. This history is essential when recovery spans more than one run.
The verified completion release note is a product-specific example of why a durable check matters. This guide has a different purpose: to define a reusable receipt schema for actions performed by business agents, including partial failure, target versions and independent read-back.
Protect secrets while preserving audit value. Store references or redacted evidence when the underlying record is sensitive. Define who can inspect the full receipt and how long it is retained. A proof system that exposes unrelated customer data creates a new failure even if the original task succeeded.
Frequently Asked Questions
The requester defines the exact target state, while an independent verifier decides whether the observed state matches it.
Keep the request identifier, target version, attempted action, tool response, read-back value, timestamps and verifier result.
The message does not prove the target state was read back independently, so it cannot serve as a completion receipt or close the task.
The receipt should record the requested, attempted, observed, verified and resolved states, including any partial failure.
The final deliverable is the receipt schema, verifier contract, retention rule and failure route. Teams building agents that act in operational systems can use AI4SALE AI agent development to design these controls. Completion should become a state another operator can verify, not a sentence the agent asks everyone to trust.