REWIND

Human authority: REWIND pauses the agent’s real tool call until a person approves or denies it.
Before execution: 14 evaluated, 9 allowed, 5 blocked by policy — with zero catalog writes.
Exact recovery: WebMCP revert restores 9/9 prior values while preserving the audit trail.

Inspiration

AI agents are getting better at taking real actions on the web — but most websites still treat an agent action like a normal click.

That becomes risky when the action is consequential.

If an agent changes 50 prices, updates hundreds of records, or triggers a high-impact workflow, the application should be able to answer three questions:

What will change before execution? Who is allowed to authorize it? And can the exact previous state be recovered afterward?

That question led me to build REWIND.

Agent actions should be transactions, not clicks.

What it does

REWIND is a reference implementation of a transaction-safety layer for AI agents using WebMCP.

Instead of exposing raw mutations, REWIND gives an agent a structured lifecycle:

Preview → Guard → Approve when required → Commit → Audit → Revert

Before a write occurs, REWIND computes a deterministic preview showing exactly what would change and what would be blocked.

In the demo, an agent requests a 20% discount across the Summer collection. REWIND evaluates 14 products:

9 satisfy the policy
5 are blocked by the 40% minimum-margin guardrail
0 catalog writes occur during preview

The model does not decide which changes are safe. The application does.

The agent can then commit exactly the valid change set through the WebMCP apply_change_set Site Tool. The resulting transaction is recorded in an audit ledger and attributed to the agent.

Once a revertible transaction exists, REWIND's exposed WebMCP capability surface changes dynamically: revert_change_set becomes available. Invoking it restores the exact retained prior values — demonstrated with 9/9 values restored.

Human authority for consequential actions

REWIND also supports application-owned authorization.

In the demo, the agent proposes a 1% price increase across all 53 active products.

The preview is safe and read-only, but the operation crosses REWIND's approval threshold.

When the agent invokes apply_change_set, REWIND does not immediately execute it.

Instead, the actual tool call is held pending and the application displays:

AGENT REQUESTS APPROVAL

Execution paused — Awaiting human decision

Nothing has been written yet.

The human can inspect the proposed transaction inside REWIND and approve or deny it. In the demo, the operation is denied with a reason, and the pending call resolves with:

NOT COMMITTED — 0 catalog writes

This creates a clear responsibility boundary:

The model proposes. The application enforces. The human authorizes.

How I used WebMCP

WebMCP is not an add-on to REWIND — it is the structured interface through which the agent interacts with the application.

REWIND exposes typed Site Tools for operations such as previewing changes, applying a change set, inspecting transaction state, and reverting committed changes.

The exposed tool surface can also change with application state. Before a revertible transaction exists, REWIND exposes seven tools. After a committed transaction creates a valid recovery path, the application exposes an eighth dynamic tool: revert_change_set.

The responsibility boundary is intentional:

WebMCP provides the structured agent-facing tool surface. REWIND implements the transaction-safety semantics at the application layer.

How I built it

I built REWIND in TypeScript around a deterministic 56-product reference catalog.

The application separates:

WebMCP tool exposure and schemas
deterministic pricing and guardrail logic
preview and change-set generation
application-owned approval state
transaction persistence
lifecycle state
audit ledger
exact inverse-state recovery
UI visualization of agent activity and transaction state

The browser UI and the agent operate against the same application state. This makes it possible to see what the agent requested, what the policy allowed, what actually changed, and who authorized the action.

Challenges I faced

Making an agent change data was not the difficult part.

The difficult part was defining safe boundaries around agent writes.

I had to keep previews non-mutating, make guardrails deterministic instead of delegating safety decisions to the model, distinguish agent-originated actions from direct human page actions, preserve exact prior state for recovery, expose capabilities only when they become valid, and keep consequential tool calls genuinely pending while awaiting a human decision.

Another challenge was making those guarantees visible. I wanted the demo to show the transaction lifecycle directly instead of asking a judge to trust hidden backend logs.

Testing

I tested REWIND at both the logic and browser levels, including the complete live WebMCP flow.

Final verification:

37/37 unit tests passing
25/25 browser/E2E tests passing

The browser tests cover preview without mutation, policy filtering, agent commit, dynamic revert_change_set exposure, exact restoration, pending human approval, denial with zero writes, lifecycle state, and browser-console integrity.

I also tested the deployed Site Tools end-to-end through ChatGPT's in-app browser.

What I learned

Building REWIND changed how I think about agent-enabled websites.

WebMCP becomes especially interesting when a website does more than simply expose actions. The application can expose structured capabilities with domain-specific constraints and state-dependent availability while retaining authority over what those actions actually mean.

For consequential agent workflows, this suggests a useful design pattern:

Preview before mutation.
Enforce policy in the application.
Require human authority when the consequence demands it.
Record what happened.
Retain a deterministic recovery path.

What's next

REWIND currently uses a merchant catalog as a focused reference implementation.

The same transaction lifecycle could be explored in other consequential agent workflows: CRM bulk updates, infrastructure configuration, administrative operations, content publishing, or other systems where an AI agent can modify many records faster than a human can inspect them.

A next step would be adapting the pattern to real application backends and exploring reusable primitives for application-owned agent authorization and recovery.