ProofDone

Approve exact effects and verify the customer outcome before an AI agent says done.

Comment

Inspiration

When I built the first ProofDone prototype during this challenge, cancellation looked like a simple agent action: call the right tool and report success.

But the more I followed the intended outcome across store, fulfillment, shipment, and payment state, the less honest that became. A cancellation flow could partly succeed while the customer’s payment remained captured.

That led to the question behind ProofDone:

When has an agent actually earned the right to say “done”?

WebMCP gives websites a structured way to work with agents. ProofDone explores what must happen around and after the tool call so that an approved action becomes a verified customer outcome.

What it does

The public demo is a normal commerce storefront with an agent-assisted order. The user gives only the goal:

Cancel order G1-ORDER-1001.

ProofDone exposes the current order truth and the currently valid resolution through WebMCP. From those structured capabilities, the agent determines that the valid cancellation also includes stopping fulfillment, preventing shipment, and refunding the captured payment.

Before anything changes, the website presents the exact projected effects. The human approves those effects on the page. Approval intentionally belongs to the website, not to an agent tool.

After approval, the agent can commit the resolution. But ProofDone does not treat a successful commit as customer completion. A separate fresh verification read checks the resulting state before the interface can show OUTCOME VERIFIED.

That distinction also makes failure cases explicit:

  • If material state changes after approval, the resolution becomes STALE_RESOLUTION and the commit performs zero business writes.
  • In a controlled partial execution, all three operations are attempted, but only fulfillment and shop cancellation change state. The refund does not. ProofDone reports PARTIAL_OUTCOME, keeps the captured payment visible, and requires human follow-up instead of reporting success.
  • Replaying the same completed request does not create a second mutation.

Why WebMCP is a strong fit

Without a structured website contract, the user or agent has to reconstruct business rules from UI state and page controls. In ProofDone, the user states the goal while the website supplies the current constraints, valid resolution, projected effects, commit result, and verification result.

This creates a clearer division of responsibility:

  • the human states intent and approves exact effects;
  • the website owns current business state, allowed resolutions, approval validity, writes, and verification;
  • the agent discovers and explains the correct action path through WebMCP.

The result is a better user experience because the customer does not need to know the internal sequence of commerce operations, while the agent still cannot silently broaden an old approval or declare success after only part of the intended outcome occurred.

WebMCP implementation

ProofDone registers exactly five native WebMCP tools:

  • get_order_truth
  • get_order_resolution_options
  • preview_order_resolution
  • commit_order_resolution
  • verify_order_resolution

Together they implement:

Observe → Preview → Approve → Commit → Verify

There is intentionally no approval tool. Exact-effect approval is page-owned.

The product page and WebMCP tools use the same ProofDone state. A preview is bound to the material state and exact projected effects. A stale preview is rejected before business writes. Commit and verification are separate claims, and duplicate replay is idempotent.

The public judge path runs in a deterministic mode so judges do not need provider credentials or an account.

Real-provider validation

The deterministic demo proved the lifecycle in a controlled environment, but I did not want to stop there. I wanted to see whether the same observation boundary still made sense when real commerce providers exposed different parts of the state.

The same codebase therefore read a Shopify Development Store order and a ShipBob Sandbox shipment without performing provider business writes.

Shopify could report that the order was unfulfilled, but that alone was not enough to prove what had physically happened inside the warehouse. I treated the ShipBob evidence conservatively for the same reason: when no physical Picked milestone was visible, ProofDone did not invent one.

In a separate drift test, ProofDone first observed the same ShipBob shipment when the API contained no Picked milestone. ShipBob’s own Sandbox Simulation Terminal then advanced the shipment. A fresh ProofDone read observed Picked / 100 and a changed material observation digest.

The public judge path remains deterministic so anyone can reproduce it without provider credentials. The Shopify and ShipBob integrations are read-only validation paths, not production transaction writes.

Execution and testing

The current project has 390 logical tests covering the resolution lifecycle, including stale approval rejection, exact-effect approval, idempotent replay, separate verification, controlled partial execution, shared UI/WebMCP state, and provider read-only boundaries.

The live public flow was tested with ChatGPT’s in-app browser and Google Chrome 152 with WebMCP testing enabled.

What was difficult and what I learned

Connecting the commerce APIs took work, but it was not the hardest part. The harder problem was deciding when the software had enough evidence to let an agent say “done.”

One bug made that distinction concrete. After a partial execution, a duplicate retry correctly performed zero additional writes. But the interface then used the retry response—with its per-call zero counters—in place of the original execution evidence. The business behavior was safe, but the evidence shown to the user was misleading.

Fixing it required preserving the original execution result separately from later attempts.

The central lesson became:

COMMITTED != VERIFIED

Approval, execution, and verified customer outcome are three different claims. Separating them made stale-state rejection, idempotent replay, partial outcomes, and the final verification receipt easier to reason about and test.

What’s next

The next step after the challenge would be to turn the resolution lifecycle into a more reusable integration pattern and, only with explicit provider authorization and stronger production controls, connect controlled write adapters to real commerce systems.

Built With

  • next.js
  • node.js
  • react
  • shipbob-sandbox
  • shopify-admin-graphql-api
  • shopify-hydrogen
  • shopify-storefront-api
  • typescript
  • vercel
  • vercel-shop
  • webmcp
Share this project:

Updates

Submission history