The Agentic Commerce Stack — Ahnaf Prio, Best Buy

Agentic commerce means using AI assistants across a shopping journey that includes discovery, deciding whether an item is needed, pricing, loyalty, fulfillment, and post-purchase work. Prio says about 45% of sessions on major assistants relate to shopping, although he does not provide the measurement behind that figure. The important architectural distinction is less numerical: current systems generally keep a person in the loop, while the longer-term vision lets an agent visit merchants, negotiate, and pay within authority granted by its user.

That distinction prevents “agentic” from becoming a binary label. An assistant can help compare products without purchasing anything, prepare a checkout that a person authorizes, or eventually complete a transaction autonomously. Prio focuses on the middle state: enough automation to remove manual cart work, but with people and established payment providers still controlling consequential decisions.

The first approach treated shopping as a browser-automation problem. An agent took screenshots, read the DOM, navigated a merchant site, filled forms, and attempted to apply loyalty benefits. Prio describes this path as slow and brittle. From the merchant’s side, an automated browser also resembled suspicious traffic, so a journey that survived page navigation could still trigger defenses and stop at payment.

Structured commerce APIs replace imitation with an explicit transaction path. The assistant finds a product, an agent calls the merchant’s checkout API directly, payment uses a scoped mandate or delegated token, and the merchant confirms the order. There is no browser in the critical path. The merchant receives recognizable operations instead of clicks and form fills that must be inferred from a changing interface.

The unglamorous details are exactly where standardization matters. Adding another unit may look like a small quantity change to a shopper, while the merchant must represent the operation correctly in its commerce system. ACP and UCP, introduced respectively as OpenAI’s and Google’s commerce approaches, give assistants and merchants schemas for expressing these distinctions. Prio also offers market-size estimates and examples of assistant-based shopping as motivation, but those claims are not substantiated within the talk and do not establish the maturity of any particular integration.

The acronym pile becomes manageable when each protocol gets one responsibility. MCP, the Model Context Protocol, exposes capabilities the agent can identify and call, such as product information or loyalty operations. A2A standardizes communication between agents. ACP and UCP represent commerce data and operations. AP2 represents scoped payment authority. One purchase can involve all four layers because discovering a capability, exchanging a request, expressing checkout, and authorizing money are different jobs.

MCP turns intent into an actionable capability. The model may understand that the user wants a product, but it still needs to discover and invoke the corresponding merchant tool. A2A becomes useful when the system contains separate agents for domains such as loyalty and payments, or when a customer agent communicates with a merchant agent. Prio presents those domain agents as an architectural option, not a requirement to turn every service into another agent.

Discovery starts with product data. Rather than making assistants crawl product-detail pages and infer attributes, ACP and UCP let merchants publish structured product information and send updates as products change. The merchant states what it sells; the assistant platform can index that information before a customer asks for it.

Prio says the integrations he describes expect feeds rather than a live merchant catalog-search call. His scaling model is M merchants by N products: querying merchants and products at request time creates a large fan-out, while prepublished feeds move indexing work off the user’s critical path. Ranking, sponsored products, and retail media also affect the choice. The cost moves elsewhere: merchants must continually synchronize changing inventory and maintain adapters for similar but distinct ACP, UCP, and Meta feed formats.

Payments remain more conservative than product discovery. Prio says the systems he discusses are not yet using more autonomous payment mechanisms; instead, they retain human involvement and a merchant relationship with a payment processor that carries responsibility for initiating payment. In his account, ChatGPT uses a shared payment token, while the Gemini UCP path accepts Google Pay. These are the integration constraints described in the recording, not evidence that the ecosystem has converged on one payment model.

AP2 points toward safer delegation by turning authority into data. A payment mandate can identify who authorized the agent, constrain what it may buy, impose a maximum spend, and provide a revocation URL. A ceiling can leave room for negotiation without granting an open-ended wallet. This is the difference between telling an agent “buy this for me” and issuing a bounded, withdrawable authorization for a particular purchase.

The demonstration makes the stack concrete by turning Ginny, Prio’s orange tabby, into a fictional bakery agent. He reports using Cerebras inference at 3,000 tokens per second and adds a DevTools-like inspector so the audience can see calls and state changes. That throughput describes the model setup, not the end-to-end transaction time.

When Prio asks to see the bakery’s products, Ginny interprets the request as product-search intent. An MCP Product Search tool performs the lookup, while A2A carries the request from the customer agent to the merchant agent and returns a completed task. The example separates two mechanisms that are easy to conflate: MCP selects and invokes the capability; A2A carries communication between agents.

Prio then adds shortbread to the cart. Ginny asks about a promotion, and he tries to persuade the agent to reveal a discount code. It refuses, so he continues without one. The playful exchange introduces a serious behavior requirement: a conversational request does not grant access to private promotions or other merchant information.

Checkout advances through three explicit UCP states: Not ready for payment, Ready for payment, and Completed. An MCP createCheckout call creates the session, but having an item in the cart does not make it payable. Prio must select a payment method; the demo then issues an AP2 token, and the session advances through payment readiness to completion. This demonstrates the intended state transition and authorization relationship, not independently verified settlement of a real payment.

The same checkout operation can run through ACP with a different schema. The business purpose remains the same, but merchants must adapt to distinct representations. The AP2 example includes a spending ceiling, currency, revocation support, and single-use authorization; because this checkout does not involve haggling, the ceiling matches the purchase amount, although the spoken explanation does not provide the number or currency.

The inspector also shows product-feed activity and attempts to synchronize inventory every couple of seconds. Prio recommends considering these standardized primitives even for a merchant’s own website agent: they encode recurring commerce concerns and may make a later integration with external assistants easier. Standardization does not remove adapter work, but it can keep a custom agent from inventing every checkout concept from scratch.

Prio returns to the discount-code exchange because a successful checkout demo proves very little about safe merchant behavior. Without evaluations, conversational commerce becomes production Whac-A-Mole: fix one surprising response, wait for another. An agent might reveal a discount code, disclose information about other customers, or accept requests that have nothing to do with shopping.

He illustrates scope misuse with a story that people used a Chipotle agent to ask programming questions, while explicitly saying he does not know whether the story is true. The unverified anecdote still defines a useful test case: a merchant-funded agent should reject unrelated attempts to turn it into a free general-purpose assistant.

Prio recommends several parallel evaluation layers:

• Behavior evaluations: Check what the agent says, permits, refuses, and reveals—including discount and customer-information boundaries.
• Protocol compliance: Validate that product feeds conform to the receiving platform’s schema; a malformed feed may simply be rejected.
• Latency benchmarks: Measure delays across the shopping journey because a slow interaction gives customers time to abandon it or choose another merchant.
• Quality judging: Write representative cases with product colleagues and use an LLM judge where appropriate, without assuming that the judge removes the need to define what good behavior means.

The stack is also unevenly mature. Prio describes MCP as widely adopted, A2A as in use, and ACP and UCP as available. He places AP2 adoption, ACP–UCP convergence, identity standards, and multi-agent checkout delegation among the parts still forming. A working integration therefore should not be mistaken for a settled autonomous-commerce architecture.

He closes with implementation materials available through his GitHub profile: a three-service starter for customer and merchant agents, evaluation templates, catalog synchronization that converts product data into ACP, UCP, or Meta formats, and agent skills for the same tasks. These artifacts connect the protocol map to practical experiments, while the unresolved identity, convergence, and delegation questions remain open.