Update (Nov 11): Three more changes from your comments, now in the spec:

• Money is capped, per run and per period. Reversible isn't the same as bounded: an agent allowed to make undoable charges could make them forever. A policy can now cap one run (perRun), so the worst case is known before it starts, and all runs over a rolling period (perPeriod). A call that would pass either cap becomes an ask, with the totals shown. Thanks to the per-run cap suggestion in the comments.
• An undo's receipt says what the undo actually did: the version it found, the version it left, and side effects such as a cancellation notice. A partial undo is then its own auditable change set, next to the original run.
• The review shows what is still reversible when you read it, sorted by deadline, with closed windows marked closed. It's a countdown, not a log.

The refund_order example below is now charge_order. On the approval side, HATP 0.2.1 is on npm. It adds deferred votes, which the Journal needs for approvals that come hours later. The Journal itself is planned for v0.3.

Update (Nov 6): Still a draft, and still not built. But your comments have changed it a lot, and every point below is now in the spec:

• Newer edits are safe: every undo carries a version, and if the record changed, the undo stops and only a human can override it. An action with no version can't be undone automatically.
• Undo windows have to outlast review: a policy can set a minimum window (minWindowSeconds), and anything shorter needs approval first. Reminders now cover every open window, and escalate if nobody has looked. Thanks to the Friday question in the comments.
• Dependencies can be declared: tool servers can state what a call relied on (effect.uses), and each link records whether it's declared or a guess.
• Other runs are covered: the Reversal Plan lists who read the changed value since, so the approver knows whom to tell.
• Apps with no API: a computer-use tool can undo through the app's own interface, with a check before and after, and it needs approval by default.
• Authority is rechecked at undo time, not inherited from the original run.

The approval side of HATP also moved on: 0.2.0 is on npm, and the gateway now checks the plan's real totals. The Journal is planned for v0.3.

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 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.

The gap

Idea 1: every effect comes back with its undo

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:

Idea 2: autonomy is granted by reversibility

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.

Undo is a decision, not a button

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:

1. adds dependent steps: if step 5 used step 2's result, undoing 2 alone would leave 5 pointing at nothing;
2. checks each step: asks each tool server, without changing anything, whether undo would work right now;
3. builds a Reversal Plan in reverse order, listing what can't be undone, and routes it to a human through the Human Gateway:

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)

1. runs the compensations in reverse order after approval, and records the outcome. If one fails, it doesn't undo anything that the failed step still depends on, and it reports exactly what was reversed, failed, or skipped.

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.

Never overwrite newer human work

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.

Undo after a transaction commits

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."

What it doesn't do

• Undo reads. A disclosure can't be taken back, so reads that send data outside the organisation are declared irreversible and fall under the autonomy policy.
• Redo. Fixing an undo is a new run.
• Prove the tool server really reversed the effect. Like everything in HATP, signatures prove who claimed what, not that the claim is true.

Status

• Spec draft: spec/hatp-journal.md. It builds only on v0.1 and lists every change it would make to it.
• No code yet. The work is planned in the v0.3 milestone: schema, a Recorder in the SDK, the MCP binding, and a demo where you undo part of an agent's run from the browser approver.
• v0.2 is done and on npm as 0.2.1: pending votes, recovery, locks, and asks outside transactions. The Journal's code starts next, beginning with the Recorder and its own tests.

I'd like feedback on

1. Would you return a compensationToken and undoBy from your MCP server's tools? What would make that hard?
2. Reversal skips prepare. To keep undo cheap to adopt, tool servers get an optional check instead of the full two-phase flow; only the human votes. Is that too weak?
3. Dependencies. Agent hosts rarely know which earlier result a call used. Today the draft assumes "depends on everything earlier", which is safe but makes "undo just this step" pull in too much. Should the Recorder infer links from matching argument values?
4. Reversibility-gated autonomy: is "act freely on what can be undone, ask before what can't" the right default, or too permissive?
5. Long undo windows: if Dana changes roles before the window closes, should her authority be checked again at undo time?

Spec and SDK: https://github.com/probita-ai/hatp. Comments here or issues on GitHub are both welcome.