Agentic Commerce: Help an AI Shopper Make a Promise You Can Keep

“A waterproof jacket under 150, delivered before the weekend.” Imagine a shopper asking an assistant that question. A small outdoor shop has a suitable jacket, but the price on its product card belongs to a different size. The delivery estimate assumes a postcode the shopper has not supplied. This is an illustrative scene, not an observed customer result.

The problem is not that the shop needs to sound more like an AI. It needs to make a reliable offer: this variant, at this total, available for this destination, with these conditions. The assistant may help someone discover it, compare it or buy it. Those are different jobs.

Agentic commerce means software assisting with shopping tasks and, where authorised and supported, taking purchase actions for a person. It does not mean every assistant can pay, every merchant is eligible, or the customer relationship has disappeared.

Start with the route, not the protocol logo

In one route, the assistant recommends a product and the shopper finishes on your website. In another, a supported integration presents checkout in the assistant. A cart transfer sits between them: it can populate your cart without completing payment. Tracking, cancellation and returns require further supported capabilities; a buying integration does not imply all three.

These distinctions change the work you buy. A feed can improve discovery without giving anyone permission to place an order. Publishing an API specification does not enrol your shop in a platform programme. Check the merchant, country, product category and user experience actually available to you.

What the primary sources say on 5 November 2026

The following are selected checkpoints, not a worldwide availability list. OpenAI’s merchant page and some checkout/help documentation describe different experiences; treat that as a reason to verify your approved route, rather than assume either universal access or universal withdrawal.

Programme / official reference	What to verify
ChatGPT merchant programme	The current merchant page prioritises discovery and merchant-owned checkout; it lists shopping as U.S.-available. Confirm the approved experience.
Google UCP Cart API	October documentation distinguishes cart transfer from native checkout. Transfer alone does not require the native checkout integration.
Perplexity Instant Buy	The help centre describes U.S. purchases through compatible merchants. Eligibility is not every product at every store.
Amazon Shop Direct / Buy for Me	Shop Direct links to external stores; eligible Buy for Me products support purchasing on the shopper’s behalf. Check participation controls.

Make the jacket one identifiable offer

Keep a stable product identity and separate variant identifiers. In the illustrative example, JKT-M-TEAL is one medium teal jacket, not every size of the model. Store material, fit, care, weight and relevant performance claims as supported attributes. Do not invent a GTIN or waterproof test rating to fill an empty field. “Water-resistant” and a substantiated waterproof specification are not interchangeable.

Keep the useful story and photographs too. People and multimodal assistants can use imagery, reviews, preferences and brand context; structured fields do not replace them. Product pages, feeds and checkout should derive their claims from governed records, with channel-specific mappings checked for errors.

A feed is a distribution copy and can lag. Choose an update cadence for the actual volatility and channel requirements, monitor rejected or stale items, and revalidate the price and sellable quantity at the transaction boundary. The mere word “real-time” does not reserve the last jacket.

Recheck the promise when the shopper moves to checkout

For a worked example in one unspecified currency, the chosen variant costs 120, an eligible discount removes 12, shipping adds 8 and an assumed tax adds 23.20: total 139.20. That is under the shopper’s 150 budget only if the budget covers the final total and no other applicable charges remain. The tax is invented for arithmetic, not a rate recommendation.

Ask for the information needed to quote delivery. Destination, order cutoff, stock location and carrier service matter. “Dispatch tomorrow” is not “arrives before the weekend.” Show the actual estimate and any uncertainty; do not silently substitute another size, colour, delivery date or more expensive item.

Before committing, validate the current cart, reserve stock where the system supports it and require the approval or delegated authority your checkout route needs. A recommendation, cart, payment authorisation, captured payment and accepted order are distinct records. If the result is unknown after a timeout, look up the existing operation before a bounded retry; do not create a fresh order simply because the screen stopped responding.

An assistant is not a permission bypass

Public product facts and private order details need different access. Give order status only to the verified buyer or an explicitly authorised representative, scoped to that order and account. A predictable order number or “AI agent” user-agent string is not authorisation. Keep customer addresses, invoices and staff-only stock data out of public feeds.

Validate tokens, scopes and current account permissions server-side. Keep untrusted product descriptions, reviews and tool outputs from changing payment instructions or system permissions. Apply normal fraud, rate-limit and payment controls; an automated client can still be hostile or mistaken.

Write return eligibility, deadlines, condition requirements, costs and refund timing precisely, with legally required exceptions. A return request is not an approved refund, and an order marked shipped is not proof of delivery. Decide who owns support, disputes and exceptions before opening a new route.

Run a small pilot with evidence, not a readiness total

Select a manageable set of variants in an eligible programme and name an owner for catalogue quality, checkout and customer support. Sample them against the source records and test a real destination, discount eligibility, the last unit, a price change, an expired session, a timeout after commitment and an authorised post-purchase lookup. Also test that a different customer cannot retrieve the same order.

Treat a leaking order endpoint, an unapproved payment or unresolved duplicate-order behaviour as a stop condition. A high combined score for attractive images and complete attributes cannot cancel out those failures. Expand after the critical cases pass and the operating team can reconcile the pilot’s orders and money.

Track feed acceptance and sampled offer accuracy separately from checkout attempts, accepted orders, settled payments, cancellations and returns. Use channel-provided order references and referral data where available, but allow an unknown source: referrals can be stripped and research can happen on another device. A few attributed sales do not prove incremental revenue. Compare matched cohorts, acquisition costs, support time and contribution after returns before expanding.

What the shop owner can do next

Take one jacket from source record to a supported shopping surface, through an approved order and back to an authorised status lookup. Write down every mismatch and assign its owner. Better data makes a more dependable offer; it does not guarantee a recommendation, ranking or conversion. That is a useful first investment even if the next platform announcement changes the checkout route.

Part 1 of the AI shopping series. Continue with product discovery and recommendations, then checkout and delegated payments.

Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. The shop, product and calculations are teaching examples; programme availability can change.