An agent asks for approval to change one record. The user agrees. Before execution, the agent discovers another issue and expands the plan to several records. If the application remembers only “approved,” a specific decision has silently become a broader permission.
I want approval to describe the operation that was reviewed. The objective may stay the same while the action, target or consequences change. Those changes need to remain visible at the execution boundary.
Make the proposal reviewable
A useful proposal identifies the action, the affected resource and the relevant before-and-after state. For a batch operation, it should make the selected records and the selection criteria clear. The person reviewing it needs enough information to understand the practical effect.
I would give the proposal a version and retain the exact fields that affect its meaning. A stable fingerprint can help detect whether those fields changed, provided the application defines how the representation is normalized. The fingerprint is a comparison mechanism; it does not establish who is allowed to approve.
In customer communication software such as Conviro, my support platform, the difference between preparing a response and authorizing an operational change matters. This article describes how I reason about that boundary, rather than a claim that every possible action is available in the product.
Check the world again before applying the decision
The proposed payload can remain identical while the target changes. A record may have been updated, the user’s role may have changed, or another worker may already have completed the operation. Approval should not freeze the rest of the application in time.
I would recheck the target version and current authorization when execution begins. If the preconditions no longer hold, the system can explain the changed fact and produce a revised proposal. The approval record should remain attached to the original version.
This is closely related to keeping remembered context separate from current authority. An old approval is evidence of a past decision, with a particular scope.
Define expiry and consumption
Some actions remain reasonable after a delay; others depend on a short-lived state. An approval can include an expiry time appropriate to the operation. The system should explain when a proposal has expired instead of presenting a previously accepted button as if it were still actionable.
Consumption also needs a policy. If the action may be executed once, two workers should not independently consume the same approval. An atomic state transition can reserve execution, while the downstream operation still needs its own duplicate protection or outcome lookup.
If the remote outcome is uncertain, the correct next step may be reconciliation. Issuing a new approval should not become a shortcut around an unresolved first attempt.
Keep the explanation close to the evidence
A long summary is not necessarily a good approval request. I prefer a concise description of what will change, why the agent proposes it and what evidence supports the decision. Details should remain accessible without obscuring the action itself.
The agent should also distinguish a required approval from a request for missing information. Asking for an address and asking for permission to replace an address are different interactions, even if both pause the workflow.
Review changed-plan cases explicitly
I would test a changed target, a changed payload, an expired approval, a revoked role and a repeated execution attempt. Each case checks whether the approved scope survives the handover from planning to action.
A separate proposal and execution path makes this easier to reason about. The approval becomes a concrete record that the runtime can validate, rather than a conversational sentiment that the agent can reinterpret.
That is the practical value of an approval boundary: a person decides about a specific operation, and the system preserves that decision’s limits as work continues.
Updated 30 September 2026.