Reversible and irreversible actions

The three classes#

The boundary is not technical difficulty, it is observation. Deleting a sent message from your own store does not delete it from the recipient's inbox, and the presence of a delete button on the record you hold is not evidence to the contrary.

Approval belongs before the boundary#

This taxonomy is the reason autonomy is shaped the way it is. Because the irreversible class cannot be undone, the decision has to be taken before the action rather than after it — which is exactly what ask_before_send does, and what draft_only does more strictly by preparing a reply and not even asking.

A held draft is worth being precise about: it has not been handed to any provider, so there is no message in flight, no delivery attempt and nothing in your sent folder. The recipient sees nothing. A held draft is not a slow reply — it is no reply, and the clock the customer is counting is still running.

Uncertainty is its own state#

Between reversible and irreversible sits a state most systems refuse to model: the action may or may not have happened. A provider was handed a message and did not acknowledge it. Connect reports sent only on the provider's acknowledgement and shows the rest as uncertain, rather than guessing in either direction.

Guessing has a cost in each direction and they are not symmetrical. Assume failure and re-send, and a customer gets the same reply twice. Assume success and a real customer is waiting for something that never left. Showing the uncertainty puts the choice where the context lives, with the person.

Does Connect use this taxonomy?#

It is built into how actions are gated rather than named on a screen. Four consequences you can see:

• Autonomy is per channel — the channels differ in how visible their actions are, so email, whatsapp, sms and voice each carry their own mode and can be set independently.
• Deleting a conversation is a mark on the record, not a destruction of it: threads.deleted_at is the person's own view, and the record remains for recovery and for the history.
• Merging two people is a human decision. Duplicates are proposed, never applied automatically, because a merge is not cleanly reversible — it preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides, and unpicking that afterwards is guesswork.
• A rejected draft is recorded as a rejection and the engine does not immediately draft the same reply again; the decision is part of the history rather than a silent discard.

What people get wrong about undo#

“Undo send”

Where a provider offers it, it is a delay before sending, not a retrieval after it. Once the delay elapses the action is in the irreversible class

“It is only a draft”

True until it is approved. After approval the send runs through the same boundary a person's own send uses

“I deleted it, so it is gone”

From your list. Deletion in a record system is usually a mark that hides a row; whether it is ever destroyed is a retention question, not an undo question

“The agent should just ask about everything”

That is ask_before_send, and it is a legitimate setting. What it costs is the response time the channel was chosen for

Questions#

Related#

• The four autonomy modes
• Approvals
• Held drafts
• Recover something that was removed
• Duplicate detection