An agent that edits records will eventually edit the wrong ones: a bad merge, a field overwritten across a few hundred contacts, a cleanup that deleted what it should have kept. A log tells you what happened. It does not give you the records back.
If you are about to give an agent write access to a CRM, here is what the undo has to do, and how to check it before you trust it.
"Agent X updated contact 412" is an audit line. "Contact 412 was {title: CTO, phase: lead}, now {title: CTO, phase: customer}" is something you can reverse. Every write needs the record as it was before and as it is after, stored with the actor, a run identifier and a request id. Append only: an edit to the history defeats the point of having one.
Nobody wants to revert 300 individual changes. The unit that matters is the run: everything one agent did for one job. Two ways to get there: group calls that arrive close together automatically, and let the agent name its run so you can find it later. A header pair works well for this:
X-Run-Id: prospecting-2026-10-12
X-Run-Label: Seed-stage dev tools, batch 1
When something goes wrong you search for the label, open the run and see every write in it.
This is the rule that is easiest to skip. The credential that lets an agent write must not be able to revert. If an agent can undo its own work it can also undo the evidence, and "the agent fixed it" is the worst way to learn what the agent did. Reverting should need a person's session, and calling it with an agent key should fail with a clear error.
Between the agent's write and your revert, a person may have fixed the record by hand. Restoring the before-image over their edit trades one mistake for another. A safe revert checks each record: if it changed again after the agent's entry, skip it, and report it with the reason. You finish with "47 reverted, 3 skipped, here is why" instead of a quiet overwrite.
The history has to stay complete: the agent changed it, the operator reverted it, both visible, in order. If a revert erases the original entries, you lose the ability to find out why it happened.
Records, imports and campaign changes can be restored. An email that has already left cannot be recalled. This is why the best undo story for outbound mail is upstream: drafts land in a queue, a person sends them, and a dry run shows what a campaign would send before any real delivery.
On a throwaway workspace: let an agent upsert 20 contacts under a named run, edit two of them by hand, then revert the run. You want to see 18 restored, 2 skipped with a reason, the revert itself in the log under your name, and a refusal when you try the same call with the agent's key.
If your CRM can do all of that, you can leave an agent running. If it cannot, decide what you are willing to lose before you hand it the key.
From Deskhand, by Grain64.