Tuesday

Anna's skincare brand bills $42/month to 12,000 subscribers. When a renewal fails, three AI agents debate retry vs downgrade vs release -- and a real PayPal subscription is updated on their call.

Comment

Inspiration

Tuesday, 3 AM. A $42 skincare renewal fails. The card was declined.

At a subscription brand with 12,000 subscribers, that is not one lost charge -- it is the start of a silent churn. Industry benchmarks put involuntary churn (payments that fail) at 25-40% of all subscription churn in beauty and DTC. The customer never decided to leave. The payment just failed, and nobody noticed.

We kept asking one question: who decides what to do about a failed renewal -- and who can prove the decision was fair?

Today's options are crude. Retry blindly. Or cancel. There is no judgement, and no record of why. For a brand billing real customers, that is the difference between a recovered subscriber and a silent loss.

PayPal's own numbers show why this matters now: branded checkout volume has been stuck at +2% for two straight quarters while Apple Pay, Klarna and Shop Pay close in. The growth PayPal names out loud is agentic commerce -- AI agents that pay on a customer's behalf -- which PayPal projects will reach $1.7 trillion by 2030. And J.P. Morgan notes the volume concentrates in "recurring, low-risk categories such as groceries and subscriptions."

Subscriptions are where agentic commerce arrives first. And the failure path is the hole nobody has filled.

Try it now

Hosted demo: https://tuesday-paypal.onrender.com (free instance -- the first load can take up to a minute while it wakes)

Source: https://github.com/Agentic-Guides/triad

Run it yourself with no configuration at all: npm start then open http://localhost:8787. The deterministic engine, a mock PayPal client and a curated catalogue are the defaults, so the demo works with no API keys. See Run It below for the live sandbox and LLM paths.

What it does

Anna Pays Tuesday puts three independent AI agents on the failed-renewal path, and makes PayPal the place the decision lands.

Agent Model (a different vendor each) Job
Advocate deepseek-v4.1-flash (DeepSeek) Argues to retry -- the subscriber is valuable, the failure looks technical
Auditor gemma4:31b (Google) Opposes only on a concrete, citable risk -- repeated failures, churn pattern, margin loss
Witness gpt-oss:120b (OpenAI OSS) Judges both sides and decides: retry / downgrade / release

Three different vendors on purpose. Three copies of the same model share the same blind spots, which defeats the entire point of an adversarial review.

You choose which product gets bought. The tribunal ranks the whole catalogue and says which candidates it would approve, but the verdict is not the last word: every row in the candidate grid is clickable. Pick one and Tuesday re-rules on that product at its real price -- the same three agents, the same gates, no hidden override. An APPROVED or CONDITIONAL verdict raises the PayPal order for the product you picked. Pick a refused one and no order is created at all.

The renewal moves only on consensus (2-of-3). On dissent, the brand does not get a bare "no" -- it gets a Dissent Map: who blocked what, and why.

The novel part is not the debate -- multi-agent debate already exists. It is what gets stamped onto the money: a consensus receipt (the decision + all three votes + a SHA-256 fingerprint of each agent's reasoning) is hashed and written into the PayPal record's custom_id as triad1:<hash>. The payment record itself becomes the audit trail. Anyone can re-hash the receipt and prove the record was not altered.

And the human still decides. The demo raises an order and stops: capture is a separate, human step. The page says so on screen -- settlement: draft -- a human must approve. We did not work around that -- it is the point. PayPal has built human consent into the payment structure, which is exactly what makes agentic commerce trustworthy.

How we built it

  • Three independent LLMs as the decision layer -- Advocate, Auditor and Witness each run on a different vendor's model, so the disagreement is genuine, not one model talking to itself. (The Auditor model was picked by measurement: 196 tokens / 844 ms per turn versus 365 tokens / 4,466 ms for the alternative.)
  • PayPal Orders v2 REST (paypal/client.js) as the settlement layer: OAuth2 client-credentials token, then POST /v2/checkout/orders with the decision's hash in purchase_units[0].custom_id. No PayPal SDK dependency. PayPal is not decorative -- nothing can be created unless the three agents reach consensus and the money gate allows it.
  • PayPal Subscriptions v1 and the Agent Toolkit (@paypal/mcp) are not implemented here. The settlement path is Orders v2 REST. The Agent Toolkit is the integration point this design moves to in production, and we say so rather than implying it ships.
  • Consensus receipts (src/receipt.js): canonical JSON of the decision and votes, hashed with SHA-256, stamped into custom_id, and independently verifiable.
  • Zero runtime dependencies. The demo runs with no keys at all -- every integration degrades gracefully, so a judge can reproduce the whole thing offline. Be precise about what that means, though: with no keys the three votes come from a deterministic rule engine, not from an LLM, and the engine field on the verdict line reads deterministic. The money gate, the SHA-256 receipts, the ledger, the 4x4 grid and the timeline are our code and behave identically in both modes -- only the source of the three opinions changes. The video was recorded with the live models.

The proof

Every claim above runs against the real thing:

The decision is stamped into the payment. The verdict, the three votes and the model names are canonicalised and SHA-256 hashed; the hash goes into purchase_units[0].custom_id, and is read back with a GET to prove it survived the round trip.

The real PayPal sandbox, through the REST API:

node tests/paypalSandbox.live.mjs
  token OK (app_id=APP-3C860634L8444660B)
  receipt hash: 40afacbb8ff165b6 -> custom_id: triad1:40afacbb8ff165b6
  order OK id=9WF514175M434994P status=CREATED
  round-trip custom_id=triad1:40afacbb8ff165b6 MATCH=true
  ALL LIVE PAYPAL SANDBOX CHECKS PASSED

Three real LLMs, live, with no env overrides:

A budget has room    → APPROVED  3f/0a   A=for  B=for      W=for
B budget nearly full → APPROVED  3f/0a   A=for  B=for      W=for
C over budget        → DENIED    1f/2a   A=for  B=against  W=against

Both paths -- consensus and the money gate -- demonstrably fire against real models.

The money gate, which is the whole point:

node tests/moneyGate.test.js   # asserts createOrder is called 0 times on DENIED/DISSENT

Most "AI spending" demos prove an agent can pay. This one proves it cannot -- unless three independent agents agree, and a human finishes the payment in PayPal.

Sponsor tools

Tool How it is used
PayPal Orders v2 REST (/v1/oauth2/token then /v2/checkout/orders), with the consensus hash carried in custom_id. Live-verified against the sandbox.
AG Grid The decision ledger -- every renewal, every vote, every receipt hash, with a selection-driven receipt panel.
Bryntum Scheduler The renewal timeline -- who decided what, when, and which failed renewals are still unresolved.
Channel3 Product discovery -- grounds the debate in a real, purchasable SKU. Live search through the real API when CHANNEL3_API_KEY is set; a curated 24-product set when it is not.
Render Hosting for this demo. It runs as a Render Web Service built from the repository's Dockerfile, which is also why the container carries a HEALTHCHECK: a free instance sleeps after 15 minutes idle and the first request can take up to a minute to wake it.

What's next

The pattern generalises to any high-stakes agent action: subscription changes, refunds, payouts. Adversarial review + surfaced dissent + a human final call + a tamper-evident record is the shape that makes autonomous money trustworthy -- and it is the layer PayPal's agentic rails will need.

Built With

  • ag-grid
  • agentic-commerce
  • ai-agents
  • bryntum
  • channel3
  • llm
  • multi-agent
  • node.js
  • ollama
  • paypal
  • paypal-orders-v2
  • render
  • sha256
  • tamper-evident
  • webmcp
Share this project:

Updates