Agentic commerce: a reference architecture for AI checkout under merchant control

This paper reads NVIDIA's Retail Agentic Commerce blueprint. The reference architecture is NVIDIA's work. What is ours is the engineering commentary: how the pieces fit, what they cost, where the design holds and where we would do it differently. Nothing here is a system we built or operate.

1. The problem

Today's e-commerce infrastructure was built for a human at a browser. Sessions, cookies, carts, and checkout pages all assume a person clicking through a funnel. A new class of buyer breaks that assumption: an AI agent shopping on a customer's behalf, expected to find the right product, apply the right promotion, and complete a payment end to end.

There is no standard way for that agent to work with a store. It cannot ask a merchant what it is capable of, it cannot negotiate checkout terms, and it has no safe channel to pay. Each agent platform ends up wired to each merchant through a bespoke integration. Those integrations are fragile, they break on every store change, and they do not scale across a catalog of thousands of merchants.

The merchant carries the larger risk. Handing shopping decisions to a third-party agent can mean handing over the business logic that defines the store: dynamic pricing, inventory rules, tax and regulatory compliance, who is legally the seller on record. A retailer that gives that up to run in someone else's agent has lost control of its own commerce.

The blueprint resolves both sides at once: agents transact end to end, and the merchant stays in authority over price, payment, and compliance. The focus here is the architecture and its boundaries, not any specific model or vendor.

2. The protocol layer

The protocol layer is the contract between an outside agent and the store. One interface serves every agent, so a merchant integrates once rather than once per platform. We build it on a standardized agent-to-merchant protocol layer (a role now being filled by emerging open protocols for agent discovery, checkout, and delegated payments) rather than a private API. Supporting more than one such protocol is deliberate: it keeps the store reachable as the ecosystem settles.

It covers four exchanges.

• Discovery. An agent asks the store what it offers and how to transact with it (available capabilities, catalog access, checkout terms) instead of scraping a page built for a human.
• Checkout. The agent constructs a cart and completes an order through a defined handshake. The store validates every step against its own rules before it commits.
• Delegated payments. The agent pays on the customer's behalf through a scoped, auditable authorization. The store never surrenders control of how a payment is taken.
• Order lifecycle. After the sale, webhook events push order state (confirmed, shipped, delivered, refunded) back to the agent, so post-purchase updates flow without the agent polling or holding a session open.

3. The intelligence layer

Behind the protocol, the store runs its own agents. These make the shopping experience good; the protocol only makes it reachable.

3.1 Promotion strategy

A fast reasoning model selects the promotion to offer against real-time signals: competitive pricing, inventory pressure, margin targets. The offer is proposed here and priced by the merchant control layer, so a discount is a business decision the store makes, never one the external agent invents.

3.2 Semantic product search

Natural-language queries resolve through an embedding model and a vector database over the catalog. Products are embedded once; a query is embedded at request time and matched by meaning, so "a warm jacket for winter hiking" returns the right items without depending on exact keywords. The same embedding-based retrieval powers our multimodal shopping assistant, which extends it to image search and multi-turn discovery for human shoppers.

3.3 Agentic recommendations

Cross-sell runs through an agentic-RAG pipeline: an agent-orchestration framework coordinates several specialized agents that retrieve, filter, and rank candidates against the customer's context. The result is a personalized set of suggestions with a traceable reason for each, rather than a generic "customers also bought" list.

A small efficient open model also generates post-purchase messaging (shipping and delivery updates) in the store's configured brand tone and language, including across multiple languages.

4. Merchant control

This layer is the reason the architecture is safe to deploy. It is the boundary that outside agents cannot cross.

The store's own experience is delivered through an embedded, merchant-owned widget for cart, checkout, and recommendations: the same intelligence, surfaced under the retailer's brand for human shoppers too.

5. Serving and observability

The models run as independent model-serving microservices, so promotion reasoning, embedding, and messaging scale and version separately. Distributed tracing and observability span the full multi-agent workflow: every agent step, protocol exchange, and checkout decision is traceable end to end. When an agent applies a promotion or completes a purchase, the reasoning behind it is inspectable rather than opaque, which is what makes the system auditable enough to trust with money.

6. Key capabilities

• A standardized protocol interface for agent discovery, checkout, delegated payments, and webhook-driven order lifecycle: integrate once, serve every agent.
• Intelligent promotions selected against live competitive and inventory signals, and priced under merchant authority.
• Semantic product search over an embedding model and vector database for natural-language discovery.
• Agentic cross-sell through a multi-agent RAG pipeline with per-suggestion reasons.
• Multilingual post-purchase messaging in the store's own brand tone and languages.
• An embedded merchant-owned widget for cart, checkout, and recommendations.
• End-to-end tracing across every agent and protocol step.

7. Requirements

8. Where this applies

Any retailer that expects agent-driven traffic can adopt this without rebuilding its store. The protocol layer makes the catalog reachable to agents; the control layer keeps pricing, payments, and compliance where they belong. A catalog only becomes reachable once it is rich enough to be discovered, which is where automated catalog enrichment fits ahead of this layer. As agents become a normal way people shop, this is how a merchant participates in that channel without ceding the business.

9. Sources

The architecture described above is NVIDIA's, published as an AI Blueprint. We have not built or operated this system; we have read the design and written about it. Where a figure or a design decision appears above without another citation, it comes from the blueprint.

1. NVIDIA, Retail Agentic Commerce blueprint, from the NVIDIA AI Blueprints catalogue.

2. Our own MCP, A2A, ACP, AP2: the agent protocol stack, which covers the protocol layer this architecture depends on.

3. Our own catalog enrichment, the stage that has to come before a catalog is reachable by an agent at all.

4. The Agent Payments Protocol (AP2) and the Model Context Protocol specification, the two layers an agent actually transacts over.

This note sits in our Engineering track, alongside the commerce and agentic threads. The full library is at Research.