Agentic Commerce: Retailers Need a Front Door for AI Agents

What agentic commerce actually means

Agentic commerce is buying and selling in which an AI agent can discover products, compare options and complete actions on a customer’s behalf within defined permissions.

The defining change is delegated action. A chatbot may answer a sizing question, a recommendation engine may rank products and generative search may summarise reviews. An agent can go further: create a basket, select delivery, request approval, make a payment or initiate a return.

Consider a customer asking an assistant to reorder their usual coffee beans for delivery before Friday, provided the total is below £30. The agent identifies the known product, checks stock and delivery dates, and presents the proposed order. The customer approves it, the agent checks out using a permitted payment method, and the retailer records both the instruction and approval.

If the parcel is delayed, the agent might retrieve tracking information or request a cancellation. It should not substitute a different product, change the delivery address or exceed the spending limit unless the customer has authorised those actions.

That is a more credible near-term model than software spending freely without supervision. Approval points can gradually be removed for narrow, repeatable purchases once the customer, merchant and payment provider can enforce clear boundaries.

The Amazon–Meta dispute is about control of the customer

Amazon blocking Meta’s shopping agent is a useful example because the disagreement is not really about bots. It is about who controls discovery, purchase decisions and the customer relationship.

An agent-mediated sale can cost a retailer more than a page view. The retailer may lose:

• direct traffic and opportunities to build loyalty;
• control over ranking, bundles and merchandising;
• advertising or sponsored-placement revenue;
• behavioural data gathered during product research;
• the ability to explain important product differences;
• ownership of support and post-purchase communication.

The agent may become the interface customers trust, whilst the retailer is reduced to stock, fulfilment and returns. That is commercially uncomfortable, especially when the agent operator can alter rankings or introduce its own fees.

Blocking agents has a cost too. A customer who delegates product research may never visit merchants that cannot provide useful, machine-readable information. Those retailers lose qualified demand before their conventional acquisition funnel begins.

Amazon can defend a closed ecosystem because customers already start product searches there, and because advertising, marketplace data and membership are central to its model. Most independent UK retailers do not have that position. Copying Amazon’s response may protect control over customers who arrive directly while making the business invisible to customers who start with an assistant.

The practical objective is not maximum access or maximum obstruction. It is controlled distribution on terms the retailer can observe and enforce.

Should retailers welcome, restrict or charge shopping agents?

Controlled access should be the default. Approved agents should receive accurate product data and narrowly scoped actions through authenticated interfaces. Anonymous scraping can remain restricted, particularly when it creates load or ignores commercial rules.

Blocking is justified when an agent:

• crawls abusively or conceals its identity;
• presents stale prices, stock or delivery claims;
• creates fake baskets or orders;
• bypasses purchase limits or regional restrictions;
• misrepresents returns, warranties or product capabilities;
• cannot provide evidence of customer consent.

Unrestricted access is no better. A storefront built for humans cannot express that an agent may search and create a basket but may not submit an order. robots.txt can indicate crawl preferences, but it is not an authorisation system, policy engine or commercial contract.

We would not charge agents merely to discover public products. A discovery toll discourages a channel before its incremental value is known and favours the largest merchants that agents cannot afford to omit.

Fees become more reasonable when an agent consumes scarce services, accesses privileged or enriched data, reserves inventory, receives preferential availability or demonstrably generates profitable demand. Any agreement should define what is being paid for rather than treating automated traffic as inherently valuable.

Several rules are non-negotiable:

• Attribution: the order must identify the referring agent and retain that attribution through checkout.
• Consent: the retailer must know which customer instruction permitted each consequential action.
• Returns and cancellations: the agent must present the actual merchant policy and use supported workflows.
• Support ownership: the parties must define who handles selection errors, delivery issues and refunds.
• Data use: product, pricing and customer data must not be reused beyond agreed purposes.

The technical front door an agent-ready retailer needs

Agents should not be expected to operate a website by guessing what buttons and page markup mean. Keep the human storefront, but place a dedicated agent gateway beside it.

That gateway should expose current, structured information including:

• stable product and variant identifiers;
• descriptions, attributes and compatibility constraints;
• stock status and reservation rules;
• delivery destinations, costs and realistic promises;
• total prices, including unavoidable charges;
• age, quantity, return and regional restrictions.

Every agent should identify and authenticate itself. Permissions can then distinguish product search, basket creation, inventory reservation, checkout, cancellation and post-purchase support. Rate limits should apply by agent and action rather than relying only on IP addresses.

A policy engine should sit between the gateway and commerce platform. It can enforce rules such as maximum quantities, approved delivery regions, prohibited substitutions and mandatory human approval. Those rules then apply consistently whichever assistant initiated the request.

Transactional endpoints must be idempotent. If an agent retries a request after a timeout, the same operation should return the original result rather than creating a second order or charge. This is ordinary distributed-systems engineering, but it becomes critical when software is acting without a person watching each screen.

Signed requests, complete audit logs, anomaly detection and a per-agent kill switch are baseline controls. We would also separate agent credentials from internal service accounts and make permissions short-lived where possible.

This is a custom integration problem, not a page-builder feature. Our approach to custom web application development is to treat permissions, failure states and observability as product requirements rather than additions after checkout works.

Agentic commerce payments need mandates, not just checkout APIs

A checkout API can accept a payment. It does not prove that an AI system was entitled to make that payment.

Delegated payment authorisation requires a mandate: a record that the customer permitted an agent to spend within explicit boundaries. A useful mandate may specify:

• a maximum amount and currency;
• approved merchants or product categories;
• permitted products and substitutions;
• an expiry time or maximum number of purchases;
• delivery-address restrictions;
• changes that require renewed human approval.

UK payment and consumer obligations do not disappear because an agent initiated the order. Strong customer authentication may still be required depending on the transaction and applicable exemption. Retailers must also manage PCI DSS scope, refunds, cancellation rights and evidence that the customer agreed to the final purchase.

The emerging initiatives occupy different parts of this process. Stripe’s Agentic Commerce Protocol provides a way for agents and merchants to exchange product and checkout instructions, with Stripe positioned around payment and checkout infrastructure. Google’s agent-payment work addresses messages and mandates between agents, merchants and payment providers. Visa and Mastercard are developing network-backed credentials, authentication and controls intended for agent-initiated payments.

These should not be described as one interchangeable standard. A messaging protocol, an agent identity scheme, a checkout API and a card-network credential solve related but distinct problems. A retailer may eventually use several layers in one transaction.

Our Stripe integration work treats authorisation, retries, webhooks, refunds and reconciliation as one system. For delegated purchases, that system also needs an auditable chain showing what the customer requested, what the agent selected, which changes were made and what was finally approved. A successful charge alone is not sufficient evidence.

Where Shopify, Salesforce and other platforms fit

Platforms can shorten implementation, but each one controls a different part of the journey.

Shopify’s route is attractive for retailers that want quick access to supported sales channels. The trade-off is accepting more platform decisions about how products are found, how checkout operates and how attribution is measured.

Salesforce can connect customer records, service cases and automated workflows. It may be useful for handing an agent-originated order into support or retaining consent records. It does not fix unreliable inventory data or make an unsafe order endpoint safe.

The build-versus-buy rule is straightforward: buy commodity capabilities, but retain ownership of policy, observability, customer consent and integrations that create commercial advantage. A retailer should be able to replace a discovery channel without rewriting its core ordering rules.

A low-risk agentic commerce pilot for UK retailers

Start with one narrow, reversible journey. Replenishing a known product is safer than asking an agent to interpret an entire catalogue, compare subjective alternatives and purchase without review. Assisted buying from a restricted product range is another sensible starting point.

Run the agent against a sandbox before allowing live stock reservation or payment. Tests should include malicious product text, prompt injection, attempts to bypass quantity rules, expired mandates, delayed responses and duplicated requests. Failure behaviour matters as much as the happy path.

Permissions should expand progressively:

1. Product discovery using read-only data.
2. Basket creation with no inventory commitment.
3. Checkout after explicit human approval.
4. Tightly bounded autonomous purchases for proven repeat journeys.

Measure incremental revenue, not raw agent visits. Track conversion, gross margin, failed actions, returns, fraud, support cost and orders that would otherwise have arrived through a lower-cost direct channel. Attribution should distinguish genuinely new demand from customers whose existing relationship has been intercepted.

Set exit criteria before launch. Define the error rate, fraud pattern, support burden or attribution failure that will pause the pilot, and make rollback possible without taking the ordinary storefront offline.

Expand only when agent-originated orders are profitable, traceable and no more operationally harmful than existing channels. Until then, the right front door is narrow, authenticated and easy to close.

Talk to us about building an agent gateway, commerce integration or controlled pilot.