EXPERIMENT_035 // AGENT-TO-AGENT.MICRO-PAYMENT.SIMULATOR
Two mock agent wallets, Atlas and Scout, transact against their own spend caps and merchant allowlists while a scripted eight-transaction run shows the ledger allow one payment, deny another for an unlisted merchant, and deny a third for an exhausted cap, each with its running balance.
LOADING EXPERIMENT...
Two mock agent wallets, Atlas (a procurement agent) and Scout (a research agent), each carry their own spend cap and their own list of merchants they are allowed to pay. Click Run and eight scripted transactions post one at a time: a payment that clears with room to spare, a payment to a merchant that was never added to the wallet's allowlist, and a payment that would push a wallet past its cap even though the merchant is approved. Each decision shows its reason and the wallet's running balance updates live, so cap exhaustion and allowlist rejection read as two distinct failure modes rather than one generic "denied".
HOW IT WORKS
Atlas and Scout are hand-authored mock wallets, not real accounts: each has its own fixed spend cap (in minor units, to avoid floating-point arithmetic on money) and its own list of merchant ids it is permitted to pay. The same merchant can be on one wallet's allowlist and absent from the other's, which is what lets the eight-transaction scenario show the identical merchant produce a different outcome depending on which wallet is paying.
evaluateTransaction() runs two checks in a fixed order for every transaction: is the merchant on this wallet's allowlist, and only if that passes, would this amount push the wallet's running spend past its cap. A transaction to an unlisted merchant is denied on the allowlist check alone — the cap is never even read — the same short-circuit shape as EXP_034's identity-before-policy gateway, applied to money instead of tool calls.
runLedger() carries each wallet's running spend total forward across the scripted run in order. When a transaction is denied — for either reason — the wallet's spent total does not move. The scenario's eighth transaction posts against Atlas after two earlier denials specifically to make this visible: the wallet still has exactly the headroom it would have had if those two denied attempts had never been made.
No real wallet, stablecoin, or payment rail exists anywhere in this build. Cloudflare announced Wallets — stablecoin wallets for agents with spend caps and merchant allowlists — on 2026-08-04, but the capability was preview-only with no public API when this was built (see the disclaimer at the top of the canvas). The eight transactions, both wallets, and every merchant are fixture data; runLedger() is deterministic — the same scripted run produces the same eight decisions every time.
WHAT THIS PROVES
Spend-cap and merchant-allowlist enforcement is two separate checks with two separate failure modes, not one generic "payment blocked" state — and the order they run in changes what a caller can infer from a denial. Making that short-circuit (allowlist before cap, cap never checked once allowlist fails) something a visitor can click through turns a preview-stage infrastructure signal (Cloudflare Wallets) into an operational question this Labs experiment can already answer, ahead of the real API existing.
It's the same verify-then-decide shape as EXP_034's Zero-Trust Agent Gateway (identity before policy) and Diana's own fleet trust tiers (~/.claude/CLAUDE.md § Trust tiers), applied to a third domain: money. Three experiments now demonstrate that one architectural pattern — a hard, order-dependent gate before the expensive or consequential check runs — recurs across identity, tool-call policy, and spend, rather than being specific to any one of them.