BakedBot AI

ClearCart Protocol is an agent-to-agent commerce protocol with a compliance gate built in. The demo runs against a real merchant: Lakeshore Cannabis Club, Romeoville IL, on its live published catalog. Problem: AI agents can discover products, recommend purchases and build carts. But completing an age-restricted transaction requires a different level of trust. A merchant must establish that the buyer is eligible, apply the relevant jurisdictional rules and preserve evidence of the decision before payment. Solution: ClearCart has two components. ClearCart Protocol is a documented agent-to-agent shopping and checkout flow covering menu discovery, product questions, quotes, orders and payment handoff. ClearCart Gate is an independently callable HTTP rules service. The gate does not take the caller's word for anything. A check request carries only a buyer attestation ID and cart SKUs. The gate resolves the attestation from its own trusted store, reads purchase history from its own ledger (an approval reserves its totals immediately, so concurrent carts cannot both pass a limit), and resolves product attributes from the merchant catalog it holds. It returns APPROVE, DENY or REVIEW with structured reason codes and a signed decision receipt. The receipt is cryptographically bound and single-use. Its HMAC-SHA256 signature covers the merchant, the decision ID, the decision, a SHA-256 hash of the catalog-resolved cart, the policy ID, and the issue and expiry times. The payment rail verifies all of it before opening a session and consumes the decision ID, so a forged, altered, expired, denied, or replayed authorization cannot create a payment session. How it works: a buyer agent discovers a merchant agent, reads its live menu, asks product questions, builds a cart and receives a quote. Before payment, the merchant agent calls POST /v1/gate/check; only a valid, unconsumed APPROVE receipt creates a payment session; the buyer approves on a compliant rail handoff, a webhook confirms, and the merchant issues a pickup code. The buyer is a fictional persona, policies are simulated (labeled SIMULATED_POLICY_V1), transactions are simulated, and a payment stub enforces the receipt rules. It demonstrates the authorization architecture without processing real transactions.