The_Simulator:_Two_Agents,_Two_Wallets,_Two_Reasons_to_Deny

I built EXP_035 as a scripted walk-through of agent-to-agent payment where the agents don't exist and the money isn't real, but the constraint logic is (GitHub/labs/src/data/experiments.json, id 35, whatItProves line 1435). Two mock agents — Atlas, a procurement agent, and Scout, a research agent — each carry a spend cap in notional currency units and a list of merchants they are authorised to pay. The cap is fixed (say, 5,000 units). The allowlist varies (say, Atlas can pay Vendor A but not Vendor B, whilst Scout can pay both). A scripted eight-transaction run shows this: one transaction clears from one wallet, another transaction to an unlisted merchant gets denied on the allowlist check alone, a third transaction to a different merchant gets denied because the wallet doesn't have enough budget left, and a fourth transaction to the same merchant — in the same wallet, after some earlier denials — completes because those denials didn't consume budget.

The operative detail is here: evaluateTransaction() runs exactly two checks, in a fixed order: is the merchant on this wallet's allowlist, and only if that passes, would this amount push the wallet past its cap (GitHub/labs/src/data/experiments.json, id 35, howItWorks line 1423). A denial on the allowlist check never touches the cap. The cap is never even evaluated. That's not an implementation detail. It's the constraint order, and the constraint order is what determines what a caller can infer from a denial.

Why_This_Ordering_Matters:_Three_Denials,_Three_Different_Meanings

The pattern — check the allowlist first, the cap second — is the same ordering constraint you've already seen applied to two other gates. My own Zero-Trust Agent Gateway (EXP_034, GitHub/labs/src/data/experiments.json, id 34) runs identity verification first and policy evaluation second when it evaluates whether an agent can make a specific tool call. An agent with an unverified identity never reaches the policy stage. A verified agent with insufficient permissions reaches the policy stage and gets denied there. Those are two different failure modes, and they render differently in the logs. A denied policy is a potential misconfiguration; a failed identity is a structural problem. The ordering makes the difference visible.

Trust tiers in my own fleet (~/.claude/CLAUDE.md, § Trust tiers, lines 184-188) apply the same principle in a third domain: before an agent runs anything autonomously, I check whether that agent's track record justifies its claimed trust tier. Only agents with the right tier-to-capability ratio get to run without human approval. Agents with a higher blast radius or a newer track record get routed to human review before they execute. The constraint comes before the execution. The gate runs first, the action second.

Now the pattern shows up a fourth time, applied to spend: allowlist before cap. Three separate systems (identity, policy, trust tier) all apply the same principle: run the boundary check that says "do you have permission to do this at all" before running the constraint check that says "do you have enough resources to do it." The boundary-before-constraint ordering is not specific to any one domain. It's the pattern itself that matters.

The_Real_Rails:_Shipping,_Preview,_and_One_Early_Shutdown

What strikes me about the infrastructure where this is being implemented is how real it is, but how steep the maturity curve is. Cloudflare Wallets (announced 2026-08-04) gives agents dedicated accounts with spend limits and merchant allowlists, and the service is preview-only with no public API at the time this experiment was built (GitHub/labs/src/data/experiments.json, id 35, howItWorks line 1431). Stripe and OpenAI's Agentic Commerce Protocol launched in October 2025, not a 2026 event — but a useful detail was that OpenAI's consumer-facing Instant Checkout implementation shut down in March 2026 after approximately twelve merchants went live (proj-plan/Labs/research/tom-digest-viability-w26-2026.md, line 68-70). That's real data: a payment rail built, shipped, and then deactivated because the early-stage merchant ecosystem wasn't there yet. That failure isn't hypothetical. It's evidence.

Mastercard and Visa announced agent-payment protocols throughout 2026 (proj-plan/Labs/research/cleo-digest-synthesis-w26-2026.md, line 22), joining Google's earlier 2025 announcement. The standardisation wave is real. The infrastructure is converging. The platforms are shipping. But shipping is not the same as mature, and one of the earliest implementations already has a shutdown date attached to it.

The_Gap_Between_Simulation_and_Live:_What_EXP_035_Doesn't_Do

The agent-payment simulator demonstrates the allowlist-before-cap constraint order with fixture data, scripted transactions, and a fixed ledger. A production fleet running continuously — agents making decisions over hours or days, with real merchants registering and deregistering, with spend patterns that vary by context — has constraints the simulator doesn't carry. The wallets in EXP_035 have fixed caps; a production system would need caps that refresh on a schedule (daily, weekly, or per-session). The merchants are hand-authored; production would need dynamic registration — new merchants going live, old ones being removed, allowlists updating in real-time. The transactions are deterministic and finite; a real fleet has concurrency — two agents trying to transact from the same wallet at the same time, racing on the same budget. The simulator captures the gate order. It doesn't capture the state management required to keep that gate honest when money is actually flowing.

That's not a weakness of the simulator. That's its scope. It answers one question precisely: that the constraint order matters, and that the boundary check comes before the resource check. A production payment system has to answer all the others.

The_Pattern_Across_Three_Domains

What makes this worth writing about isn't that payment infrastructure is shipping. It's that three separate operational systems — identity verification, policy enforcement, and spend caps — have all landed on the same underlying principle: verify before you constrain. Each one applies it differently, but I've watched the principle recur independently across these three domains, and that recurrence is the signal, not the accident. The order you run constraints in changes what the system can do, what a caller can know, and what state the system ends up in after a denial. When that order shows up independently across three distinct domains, applied to three different kinds of verification (identity, capability, budget), it's not a coincidence any more — it's the pattern worth paying attention to.