An approval expires when the state it describes changes
An approved action can become inappropriate while it waits to execute. Preserve the reviewed proposal and its material state conditions, then reject execution when those conditions no longer hold.
Trace the interfaces between applications and records before changing a system.
Consider an accounts agent that queues an approved payment reminder. The invoice is paid before the message is released. Executing the exact approved tool call would now produce an inappropriate reminder, because the fact supporting the decision has changed.
The approval needs to describe more than an action. It should also identify the material conditions under which that action is authorised. A delay between review and execution creates an opportunity for those conditions to change.
Bind approval to the state that justified it. Check material preconditions immediately before the effect, at the system that owns the target. If they fail, stop the action and obtain a fresh decision against the current record.
The gap has a name
Software security calls this a time-of-check to time-of-use race. A program checks a property of a resource, another process changes the resource, and the program acts as though the checked property were still true. The Common Weakness Enumeration defines the failure in those terms and recommends making the operation atomic where possible, or limiting the gap when it is not. CWE-367
An approval queue lengthens the gap deliberately. The check includes the agent’s retrieval, reasoning and presentation of the proposal. The use happens after a person has found time to review it and after a worker has collected the approved job. Minutes or days can separate the two. A longer expiry time changes how often the race appears. It does not close it.
- 01 Observe The agent reads the target and the facts that justify a change.
- 02 Propose The action is generated against that observed version.
- 03 Approve A person accepts the action and the evidence shown with it.
- 04 Wait The target or a relevant dependency changes.
- 05 Execute The tool applies the old action unless the receiver checks a precondition.
Evaluate the precondition and the mutation together at the receiving system. A final read in the orchestrator followed by an unconditional write still leaves a gap in which another process can change the record. A shorter gap reduces exposure without closing the race.
HTTP already provides this contract. A client can send a strong entity tag in
an If-Match header with a state-changing request. RFC 9110 requires the origin
server to evaluate that precondition before performing the method and not to
perform it when the current representation no longer matches. The normal failure
response is 412 Precondition Failed.
RFC 9110, section 13.1.1
Kubernetes applies the same pattern through resourceVersion. A client updating
an object supplies the version it read. If the object has changed, the API server
rejects the stale update with 409 Conflict, leaving the client to retrieve the
new object and decide what to do next.
Kubernetes API concepts
Treat a version conflict as evidence that the approved proposal needs reassessment. Automatically retrying an unconditional version of the same action would discard the protection the precondition was meant to provide.
A policy change with an execution consequence
Hypothetical internal policy · not legislation · Fixture revision 1 → Fixture revision 2
Previous text · Fixture revision 1
Execute the reminder after approval.
Revised text · Fixture revision 2
Execute only while the reviewed account version still matches; otherwise obtain a new decision.
Interpretation · decisions to reassess
- Store the state version reviewed with the approval.
- Check the precondition atomically at the receiving system.
- Treat a conflict as a new decision, rather than retrying the old effect.
This is an authored hypothetical policy comparison, not a quotation of official rules or a claim that a regulator changed its text.
A constructed internal policy revision adds a state precondition. Interpretation is kept separate from the two texts.
Reviewed 2026-10-02
Three identities answer three different questions
Recent agent designs increasingly carry an actor identity and an operation ID. Both are necessary, and neither binds an action to current state.
| Value | Question it answers |
|---|---|
| Actor and delegation | Who is acting, for whom, and with which authority |
| Operation ID | Whether this is a retry of the same intended effect |
| State precondition | Whether the facts reviewed for that effect still hold |
The distinction matters during recovery. As argued in Every agent retry needs the same operation ID, reusing an operation ID lets the receiver recognise another attempt at one intended effect. A state version asks a separate question before the first successful attempt. An idempotent request can repeat safely and still carry out a stale decision exactly once.
Preserve the exact proposal shown to the reviewer, with a digest or immutable reference, the material record versions, actor, delegation and operation ID. Execution should use that reviewed bundle. Regenerating its contents after approval changes what the person authorised.
This is also why regenerating a plan after approval is not a harmless convenience. Terraform’s documentation distinguishes a speculative plan from the saved plan that is actually applied. It warns that intervening changes can make a speculative result differ from the final effect. HCP Terraform goes further and automatically discards a saved plan when another run changes the state before confirmation. HCP Terraform run modes
The useful pattern is the same outside infrastructure. Preserve the reviewed plan as an executable artefact. Reject it when its declared state no longer holds. Produce a new plan for a new approval rather than quietly updating the old one.
Decide which changes invalidate the decision
Binding an approval to a version of one record is straightforward. Agent decisions often depend on several records and on retrieved material. Rejecting execution whenever anything in that set changes can be safe and needlessly disruptive. Ignoring dependencies because a single version is inconvenient returns to the original failure.
The design work is to state the business preconditions. For the hypothetical reminder, the invoice is still unpaid and no dispute hold exists. For an access change, the person’s employment state, current role and target group membership might all matter. For a configuration update, the reviewed current configuration and policy version might be the relevant set.
Test the unhappy path. Hold an approved action in the queue, change one material fact, then release it. The test passes when no effect occurs and the trace names the failed precondition. Change an irrelevant field and decide whether the same approval should remain usable. That second case checks whether the version is a thoughtful business condition or merely a lock on the whole record.
Where a source offers no version or conditional operation, the adapter can sometimes create one by storing a digest and using a transaction at the write boundary. Where it cannot, the architecture should say so. A short approval expiry and a final re-read reduce exposure, but they do not establish atomicity.
What this does not tell you
A matching state version does not make the approved action correct. The agent may have misunderstood the record, omitted a relevant dependency or presented the proposal badly. The person may have approved it carelessly. Preconditions preserve the conditions that were reviewed. They do not improve the review.
Exact version matching can also reject safe work. A record may change in a field that has no bearing on the decision, and systems with frequent updates can create repeated conflicts. The answer is to identify narrower business preconditions where the receiving API supports them, then keep the conservative rejection when it does not. Availability is not a reason to execute against unknown state.
Nor does every output need this machinery. A draft that remains visibly a draft can be refreshed by its reader. The boundary matters when an agent sends, changes, deletes, releases or commits something after the person who reviewed it has left the path.
The architecture review should demonstrate a stale approval being rejected before an effect occurs. Inspect the record joining the reviewed proposal, precondition, conflict and fresh decision. Human oversight remains meaningful when the system preserves the conditions on which the person decided.