# Undo for AI agents: a draft spec for taking back what an agent already did

> Source: <https://dev.to/murthyg/undo-for-ai-agents-a-draft-spec-for-taking-back-what-an-agent-already-did-41e0>
> Published: 2026-11-01 01:50:16+00:00

A sales agent is tidying up the Q4 pipeline. It marks deal D-881 as Won in the CRM, books a kickoff meeting with the customer, and emails their buyer a welcome note. An hour later you notice it picked the wrong deal. The customer hasn't signed.

To clean up, you open three systems, work out what changed, put back the deal stage (unless a colleague has edited it since), cancel the meeting (which tells the attendees), and accept that the email has gone.

In [my last post](https://dev.to/murthyg/human-approval-as-a-2pc-vote-a-draft-protocol-for-safe-multi-tool-agent-actions-1j05) I described **HATP**, a draft protocol that makes multi-step agent actions all-or-nothing *before* they happen: plan, prepare, get a human's signed approval, then commit. Your comments on that post shaped most of v0.2, so thank you.

But most agents don't plan. They call one tool at a time, and you find out afterwards. So for v0.3 I've drafted the other half: **the Journal**, undo for agents. Nothing is built yet. I'd like your opinion before we start.

| What exists | What it does | What's missing | 
|---|---|---|
| MCP tool annotations ( `destructiveHint` ,`idempotentHint` ) | Tell the client a tool might be dangerous | Hints only: no way to reverse anything | 
| Sagas and compensating transactions | Undo steps inside one application | Nothing that works across independent tool servers an agent calls | 
| HATP v0.1 `compensate` tier | Undoes steps when a transaction fails partway | Only inside a planned transaction, and only before it succeeds | 
| Agent traces and logs | Show what happened | Can't take anything back | 

A **Recorder** sits between the agent and its tool servers, usually an MCP gateway. The agent needs no changes. When a tool server supports the journal, its normal tool result carries three extra things: what changed, a token to reverse it, and how long reversal stays possible.

```
"_meta": { "hatp/journal": {
  "undo": { "kind": "compensate", "undoBy": "2026-11-07T14:02:10Z" },
  "compensationToken": "ctk_9QwX…",
  "effect": { "summary": "Deal D-881 stage: Proposal → Won",
              "resource": "crm://acme/deal/D-881", "version": "v13" },
  "receipt": { "…": "signed by the CRM" } } }
```

The tool server writes the summary from the actual change, not from the agent's text, because a human reads it later when deciding what to undo. The Recorder chains every entry into a signed, hash-chained **Run Record**.

Tool servers that know nothing about HATP still get journaled. Their calls are recorded as `unknown` and treated as irreversible. So it works with any MCP server on day one, and gets better as servers add undo.

Each operation declares up front whether it can be undone:

| Operation | Declares | Why | 
|---|---|---|
| `update_deal` | `compensate` , 7 days | Old stage can be restored | 
| `create_event` | `compensate` , 30 days, side effect: "attendees get a cancellation notice" | Undo is possible but visible | 
| `refund_order` | `compensate` , 1 day, cost $2.50 | Undo has a fee | 
| `send_email` | `none` : "delivered to external recipients" | Can't unsend | 
| `export_report` | `none` : "discloses data outside the organisation" | A read you can't take back | 

Once every operation says whether it can be undone, you can stop asking "should this agent be allowed to act?" and ask "can we take it back if it's wrong?"

```
{ "autonomy": { "compensate": "allow", "unknown": "ask", "none": "ask",
                "approver": "human://acme.com/role/team-lead" } }
```

The agent acts freely on anything reversible. Before anything irreversible, the Recorder doesn't forward the call: it runs it as a normal HATP transaction with a human approval, so the email goes out only after someone signs off. Your organisation sets this policy, not the agent, and the agent can't change it.

Reversing work can destroy someone's newer edits or notify people outside the company, so a reversal goes through approval like any other risky action.

You ask to undo the run "from step 2 onwards". The Recorder then:

```
Undo 2 actions by sales-bot for Dana:
  1. Cancel "Kickoff with Globex" on Nov 4   (attendees get a cancellation notice)
  2. Deal D-881 stage: Won → Proposal
Cannot be undone:
  - Email to buyer@globex.com   (delivered to external recipients)
```

For what can't be undone, it suggests a remedy, such as "send a correction email", but never performs it. A corrective action is a new action and needs fresh consent.

Between the agent's change and your undo, Eve may have moved the deal to "Negotiation". Blindly restoring "Proposal" would wipe out her change.

So every compensation carries `ifVersion`: the version the agent left behind (` v13`). If the record has changed since, the tool server refuses with `UNDO_CONFLICT` and says what changed. The approval screen then shows the conflict, and only a human can choose to overwrite it.

HATP v0.1 compensates only when a transaction fails partway. With the Journal, a coordinator records a committed transaction as a run, so the same tokens can reverse it later: "that trip committed fine, but it was the wrong week."

`compensationToken` and `undoBy` from your MCP server's tools?`prepare`.` check` instead of the full two-phase flow; only the human votes. Is that too weak?
Spec and SDK: [https://github.com/probita-ai/hatp](https://github.com/probita-ai/hatp). Comments here or issues on GitHub are both welcome.