Undoing an action
An action that only changed something inside your workspace can be reversed — delete the follow-up, forget the memory, move the deal back, open the earlier version of the file. An action that reached the outside world cannot: a message a provider has accepted is delivered, and no button retrieves it. The dividing line is that, not the tool that ran.
The line, and why it is structural#
Undo is not a feature that some actions were given and others were not. It is a property of what the action did. Changing a row in your own workspace is reversible because the workspace is yours and the previous state is knowable. Handing a message to a carrier or a mail provider is not, because the change now exists in somebody else's system and in somebody's memory.
Every design that pretends otherwise ends up lying in the same place: a 'recall' button that quietly does nothing for most recipients. Connect does not offer one. Designing undo for agent actions is the longer argument; the practical version is that it is better to be told an action is final before you confirm it than to discover it afterwards.
| Action | Reversible? | How |
|---|---|---|
| A follow-up was created | Yes | Delete or complete it; the decision log keeps both events |
| A memory was written | Yes | Forget it at the tier holding it, from the memory viewer |
| An opportunity moved stage | Yes | Move it back; the movement history shows both |
| A file was modified | Yes, in effect | The change was a new version — the earlier one is still there |
| A prospect was created | Yes | Delete it; nothing has been contacted by its existence |
| A draft was approved and sent | No | The provider has it. Follow up with a correction |
| A draft was rejected | Partly | The rejection is recorded; ask for a new draft rather than un-rejecting |
| A call was placed | No | It happened. The transcript and summary are the record of it |
What an undo actually is here#
It is a new action, not the erasure of an old one. Deleting a follow-up Connect created does not remove the entry saying it was created; it adds one saying it was deleted, by you, then. That is deliberate. The decision log is the accountability trail, and a trail that can be edited by the person it holds to account is not one.
The same shape appears throughout. A file is not overwritten, it gains a version. A memory is forgotten rather than never having existed. A rejection is a decision recorded about one message. In each case the history grows instead of being rewritten, which is why 'what happened here?' stays answerable months later.
When something has genuinely gone out#
Establish what actually happened, from the decision log rather than from the conversation.
Result You learn whether the message was sent, held, or refused. Those look similar in a chat window and are three different situations.
If it was sent, correct it forward: a follow-up message that names the mistake plainly.
Result The relationship's timeline holds both, which is the honest history and the one that helps whoever handles the next conversation.
Record what should have happened, as memory or as a standing instruction if it is a rule rather than a one-off.
Result The engine reads those. A correction that lives only in a chat tab changes nothing about the next draft.
If the mistake was structural — an autonomy mode wider than you intended — narrow it at the scope that applies.
Result A contact-scope or endpoint-scope rule beats the channel's, so one sensitive account can be slowed without slowing everything.
Things people expect to undo and cannot#
- A refusal
- There is nothing to undo — nothing happened. Resolve the cause: a suppression, an allowance, or an authority limit.
- A stopped run
- Stop ends the work; it does not reverse the steps already completed. Check what completed before deciding what to reverse.
- A conversation
- Closing a tab discards the conversation, not the actions it committed. Those are workspace rows with their own history.
- A do-not-contact entry
- Not an undo question at all: the Assistant cannot clear one under any circumstances, and a person clears one deliberately or not at all.
Questions#
Is there a general undo button?
No, and a single button would be misleading given how differently these actions reverse. Each is undone where it lives — the follow-up on the follow-ups screen, the memory in the memory viewer, the file through its versions — and the Assistant can carry out most of those reversals if you ask it to.
Can I undo something the engine did rather than the Assistant?
The same rules apply, because the same services did the work. What differs is how it happened: unattended work follows the autonomy modes you set, so a recurring unwanted action is usually a settings question rather than an undo one.
Does undoing remove it from the audit trail?
No. An undo appends. The trail holds the original action, who did it, under which rule, and then the reversal as its own entry — which is what makes the sequence readable later.