“Canceled” Doesn’t Mean It Didn’t Happen

In an illustrative supplier workflow, a message is in flight. The operator presses stop. The screen loses contact. No send result arrives. I would show: Delivery unknown. Check send status.

The promise of undo ends at the first effect the system cannot retrieve. Stopping later work cannot recall a message the supplier may have read. I would find that boundary before giving the action an undo button.

Which operation does undo describe?

I use four categories when reviewing an agent workflow. These are a design vocabulary, not a claim that every product implements all four.

The distinction changes the next move. A canceled draft needs no correction. Someone who stopped a workflow after it sent a message may need to contact the recipient.

Microsoft's compensating-transaction guidance (opens in a new tab) explains why restoring the original state is not always possible. Concurrent changes and business rules can require a new corrective operation. Compensation can also fail and need its own recovery.

The send changes the promise. I would label the button Stop remaining steps once a send begins. Calling it Undo would promise a reversal I cannot establish.

Where does the workflow cross the boundary?

My illustrative supplier assistant drafts a comparison, saves an internal recommendation, and sends a message to the preferred supplier. The operator decides to stop halfway through.

Before saving, I would discard the draft. After the save, I might restore the earlier recommendation if no one has changed it since. After the message, the supplier may already have read the proposal.

The local copy can go. The message cannot.

I would place the external send behind its own authority check and make its consequence explicit. My account of human control asks who can intervene and what they can still change. Here, the operator can stop the next step. They cannot erase the supplier's copy.

I would also name the affected person. The internal record could be corrected while the supplier still acts on the wrong message. That risk remains. I would assign someone to contact the supplier if a correction is needed.

What if the stop races the action?

The awkward case is an uncertain result. The request to send is in flight. The person presses stop. The interface loses its connection before learning whether the message was sent.

At that moment, neither success nor cancellation is established. I would preserve that uncertainty and give the operator a way to inspect the send. A reassuring label would remove information they need.

A proposed recovery card makes the next move explicit:

I would make Check send status repeat that lookup and show the result beside the original request. The service may say nothing. If the lookup fails, the operator sees who is investigating. I would not turn a failed lookup into permission to send again.

Retries require care. I would keep the same operation identity, but that helps only where the sending service enforces idempotency. Without reliable reconciliation or duplicate protection, an automatic second send can compound the original uncertainty.

Orbyt's experimental Command Record specification records a request, evidence from a separate reader, and what the command cannot undo. An acknowledgement alone does not establish the effect. I would apply that separation to the supplier example.

Here is a synthetic record for that imagined send. Every field, ID, and timestamp below is invented. This is not an observed Orbyt event.

In the historical audit by another AI model, the kill switch was checked once. A rebase could then import a halt without blocking the subsequent push. The first fix checked a tree where that halt could never appear. The second fix corrected it. The check had to read the state that could actually contain the stop.

That audit exposed a broader miss. I had written an audit dimension to read live production state, and in my own words: I still did not apply it to the machinery itself. The published account is the source of that admission. I would not call a supplier send canceled on the strength of a local stop acknowledgement.

Can a restore overwrite someone else's work?

Yes. In the illustrative workflow, the agent changes a recommendation and a colleague edits it afterward. Restoring the entire earlier record would also erase the colleague's contribution.

That is not a clean undo. It is another write with another consequence.

I would read the current version, calculate an authorized correction, then submit the restore with the version I read as a condition. The storage system must enforce that condition during the write. The check belongs there. If another edit lands first, the restore must fail without changing the record. I would re-read and reconcile instead of retrying the old snapshot. I would preserve the original action and the attempted correction in the history.

The same principle applies to permissions. I would not restore yesterday's access settings if that could reintroduce access an administrator removed today. Recovery needs current authority, even when the original action was authorized.

My permissions threat model treats consequence as part of the boundary. A recovery path deserves that same scrutiny. Otherwise the safest-looking button can become the broadest write permission in the product.

Does this make automation too cautious?

The strongest objection is complexity. A recovery system can become more complicated than the task it protects. That cost is real. An unsaved draft is cheap. Reversible local edits do not need the machinery of a distributed business transaction.

I would scale the design to the consequence. I would discard an unsaved draft, use a version condition for shared state, and reserve explicit compensation and escalation for effects that cross system or organizational boundaries.

I would keep an action outside the agent's authority when I cannot observe its result or handle its failure. The button would say Stop remaining steps after the external send begins. The recovery card would name the human operator who can authorize a corrective message.

What to do Next

I would pick one action that leaves the application and mark the point where stopping computation no longer prevents the consequence. I would write the interface copy for before, after, and uncertain completion.

Then I would rehearse the uncertain case in an isolated test environment. I would delay the response after the effect occurs and check that the interface neither claims cancellation nor causes a duplicate. I would keep a confirmed cancellation as the healthy comparison.

I have not run this cancellation race drill. I would record the observed result separately from the expected result before claiming the recovery promise works.

Canceled means later work stopped only when that stop is confirmed. It says nothing by itself about an effect already outside the system.

Related reading:

• The Money Path Is a Protected File. the consequences that justify a tighter authority boundary.
• Governing an Agent Leadership Team the relationship between observation, intervention, and control.
• Verification Is the New Literacy why an asserted outcome needs an independent check.
• Simple Is Expensive. the work behind a clear and honest surface.