An assistant can describe a completed task before the underlying system reflects the intended result. I want a completion standard that follows the work through that last step. For a record update, that means checking the record. For a transfer, it means checking the destination and the relevant contents. The right check depends on the consequence of the task and should be part of its definition from the start.
Source
Staging a change still leaves a completion question
GitHub’s March 2026 architecture describes buffered writes that pass through checks before being applied. Even with that separation, an operator still needs to know whether the intended destination state exists.
My proposal is a completion contract attached to each consequential task. It should define the state to create, the permitted action, the check that establishes success, and the response to an uncertain result.
Name the state that should exist
Suppose an assistant is asked to change the owner of a record in a business application. A useful task definition names the specific record, the intended owner, the authorized scope, and the fields that should remain unchanged.
The assistant’s response is one event in that workflow. The application’s acceptance of a request is another. The final record state is the thing the user actually needs.
For a read-only research task, the completion check is different. It might require an answer supported by accessible sources, explicit uncertainty, and coverage of the requested question. Define the check according to the task rather than using the same “success” label everywhere.
Proposal
Check the authoritative destination
After a consequential change, read the relevant state from the system of record using an appropriate independent request or view. Confirm the intended value and the identity of the object. If the system processes work asynchronously, distinguish an accepted job from a completed change.
Verification can itself be limited. A destination may update after a delay, return cached data, or expose only part of the result. Record the observed state and the remaining uncertainty. A task that is still pending should say so.
Describe this figure
A completion flow in three columns, left to right. The action: drafted, with nothing sent yet, then submitted, the request sent. If the connection fails, the result is uncertain: did anything change? That branch goes to the check before any retry. The check the reader builds: read the system of record with an independent request or view, and confirm the object's identity and the intended value, whether the job was accepted or the change completed, and record the observed state; the destination may update after a delay, return cached data, or expose part of the result. The result, in words that match the evidence: if confirmed, verified, the intended state exists; if only accepted, pending, and the report says so; if some changed, partially complete, with the unresolved items named; if still uncertain, stop, and a person resolves it. The highlighted path runs from drafted to submitted, through the check, to verified.
NIST’s Generative AI Profile emphasizes evaluation and risk management in context. The completion contract here is a practical application: define success before the action, then retain evidence appropriate to its consequence.
Handle uncertainty before retrying
A connection can fail after an application has processed a request. The assistant may not know whether anything changed. Repeating an action is safe only when the workflow supports that behavior or the destination can be checked first.
A record update, a message, and a financial transaction have different duplicate consequences. Design retry rules for the actual operation. When the result is uncertain and another attempt could cause harm, stop and give the responsible person enough information to resolve it.
OWASP’s excessive-agency guidance supports limiting what the assistant can do. That includes keeping recovery and retry authority inside the scope of the original task.
Report the result at the right level
A completion record should identify the intended outcome, the action taken, the authoritative check, and any exception. Link to protected evidence where useful instead of reproducing sensitive contents in a broad log.
Use language that matches the evidence: drafted, submitted, pending, verified, or partially complete. If two of three records changed, report the two confirmed results and the unresolved third. Avoid turning an incomplete batch into an unqualified success.
This discipline makes the assistant easier to supervise and the workflow easier to hand over. It also gives the user a dependable answer to a very ordinary question: what actually happened?
Proposal
What I would test next
I would test a single record update under success, rejection, delay, and interrupted-response conditions. The assistant should report the state supported by evidence and avoid repeating a consequential action simply because its first response was unclear.