Skip to content
UCP
Menu

Resources · Essay

Anatomy of an agent purchase

A step-by-step decomposition of a shopping agent purchase — from user intent to post-sale — with failure modes and operator takeaways at each step.

Published : ·12 min read ·Primary : how does an ai shopping agent buy

When people imagine an "AI agent buying something", they picture the moment of purchase. But the purchase is the eighth step of a long flow. Understanding each step is the easiest way to see where a merchant should intervene. This essay walks through a canonical eight-step agent purchase, with failure modes and operator leverage points at each.

The canonical flow

  1. Intent formation
  2. Decomposition
  3. Retrieval
  4. Comparison
  5. Disambiguation
  6. Commitment
  7. Transaction
  8. Post-sale

Step 1 — Intent formation

The user states a goal. Sometimes clearly ("a 65-inch OLED TV under €2,500, delivered before May 5"), sometimes vaguely ("I want a new phone"). The agent must parse, disambiguate and, when needed, ask a clarifying question.

Failure mode: intent ambiguity causes the agent to over- or under-specify constraints. Not a merchant concern directly, but it determines the query shape.

Step 2 — Decomposition

The agent decomposes the intent into structured constraints: category, brand preferences, budget, attributes, region, timeline, risk tolerance.

Operator leverage: if your attributes are typed and cover the category's query surface, decomposition maps cleanly to your data. If not, you are filterable-out on constraints you actually meet.

Step 3 — Retrieval

The agent queries one or more sources: a retrieval index built from feeds, a marketplace API, a direct search, a browser-use fetch. Each source has different latency and trust characteristics.

Failure mode: your PDP is not in the retrieval index because your schema is thin, your sitemap is incomplete, or a consent wall blocked indexing.

Operator leverage: the Merchant Center feed is the lowest-effort, highest-yield surface. Complete it.

Step 4 — Comparison

The agent compares candidate offers across price, match score (embedding distance to intent), policy fit, delivery time, merchant trust.

Failure mode: identifier ambiguity causes two merchants selling the same product to be scored separately, at reduced confidence.

Operator leverage: GTIN coverage, structured policies, honest availability.

Step 5 — Disambiguation

The agent narrows to 1–3 candidates. It may surface them to the user ("here are your three best matches") or proceed autonomously within permissions.

Failure mode: your offer is excluded because policy fields are missing and the agent cannot verify a must-have constraint ("ships to Belgium by Saturday").

Step 6 — Commitment

The user confirms, or the agent commits on delegated permission. Commitment typically requires the agent to present payment, shipping address, possibly an account identity.

Failure mode: unexpected account requirement (email verification, SMS OTP) the agent cannot satisfy.

Operator leverage: guest checkout, tokenized payment, agent-identifiable sessions.

Step 7 — Transaction

Payment is processed. Agent-pay credentials are presented and validated by the PSP. Order is created.

Failure mode: PSP does not recognize agent-pay scheme; transaction falls back to human-driven checkout, losing the autonomy promise.

Operator leverage: ensure your PSP supports Stripe Agentic Commerce, Visa Intelligent Commerce, Mastercard Agent Pay as they roll out. Test in sandbox.

Step 8 — Post-sale

Order confirmation, tracking, delivery, returns. Agents watching on behalf of the user ingest lifecycle events, report status, and initiate returns/claims when needed.

Failure mode: no webhook, tracking URL is HTML-only, returns process requires phone call.

Operator leverage: structured order lifecycle webhooks, returns/claim API, agent-acceptable identity proofing.

Where in the flow are agents today?

  • Steps 1–5 are largely production. Advisory agents do these well.
  • Step 6 is variable. Most agents hand the user to the PDP for final confirmation.
  • Step 7 is emerging. Agent-pay rails are in pilot or preview at major PSPs and networks.
  • Step 8 is uneven. Lifecycle webhooks exist for many merchants; agent-initiated returns barely.

The operator message: do not wait for step 7 to be universal before you fix steps 1–5. Those are already live.

A concrete example

User: "I want a cotton midweight sweatshirt, heather grey, men's large, under €80, shipped to Paris by Friday. Free returns."

Decomposition: category=apparel/sweatshirts, material=cotton, weight=midweight, color=heather-grey, size=M-L, budget≤€80, region=FR/Paris, delivery_by=Friday, returns=free.

Retrieval: agent queries a handful of retrieval indexes built from merchant feeds. Filters to active offers in FR.

Comparison: 12 candidates. Filters by delivery ETA, drops 7. Filters by free returns, drops 2. Three remain.

Disambiguation: agent surfaces three options to the user, with price, delivery date, and a one-line differentiator per option.

Commitment: user picks one. Agent completes checkout using a stored shipping address and an agent-scoped Stripe intent.

Transaction: Stripe ACP authorization succeeds, merchant receives order tagged as agent-paid.

Post-sale: merchant emits lifecycle webhooks; agent reports tracking to user; sweatshirt arrives Friday morning.

Every step in that flow is a feature of the Universal Commerce Protocol stack. Every step is also an operator leverage point.

Where to go next