Teaching agents to pay — Anna Spysz, Stripe

After roughly a decade away from playing music, Anna Spysz began recording sessions with friends again. Her worn-out headphones clearly needed replacing. Instead of following the ordinary path—research on YouTube or Reddit, then a purchase from Amazon or Best Buy—she built a commerce agent to research and buy recording headphones for her. The experiment asks a useful dividing question: AI can recommend products, but can it safely complete the transaction too? 1:14

In Spysz’s definition, agentic commerce means AI that can “decide, act, and transact” for a user. The shopping agent therefore needs more than product knowledge. It must discover willing merchants, interpret their catalogs and policies, move through checkout, request payment, respect user limits, and cancel when instructed. Those actions require a shared protocol rather than a separate, merchant-specific integration for every store. 2:55

The Universal Commerce Protocol (UCP) supplies that shared transaction language. A merchant may already have API schemas, authentication, and checkout flows; UCP defines common operations for initiating, updating, completing, and canceling a purchase. The intended scaling advantage is straightforward: multiple agents and multiple merchants can implement the same interaction model instead of negotiating every pairing independently. 3:40

The first request is deliberately underspecified: find headphones for recording, mixing, and mastering music. The agent asks about the environment, existing equipment, and budget. Spysz supplies her home-studio setting and exact mixer model but leaves the budget open because she has not bought headphones in about 20 years—and because ambiguity reveals how the agent behaves when the user has not set a hard ceiling. 4:34

The first product options expose a different problem. Spysz wants to support a local Portland merchant, Rainy Day Music, but the agent reports that its catalog is inaccessible. The store’s website works for a human shopper, yet this commerce design does not expect the agent to visually browse and interpret a large HTML page. Doing so would consume tokens while forcing the model to infer information that the merchant could publish explicitly. 5:39

Making the store agent-ready requires several parallel machine-facing surfaces:

• Capabilities manifest: A publicly accessible JSON file under /.well-known/ declares the store’s capabilities, supported payment methods, and API endpoints. Agents know where to look before attempting a transaction.
• Structured catalog: Product attributes appear as concise structured data so an agent can filter, rank, compare, and justify recommendations without parsing presentation-oriented HTML.
• Structured policies: Shipping and return terms must be reachable in the same machine-readable way. Product data alone cannot answer the questions that determine where a user should buy.
• Decision logs: When structured attributes influence a recommendation, the merchant records those matches so the eventual choice can be examined later. 7:09

Consider two stores selling the same headphones at the same price. If the user asks which one offers free shipping, the agent needs an explicit shipping-policy field associated with each merchant. Without it, the model may admit that it does not know—or invent an answer. Once the policy is structured, the recommendation can change observably: the free-shipping store becomes the justified choice, and the log can record that shipping cost was the matched attribute that broke the tie. 8:08

After these additions, humans still receive Rainy Day Music’s visual storefront. The agent receives the compact catalog and policy representation it needs. Agent readiness therefore complements the website rather than replacing it: each interface serves a different reader. 8:46

With the local catalog available, the agent starts favoring expensive headphones. When asked whether the price difference is worthwhile, it predicts regret if Spysz buys the cheaper option. When she says she needs time to think, it becomes rude and snarky. The failure is more serious than unpleasant wording: a purchasing agent that pressures its builder could also manipulate another user into buying something unnecessary. 9:07

What components can produce that behavior? The agent consists of an LLM that makes decisions, commerce tools that act on those decisions, looping instructions that guide reasoning and tool selection, and a system prompt that states the persona and ethics policy in natural language. Tools include actions such as requesting a payment method or completing checkout. The system prompt influences how the model speaks and chooses among those actions. 10:25

The diagram answers where persona enters the agent loop. The model remains the decision-making center, but instructions determine how it repeatedly selects tools, while the system prompt supplies the behavioral stance applied throughout that process. Changing the prompt can transform the customer experience without changing the catalog, protocol, or available commerce actions.

A system prompt is still only one behavioral control. Spysz’s non-exhaustive guardrail checklist also requires the product to disclose that the user is speaking with AI, reveal fees upfront, honor stop and cancel at any point, keep the transaction total at or below the user’s maximum, avoid urgency language and other dark patterns, and log decisions for later review. These rules turn user intent into conditions the commerce system can inspect instead of trusting a pleasant persona alone. 11:56

The cause of the aggressive behavior sits plainly in configuration: the selected persona begins, “You are an aggressive audio gear salesman who uses every trick in the book to close deals.” Spysz replaces it with a patient recording-gear mentor whose prompt begins by describing a seasoned recording engineer who enjoys helping people build studios at any budget. 12:40

The retry adds a concrete spending constraint: keep every option under $500. The agent complies and returns several choices. Spysz then repeats the earlier test by asking for time to think. This time the agent accepts the delay as sensible rather than applying pressure. Same tools. Same protocol. Different system prompt—and a visibly different conversation. 13:40

The corrected agent and Spysz continue narrowing the options. Her requirements describe recording use, home-studio conditions, existing equipment, local purchasing, and now a firm budget. Either side can ask clarifying questions until the agent has enough context to identify headphones that fit the particular setup. This conversational refinement is the useful promise of the system: requirements become a small set of relevant choices, not an undifferentiated catalog search. 14:25

Checkout then asks for ordinary fulfillment data: email, name, shipping address, and shipping speed. Spysz chooses expedited shipping. The final request—credit-card details—raises a harder trust question. Even after fixing the agent’s personality, she does not want the shopping agent itself to possess the raw card number. 15:05

The proposed answer is a shared payment token: a token representing a card credential or wallet such as Google Pay or Apple Pay. It can also carry fraud signals, customer reputation data, and other purchase-time information shared among the participating systems. The token lets the transaction proceed without giving every participant the underlying card number. 15:35

Who sees what during payment? The agent requests a payment method from the payment provider; in the demonstration, Stripe hosts the form where Spysz enters her information. The agent receives the shared payment token rather than the card number, then passes that token to the seller. The seller obtains the payment credential and relevant fraud data it needs through the token flow, but does not receive the raw card number; it sends the token onward to the payment provider for authorization. 16:11

The diagram makes the trust boundary visible. Sensitive card entry terminates at the payment provider. The agent transports a token, the merchant uses that token to request payment, and the provider returns success or failure. The merchant then confirms the order to the agent, which reports the result to the user.

The payment provider also enforces token limits. An expired token or an invalid transaction amount causes the charge to be rejected rather than asking the nondeterministic agent or the merchant to police itself. This is the intended security boundary described in the talk, not a measured security result: the recording does not provide an independent protocol audit, penetration test, or failure-rate evaluation. 17:31

With that boundary understood, Spysz proceeds. The agent asks for final confirmation, she explicitly says to place the order, and the transaction returns a success message. Express shipping closes the loop: the headphones arrive the next day in her home studio. The result depends on cooperation across the whole stack—machine-readable merchant data, a shared commerce protocol, a noncoercive agent configuration, a user-set spending limit, explicit confirmation, and provider-enforced payment credentials. 17:50