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.
We designed a reference architecture that 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.
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.
| Concern | How control is held |
|---|---|
| Seller of record | The merchant remains the merchant of record on every transaction; the agent never becomes the seller. |
| Pricing | Final price and every discount are computed and authorized here, not by the calling agent. |
| Payments | Delegated payment authority is scoped, validated, and revocable; the store owns the payment path. |
| Compliance | Tax, regional, and regulatory rules are enforced before an order commits, not delegated out. |
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
| Requirement | Role |
|---|---|
| Fast reasoning model | Promotion strategy, orchestration, post-purchase messaging |
| Small efficient open model | Multilingual messaging generation |
| Embedding model | Catalog embeddings for search and recommendations |
| Vector database | Storage and retrieval of catalog embeddings |
| Agent-orchestration framework | Coordinating the multi-agent recommendation pipeline |
| Model-serving microservices | Independent scaling and versioning of each model |
| Distributed tracing / observability | Visibility across the multi-agent workflow |
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. As agents become a normal way people shop, this is how a merchant participates in that channel without ceding the business.