The API call hasn't run. Can you still cancel?
You spot the wrong account and click Cancel. The agent hasn't made the API call yet. You'd expect that to stop it.
In the approval system I tested, it could already be too late to withdraw permission.
The agent consumes its permission before making the call. Until then, withdrawing approval blocks it. Once that permission has been consumed, withdrawal won't stop the call, even though it hasn't run yet.
The wrong-account example is hypothetical. The timing problem comes from the approval implementation I tested with scripted agents. It's something I'd need to account for before putting a Cancel button in front of someone.
Permission can be consumed before the work starts
The approval system issues a grant authorizing an action. Before executing that action, the agent redeems the grant. That's the point at which the permission is consumed.
Withdrawal and redemption are coordinated so that an unused grant can't be withdrawn and then successfully redeemed. But redeeming the grant and executing the API call are separate steps. The lock protecting the permission lifecycle doesn't cover them as one operation.
That creates a sequence like this:
- The agent redeems the grant.
- The user withdraws approval.
- The API call executes.
By the second step, withdrawal has nothing left to block through that grant. The permission has already been used, even though the external action hasn't happened yet.
This is specific to the implementation I tested. Another system might support stopping queued work or interrupting execution. It needs to provide that capability separately rather than assume that withdrawing approval will do it.
What should Cancel tell the user?
A person looking at a pending action needs to know whether they can still prevent it. The label “pending” doesn't answer that if permission has already been consumed.
Before redemption, the interface can request withdrawal and report whether it succeeded. It shouldn't announce success just because someone clicked the button. Redemption could have happened while the request was being processed.
After redemption, the interface needs to reflect what the system can actually do. If there's a way to interrupt execution, the cancellation flow needs to invoke it and report the result. If there isn't, the user needs to know the action may still go ahead.
Undoing the result is another question. An API might support reversing a change, or it might require a new action to compensate for it. Some consequences can't be taken back. I'd want those possibilities checked for the particular operation before promising recovery.
These are design recommendations based on the withdrawal finding. I didn't test a person's response to a Cancel button, interruption of an API call, or reversal of a completed change.
What I'd test before calling it cancellation
I'd start with an unused grant and confirm that successful withdrawal prevents redemption. Then I'd deliberately pause the workflow after redemption but before the API call, request withdrawal, and inspect what happens when execution resumes.
That second test is useful because it separates two moments that can look almost simultaneous in normal operation. It shows whether the product's cancellation promise still holds after permission has been consumed.
I'd also compare the message shown to the user with the recorded outcome. A withdrawal request, a successful withdrawal and a completed API action are different events. An audit record should make their order clear enough to investigate without treating the click itself as proof that anything stopped.
The retained lab finding establishes the withdrawal boundary in this implementation. It doesn't establish a universal rule for agents, or tell me how a person would interpret the interface. It does tell me where I'd need another control if I wanted cancellation to remain possible.
The user shouldn't have to discover what Cancel meant by checking whether the wrong account was changed.
About the test: This article draws on the retained Milestone 5 closure record from my agent-approval lab, completed in September 2026. The experiments used scripted agents and approvers, with no autonomous-model trials or human participants. The diagram illustrates the ordering of events; it isn't a screenshot or a record of a human clicking Cancel.
