Amazon Buy for Me and the Transition to Agentic Commerce

Agentic commerce is shopping in which an AI agent searches, compares and buys on a person's behalf, instead of the person browsing pages and filling in checkout forms. Amazon Buy for Me is one early example of the pattern, and open protocols such as Google's Universal Commerce Protocol (UCP) and the Model Context Protocol (MCP) are another. This article explains how agentic purchasing differs from human browsing, what makes a merchant easy or hard for an agent to transact with, how agents may rank candidate merchants, and which standards and markup make a catalog readable by machines.

The protocols in this area are young and change quickly. Treat the pipeline below as a reference design for how such systems fit together, and check each vendor's own documentation, listed in the references, for the current details.

How Agentic Commerce Replaces Page Scraping with Protocol Handshakes

In a traditional e-commerce flow, a person reads a results page, opens a product page and works through a checkout form. An agent that has to do the same through the browser must parse unstable client-side page structure. That approach is brittle: selector paths break when a page changes, asynchronous rendering delays the content the agent needs, and a checkout that was built for a human can fail an automated session.

Agentic commerce changes the interface. Discovery moves to retrieval over dense embedding indices, and the transaction itself moves to machine-readable contracts. Under emerging protocols such as UCP and MCP, an agent queries a merchant's catalog, evaluates offers and commits a purchase through an API instead of through the rendered page.

Two broad architectures are emerging.

• A vertically integrated intermediary. Amazon Buy for Me is described as a proxy layer that captures the shopper's journey context and hands fulfilment to the merchant of record, using browser automation on the merchant's side. The platform controls the experience, and the merchant sits behind it.
• Open, federated rails. Google's Universal Commerce Protocol is described as an open machine-to-machine standard in which merchants expose catalogs and checkout endpoints directly, and merchants stay the merchant of record.

Four-Phase Agent Purchasing Protocol

1. Phase 1: Intent parsing. The agent's gateway takes a natural-language purchase request and decomposes it into machine-checkable predicates, such as product constraints, a price ceiling and a delivery requirement.

2. Phase 2: Dual-channel retrieval. A dense channel runs approximate nearest-neighbour search over product embeddings in a Hierarchical Navigable Small World (HNSW) graph. A lexical channel runs BM25 over inverted indexes, which anchors exact model numbers and technical attributes. The candidate lists are merged with Reciprocal Rank Fusion (RRF), where $k$ is a smoothing constant traditionally set to 60 and $w_m$ weights each channel:

   $\text{RRF}(d) = \sum_{m \in \{\text{dense}, \text{sparse}\}} \frac{w_m}{k + r_m(d)}$

3. Phase 3: Reranking with feedback. A cross-encoder reranks the top candidates, and click or completion feedback can adjust the order.

4. Phase 4: Two-phase transaction commit. In the prepare step the agent sends a signed checkout request and the merchant reserves the inventory under a time-limited lease. In the commit step the agent sends a payment token and the merchant confirms the order and returns a signed receipt.

Removing the checkout page from the loop has practical consequences. A machine-to-machine exchange does not wait for a page to render, and a merchant's backend can keep its inventory consistent through explicit locks and receipts instead of through scraping.

Operating Boundaries for Merchants: Response Time and Inventory State

A person tolerates a slow page. An agent running inside an orchestration framework does not, because its tool calls run under strict time budgets set by whatever system is orchestrating them. When a merchant endpoint responds slowly, an automated router may lower its confidence in that merchant and prefer another that exposes an equivalent catalog and responds faster. The practical rule for a merchant is that time to first byte and API response time are part of how an agent chooses, not only of how a human feels about a site.

A second boundary is concurrency. If several agents try to buy the last units of a limited stock at once, optimistic locking can lead to cascading rollbacks and stale stock counts, and the result is order cancellations after payment. Distributed leases with an expiry window reserve inventory for the duration of a checkout attempt, and fencing tokens let the merchant reject a late commit that arrives after its lease has expired.

$P(\text{Drop}) = \frac{1}{1 + e^{-\lambda (\text{TTFB} - \text{SLA}_{\max})}}$

The logistic expression above is a conceptual way to picture the idea: the chance that an agent drops a merchant rises as its time to first byte passes the agent's budget $\text{SLA}_{\max}$, with $\lambda$ controlling how sharp the cut-off is. It illustrates a mechanism and is not a measured relationship.

The pattern across the three approaches in the table is consistent: the more a transaction depends on rendering a page and parsing it, the more variable it is for an agent, and the more it depends on a published contract, the more predictable it is. How to be discovered by a shopping assistant is covered in How to Get Your Product Listed in ChatGPT Shopping, and the wider playbook for direct-to-consumer brands is in How D2C and E-commerce Brands Win AI Search.

Scoring Merchant Candidates: Rank Fusion and Latency Penalties

Candidate selection in agentic commerce can be written as information-gain optimisation across the hybrid retrieval channels. Candidates are first ranked independently by vector similarity and by lexical matching on SKU and attribute indexes. RRF merges the two rankings by rank position alone, which prevents the incompatible score scales from distorting the merge.

A second-pass score can then reward verified outcomes and penalise slow endpoints. One conceptual closed form is:

$S_{\text{final}}(d) = \sigma\left(\alpha \cdot S_{\text{RRF}}(d) + \beta \cdot \log(1 + C_d) - \gamma \cdot \frac{\text{Latency}_d}{\text{SLA}_{\max}}\right)$

Here $\sigma$ is the logistic function, $S_{\text{RRF}}(d)$ is the fused retrieval score, $C_d$ counts verified agent transactions that completed with candidate $d$, and $\text{Latency}_d$ is the candidate's observed response time measured against the negotiated limit $\text{SLA}_{\max}$. The coefficients $\alpha$, $\beta$ and $\gamma$ set the relative weight of semantic relevance, historical conversions and latency. They are parameters of the model, and no agent platform has published its own values.

The consequence for merchants is directional rather than numerical. A merchant with equivalent relevance, a stronger verified order history and a faster endpoint scores higher. A merchant whose endpoint is slow enough to exceed the limit can be disqualified outright, and the agent routes the purchase to an alternative merchant that offers the same product.

Diagnosing Failed Agent Checkouts

Failures in agentic checkout usually fall into three planes: the transport layer, the state-synchronisation layer, and the semantic payload layer.

Four-Step Remediation Protocol

1. Transport. Reuse persistent connections, for example HTTP/2 connection pooling, and use TLS 1.3 session resumption as described in RFC 8446, so each agent request avoids the cost of a fresh handshake. HTTP caching semantics in RFC 9110 help keep repeated catalog reads cheap.
2. Distributed inventory locks. Replace database-level row locks with leases that expire, and issue monotonic fencing tokens so a commit that arrives after its lease has lapsed is rejected.
3. Schema validation. Validate incoming agent payloads against the JSON-LD 1.1 context before an order is accepted. Reject unversioned or malformed Offer data with an HTTP 422 response and a machine-readable error.
4. Two-phase settlement. Verify the lease first, then settle payment, and return a signed fulfilment receipt so the agent can confirm the outcome.

Protocols and Schema Standards for Agent-Readable Catalogs

Machine-readable catalogs rest on a small set of standards.

• HTTP semantics (RFC 9110) defines caching and status codes that agents and proxies depend on.
• TLS 1.3 (RFC 8446) defines the secure transport.
• JSON-LD 1.1 is the serialisation for linked data in @graph form.
• Schema.org Product, Offer and MerchantReturnPolicy describe the facts an agent needs to evaluate a purchase: price, currency, availability and return terms.
• Model Context Protocol (MCP) defines how an agent discovers and calls tools exposed by a service, and Universal Commerce Protocol (UCP) defines federated catalog and checkout rails. Both are described in their own documentation.

Terms that recur in this area: agentic commerce, UCP, MCP, Agent2Agent (A2A), Neural Generative Retrieval, HNSW, vector quantisation, click-feedback reranking, headless execution, deterministic inventory locking, two-phase commit, merchant of record and Reciprocal Rank Fusion.

The @graph below shows a product with an offer and a return policy, using placeholder values:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://example.com/products/sku-99201#product",
      "name": "Industrial High-Precision Servo Actuator",
      "sku": "SKU-99201",
      "offers": {
        "@type": "Offer",
        "@id": "https://example.com/products/sku-99201#offer",
        "price": "1490.00",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "priceValidUntil": "2026-12-31T23:59:59Z",
        "hasMerchantReturnPolicy": {
          "@type": "MerchantReturnPolicy",
          "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
          "merchantReturnDays": 30
        }
      }
    }
  ]
}

References

• HTTP Semantics (RFC 9110) — IETF, 2022. https://www.rfc-editor.org/rfc/rfc9110
• The Transport Layer Security (TLS) Protocol Version 1.3 (RFC 8446) — IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446
• JSON-LD 1.1 Specification — W3C, 2020. https://www.w3.org/TR/json-ld11/
• Google Universal Commerce Protocol (UCP) Specification 2026 — Google. https://developers.google.com/merchant/ucp
• Amazon Shopping App Agentic Architecture Whitepaper — Amazon. https://www.aboutamazon.com/news/retail/amazon-shopping-app-buy-for-me-brands
• Model Context Protocol (MCP) Standard.