Last month, I spent three days debugging why a payment confirmation email went to the wrong customer. Not the wrong inbox, the completely wrong person. The order was placed correctly. The payment went through correctly. But somewhere in the state transitions between "payment approved" and "fulfillment started," a reference got mixed up, and suddenly someone's order details were visible to a stranger. It wasn't a security breach in the traditional sense. It was something worse: the system had no way to prove what actually happened, or who made what decision.
That incident haunted me while reading about WebAZ's approach to AI-driven commerce. Everyone's obsessing over the fun part, agents that browse catalogs and recommend products. But I've learned the hard way that commerce isn't about recommendations. It's about accountability.
The Fantasy vs. The Reality of Agent Shopping
Let me be honest: most AI shopping agent demos are theater. They show an agent finding a product, clicking "buy," and the demo ends. The crowd applauds. In reality, that's where the actual work starts.
When a real order exists, you need to answer questions that no one wants to answer during a presentation. Who approved this charge? Which seller are we actually working with? If the product arrives broken, what evidence proves what was supposed to arrive? What if the buyer disputes the charge three months later? What if the agent made the purchase at 2 AM when the buyer's inventory was depleted and prices fluctuated? These aren't edge cases, they're the core of commerce.
WebAZ takes this seriously in a way that feels refreshingly unglamorous. They're building explicit state transitions for the parts of commerce that actually matter in production. Not recommendation algorithms. State machines.
Two Settlement Approaches for Different Trust Models
The protocol implements two real payment rails, and I appreciate that they didn't pretend both are equally safe.
Direct pay is straightforward: buyer pays seller directly, off-platform. WebAZ records the snapshot, the state of the order, risk acknowledgements, what variant and inventory level was accepted. But WebAZ doesn't custody the money. This is honest. It's useful for sellers who already have payment infrastructure they trust, and it reduces the surface area of what could go wrong in the protocol itself.
USDC escrow on Base is the more interesting approach for agents. Real stablecoins locked in an immutable contract. The contract explicitly constrains where funds can exit: back to the buyer, to the voucher-bound seller, or to a fee sink. No arbitrary redirects. The team is transparent that this hasn't had a third-party audit, but they're not hiding that fact, they've just kept the contract surface small and added safeguards like hard transaction caps.
What strikes me is the honesty about risk. They're not claiming this is bulletproof. They're saying: "Here's what we control, here's what we don't, and here's what we're doing about it."
The Unsexy Stuff That Actually Matters
After discussing payment, the article digs into something that kills me, because it's so obvious once you think about it, but nobody builds it until production breaks.
Product variants. Inventory snapshots at purchase time. Return addresses that don't change retroactively when a seller updates their store. Price ranges displayed before selection. The ability to disable out-of-stock options.
These aren't features. They're state preservation mechanisms. They're the difference between "we have a record of what happened" and "we have a guess about what happened."
I've shipped systems where sellers could edit their store while orders were pending, and it created refund disputes that were impossible to resolve because nobody had captured the state at the moment the order was placed. WebAZ captures it explicitly.
My Take: Protocol-First Commerce Makes Sense
I'm convinced that agent-native commerce needs to be protocol-first, not platform-first. Platforms centralize authority and custody, which creates liability and a single point of failure. Protocols distribute authority and make decisions inspectable.
That said, I have questions. The MCP endpoint for agents is read-only for discovery and authenticated for writes. How does passkey approval work in practice when an agent needs to execute a purchase at 3 AM? Do you prompt the user? Do you require confirmation? The article doesn't dig into the UX of human oversight at scale.
Also, I'd want to see how fulfillment evidence is actually captured and stored. The article mentions it as important but doesn't explain the mechanism. Is that in a future release?
What Would I Build Differently?
If I were implementing this in a real business, I'd add observability earlier. The shadow RPC observer mentioned, that's good practice, but I'd probably want structured logging of every state transition before touching on-chain rails. Make it easy to debug locally before risking real money.
I'd also be very cautious about the passkey approval boundary. Security theater is worse than no security, and passkeys aren't foolproof. But that's a UX problem, not a protocol problem.
The Question That Matters
Commerce isn't about shopping bots finding products. It's about systems that prove what happened and who agreed to it. WebAZ is building for that. I think more teams should.
What's the hardest part of post-purchase state in your systems? Is it approval, settlement, evidence capture, or returns?
Source: This post was inspired by "AI Agents Can Find Products. The Hard Part Starts After "Buy."" by Dev.to. Read the original article
