Agentic Commerce: What It Means for Your Business

Quick answer. Agentic commerce is when software agents research, compare and sometimes buy products on a customer’s behalf. For an operator it is less a channel than a data and interface problem: machine-readable product data, a checkout an agent can drive, and logs that show what happened. Most agent journeys still end with a handoff to a human, so treat unattended payment as the exception, not the default.

What matters most

• Agents drop products for missing data, not for weak copy: identifiers, price, availability, delivery cost and return terms decide whether you stay comparable.
• Most agent journeys today end in a handoff to your own checkout; unattended payment is the exception because authentication still needs the cardholder.
• Your product feed and your product page must agree, because an agent may read either one and a mismatch reads as an unreliable offer.
• Agent traffic is countable at the server and cart level, but cross-agent attribution does not exist yet and should not be reported as if it does.
• The first work is catalogue hygiene and a callable checkout, neither of which requires a replatform.

What is agentic commerce, in plain terms?

Agentic commerce is the point where a software agent does shopping work for a person. It reads product pages, compares options against a brief, and in some cases adds to a basket or pays. The agent is not the chatbot on your storefront. It is a separate program, usually running outside your domain, acting on instructions from a customer.

Three capabilities matter to an operator: reading your catalogue, holding a basket, and completing payment. Each has a different level of readiness. The term itself is not settled — vendors use it for everything from a product recommender to a system that buys without a human in the loop. When someone pitches agentic commerce to you, ask which of the three capabilities their product actually performs.

Where to go next

• agentic delivery platform services
• ecommerce SEO for product catalogues
• analytics and attribution setup
• book a 5 Kings SEO audit

What does an agent need from your catalogue before it can compare you?

An agent compares on identifiers and constraints, not on brand adjectives. If it cannot extract a price, a stock state and a delivery window, you fall out of the shortlist. That data usually exists in your PIM and your feed. The problem is that it does not survive the trip to the product page.

• Identifiers: GTIN, MPN and brand, so the agent can tell your SKU apart from a near-identical one.
• Price: current price, currency, and whether it is a unit price or a pack price.
• Availability: in stock, on backorder or discontinued, with the date the state was last confirmed.
• Delivery: cost and expected window, not the phrase ‘fast shipping’.
• Returns: window, who pays return postage, and what is excluded.
• Variants: consistent option names such as colour and size, plus one canonical URL per variant.

Which parts of the buying journey can an agent finish today?

Discovery and comparison work wherever product data is machine-readable. Adding to a basket works where a cart API exists and the agent has permission to call it. Completed payment is rarer. Most agent journeys still end with a link back to your checkout, and the customer pays. That handoff is not a failure; it is the current normal, and it is where your conversion rate still gets decided.

• An agent cannot pass strong customer authentication alone; the cardholder still approves the challenge.
• Age-restricted, regulated and made-to-measure goods rarely complete without a human step.
• Returns, delivery disputes and substitutions are not handled end to end by agents today.
• Some agents only read pages and never call an API, so a page that renders without JavaScript still matters.

What has to exist on the technical side before agents can transact?

The checkout has to be callable. In practice that means a documented cart or order API, idempotency keys so a retry does not create two orders, tokenised payment credentials instead of raw card data, and a clear step-up path when the issuer demands authentication. Stripe’s Payment Intents documentation is a useful reference for how that flow is modelled, even if you run a different processor.

On the discovery side, three surfaces do most of the work. Structured data on the product page, using schema.org Product and Offer, tells a parser what the page sells. Robots rules and server logs tell you who is reading. A machine-readable index such as llms.txt is a proposed convention, not an agreed standard, so publish one if it is cheap and do not build a strategy on it. Model Context Protocol is more useful internally, for exposing your own tools to your own agents.

Where does this land on the platform you actually run?

The surfaces differ by platform. The table below is a starting map, not a specification. Check your version, your app permissions and your API scopes before you promise an agent anything.

How do you measure agent traffic without inventing numbers?

Start with server logs. Many agents declare themselves in the user agent string. Some do not, and some browsers spoof. Count requests to product and cart endpoints rather than page views. Then instrument cart creation and checkout handoff as events, with the referrer and user agent attached, so you can see which journeys started outside your site.

Cross-agent attribution is not reliable yet. No shared identifier follows a person from an assistant to your store, and analytics scripts miss requests that never execute JavaScript. Report what you can trace — sessions, carts, and orders with a logged entry path — and say plainly that the rest is unmeasured. A number you cannot defend is worse than a gap.

What should you do first on Monday?

Work in this order. None of it requires a replatform, and most of it improves your ordinary search performance at the same time.

Catalogue fixes and machine-readable product data are the same project as your ecommerce SEO. The checkout and interface side is what our agentic delivery platform work covers, and the logging sits with analytics and attribution.

• Audit product structured data on your top 200 SKUs against schema.org Product and Offer.
• Reconcile feed and product page for price, stock, delivery cost and return terms.
• Publish one canonical URL per variant and standardise option naming.
• Document your cart and checkout API, including auth, scopes and rate limits.
• Log agent user agents and checkout handoff events before you buy tooling.
• Decide what you will not support, such as unattended payment, and write it down.

Frequently asked questions

Do I need to rebuild my store for agentic commerce?

No. The work that matters first is data quality and interface clarity. Correct identifiers, prices, stock states, delivery costs and return terms on your product pages and in your feed do more than a new frontend. A callable cart API is the second step, and most established platforms already expose one. Replatforming before you have fixed the data just moves the same gaps to a new system.

Will AI agents actually buy things, or only research?

Mostly research and comparison today, with a handoff to your checkout for payment. Unattended purchases happen in narrow cases where a merchant has built a dedicated checkout flow and the customer has pre-authorised it. Strong customer authentication, fraud checks and issuer challenges still require the cardholder. Plan for the handoff and make it fast rather than assuming full autonomy is coming next quarter.

How do I block bad bots without blocking agents I want?

Use robots rules and rate limits deliberately rather than a blanket block. Decide which crawlers you allow on product and cart endpoints, and block by behaviour — request rate, path patterns, missing headers — rather than by category. Keep a log so you can see what changed. A blanket block on all automated traffic also removes the agents that send you qualified customers.

Can I track agent traffic in my analytics platform?

Partly. Requests that never execute JavaScript do not appear in client-side analytics, so server logs are the reliable source. Many agents identify themselves in the user agent, which you can segment on. What you cannot do yet is follow one person from an assistant conversation to your order. Track sessions, cart creation and checkout handoffs, and label the rest as unknown rather than estimating it.

Which product data matters most to an AI agent?

Identifier, price, availability, delivery cost and return terms, in that order. Without a GTIN or MPN an agent struggles to match your SKU to the same product elsewhere. Without a confirmed stock state and a delivery window it cannot rank you against alternatives. Descriptions help a human decide; the structured fields decide whether you are in the comparison at all.

Sources

• Product and Offer vocabulary used to describe catalogue items to parsers
• Google’s required and recommended properties for product structured data
• Proposed llms.txt convention, referenced as a proposal rather than a standard
• Payment Intents as the model for a callable, retry-safe payment flow