Agent-ready and agentic commerce guide

This agentic commerce guide brings together every layer a brand needs so that SI agents can find it, understand it correctly and buy from it. Being agent-ready is not a single file, a single protocol or a single integration; it is an operating model that runs from access policy and product data to checkout, payment authority, measurement and law. The guide sets that model out through maturity levels, a reference architecture, platform-by-platform steps and a 12-month roadmap.

The perspective comes from Webtures’ GEO, AEO and agent readiness work as a digital consultancy that has worked with brands from Istanbul and London for 16 years. For a short definition of the concept and the scope of our service, see agentic commerce readiness; this guide focuses on execution: what to do, when, in which order and with what evidence.

The protocol and platform landscape is moving fast. Every date and figure in this guide was therefore checked against a primary source (protocol specification, official company announcement, regulatory text) as of 20 October 2026 and is listed in the sources section. Figures based on a company’s own measurement are labelled as company claims. Claims that could not be verified were left out. This guide is not legal or investment advice.

Executive summary: 12 theses on agentic commerce

The 12 theses below summarise the rest of the guide. Each one stands on its own; the detail sits in the relevant section.

1. Agentic commerce is not a checkout feature; it is a restructuring of the distribution channel. Agents fold discovery, comparison, decision and purchase into a single conversation. The top of the funnel and the moment of decision are moving to SI surfaces.
2. Being agent-ready is not a certificate; it is an operating model made of eight capabilities. Discoverability, comprehensibility, transactability, identity, reliability, observability, security and governance. The weakest link sets the level of the chain.
3. Today’s reality is agent-led discovery more than agent-led buying. On 24 March 2026 OpenAI said the first version of Instant Checkout did not offer the flexibility it wanted, let merchants use their own checkout experiences and focused on product discovery. Value today is created mostly at the citation, recommendation and referral stages.
4. No single protocol will win; the multi-protocol era is here to stay. ACP, UCP, AP2, MCP, A2A and x402 solve different layers. The right strategy is a protocol-independent core with protocols connected through adapters.
5. The biggest bottleneck is not technology but data consistency. Adobe’s April 2026 measurement puts the average machine-readability score of US retail product pages at 66%. Inconsistent prices, stock, return policies and identifiers are the most likely reasons an agent drops a brand.
6. Payment is the most complex and most regulated part of agent commerce. Card networks are building token and agent identity layers, and AP2 ties user authority to signed mandates. How liability is shared between the parties is still largely left to contracts.
7. Agent traffic should be managed as an intent signal, separate from classic bot traffic. HUMAN Security’s data for the first eight months of 2025 shows that about 87% of the pages agents browsed were product-related, while only 2.2% of agent interactions were on checkout pages and 3.9% on account pages (company claim). There is a wide gap between discovery and transaction.
8. Being good for agents does not mean being bad for people. Clear, structured, verifiable information, fast pages and transparent pricing serve both. Agent-ready transformation is also a classic SEO and conversion optimisation programme.
9. The real commercial risk is losing the customer relationship, not losing traffic. Staying merchant of record, first-party data, loyalty and brand experience decide long-term margin. An agentic strategy is a decision about data and relationship architecture.
10. Measurement has to be rebuilt. Last click sees only one link of the chain from retrieval and citation to click, checkout and repeat purchase. Server logs, an order source field and first-party data become critical.
11. Regulation has become enforceable from 2026. The transparency obligations in Article 50 of the EU AI Act have applied since 2 August 2026. Consumer law, strong customer authentication and data protection rules apply to agent transactions unchanged.
12. The winners will not be those with the best integration but those that are the most reliable source. Agents choose fast, consistent, verifiable and well-documented sources. This is a game of operational discipline more than technical brilliance.

How to read this guide

• Leadership teams: the 12 theses, market data, commercial strategy and roadmap sections, then the one-page assessment in the checklists.
• Product and technology teams: protocol architecture, the maturity model, technical implementation and the example files.
• E-commerce and marketing teams: the timeline, platform playbooks, measurement and sector scenarios.
• Risk and legal teams: the security, risk and law section and the payments, risk and legal checklist.

What does agent-ready mean? Agents, agentic commerce and readiness

Agent-ready means a business’s digital assets can be found, understood, trusted and transacted with by SI agents. Agentic commerce is an SI agent discovering, comparing and selecting products on a user’s behalf and, where authorised, starting payment. What agentic commerce is, and which layers a brand needs to prepare, is summarised on our agentic commerce readiness page; this section pins down the concepts used throughout the guide.

What do we mean by an agent?

In this guide an agent is a software system with four components: it interprets a goal the user states in natural language, breaks the goal into sub-tasks, uses external tools such as web pages, APIs, MCP servers and payment networks, and acts within the limits the user sets (budget, brand, time, approval). The difference between a chatbot and an agent is action: a chatbot answers “what should I buy?”, an agent starts the purchase flow.

Three modes of agentic commerce

Agentic commerce is not the same as conversational commerce. In conversational commerce the person decides; in agentic commerce part of the decision is delegated to a machine. That difference is decisive for legal liability and for measurement.

Seven common misconceptions

1. “Agentic commerce means checkout in ChatGPT.” Most of the value today is in discovery and referral. OpenAI itself shifted its priority to product discovery in March 2026.
2. “llms.txt is a ranking factor.” Google says there is no need for llms.txt or similar special files to appear in SI-powered Search, and that Google Search does not use them. It can remain a low-cost hygiene step for other engines.
3. “We have an API, so we are agent-ready.” The API has to be discoverable, documented, authorised, idempotent and fast. Most enterprise APIs fail that test.
4. “Agents only look at price.” Agents weigh stock, delivery time, return policy, reliability and brand signals together.
5. “Agentic commerce is limited to retail.” UCP’s plans to expand into lodging and food ordering show the scope spreading into travel, food and services.
6. “Users don’t trust agents, so there’s no hurry.” According to Adobe, in March 2026 SI-referred traffic converted 42% better than non-SI traffic; in March 2025 it converted 38% worse. Waiting raises the cost of learning.
7. “One protocol will win, so let’s bet on it.” Protocols solve different layers; you need an adapter architecture.

How agents “understand” a brand is a separate discipline that comes before the transaction layer. Clarity of brand entities and machine-interpretable content are the scope of our Agent Experience (AX) service.

Agentic commerce timeline: what happened between 2024 and 2026?

The timeline below shows the order in which agentic commerce infrastructure was built. Dates are taken from primary sources; the aim is to separate strategy from announcement noise.

OpenAI and ACP: a fast start, then a turn to discovery

On 29 September 2025 OpenAI and Stripe announced Instant Checkout in ChatGPT, built on the Agentic Commerce Protocol (ACP). At first, US users could buy from US Etsy sellers inside the chat; according to ChatGPT’s release notes, Shopify merchants followed on 20 November 2025. Only single-item purchases were supported at launch.

On 24 March 2026 OpenAI said the first version of Instant Checkout did not offer the flexibility it aimed for, that it was therefore letting merchants use their own checkout experiences, and that it was concentrating on product discovery. Merchants wanting deeper integration still have the option of building ChatGPT apps. As of October 2026, OpenAI’s help pages say an Instant Checkout option may still appear for some eligible products and merchants; the feature was deprioritised, not removed. ACP lives on: product results and comparisons in ChatGPT are powered by it.

The lesson: agent-led discovery is growing fast, while agent-led payment is operationally hard. Keeping stock, tax, shipping, returns and price in sync inside a single chat interface is complex, and merchants care about keeping checkout under their own control. The strategy should be to win the discovery layer early and keep options open at the payment layer.

Google: UCP, AP2 and Universal Cart

Google announced the Universal Commerce Protocol (UCP) on 11 January 2026. UCP was co-developed with Shopify, Etsy, Wayfair, Target and Walmart and is endorsed by more than 20 companies including Adyen, American Express, Best Buy, Flipkart, Macy’s, Mastercard, Stripe, The Home Depot, Visa and Zalando. In Google’s words, retailers remain the seller of record. UCP was designed to be compatible with A2A, AP2 and MCP.

On 19 March 2026 optional Cart, Catalog and Identity Linking capabilities were added to UCP. Identity Linking lets users bring loyalty programme and membership benefits into agent shopping. On 19 May 2026 Google announced Universal Cart, which works across Search, Gemini, YouTube and Gmail, said UCP checkout would open in Canada and Australia in the coming months and later in the UK, and said AP2 would come to Google products starting with Gemini Spark.

According to Google Merchant Center help, as of 20 October 2026 UCP-based checkout applies only to products eligible in the United States, Canada and Australia, and is available for selected merchants. Türkiye is not on that list.

Microsoft: Copilot Checkout and Brand Agents

On 8 January 2026 Microsoft announced it was beginning to roll out Copilot Checkout on Copilot.com in the US. Integration runs through PayPal, Shopify and Stripe; the merchant stays merchant of record, and Shopify merchants are enrolled automatically after an opt-out window. According to Microsoft’s own data (August 2025), journeys that included Copilot led to 53% more purchases within 30 minutes of interaction, and when shopping intent was present, journeys with Copilot were 194% more likely to end in a purchase (company claim).

In the same announcement Microsoft introduced Brand Agents, which work on a brand’s own site in its own voice; the feature is offered to Shopify merchants through a waitlist. The lesson: representation on external SI surfaces and an agent experience on your own site are two separate capabilities and should be planned separately.

Shopify: Agentic Storefronts and the Agentic plan

On 24 March 2026 Shopify announced Agentic Storefronts, making merchants’ products discoverable in ChatGPT, Microsoft Copilot, AI Mode in Google Search and the Gemini app. According to Shopify, there are no transaction fees beyond standard processing rates, orders flow into the admin with ChatGPT referral attribution, and merchants remain merchant of record. In ChatGPT, purchases complete through the merchant’s own checkout in an in-app browser. Shopify’s current help page also lists Meta surfaces, including Muse, among the channels.

In the same announcement Shopify made the Agentic plan generally available, letting brands that do not run on Shopify open their products to the same agent channels through Shopify Catalog. Being both a co-developer of UCP and active on the ChatGPT side puts Shopify in the position of a commerce operating system that links protocols together. For merchants that means access to many channels from one platform; it also means more intermediary power for the platform.

Amazon, Perplexity and other surfaces

Amazon is building the most integrated model on the agent side. On 13 May 2026 Rufus was renamed Alexa for Shopping and brought together with Alexa+; in the US the experience offers features such as automatic buying at a set price and price alerts. Buy for Me lets Amazon’s agent buy from brand sites on the user’s behalf for a limited group of US customers. What it takes to be chosen by agents in the Amazon ecosystem is covered in the agent makes the recommendation now.

On 18 November 2024 Perplexity announced “Buy with Pro” for US Pro users and a free Merchant Program aimed at large retailers. It is smaller than ChatGPT and Google, but its high-intent traffic makes it valuable for early testing. Surfaces such as Meta, TikTok and Pinterest work on the same principle: a structured catalogue, real-time stock and price, fast responses.

The payment layer: Visa, Mastercard and Stripe

Visa Intelligent Commerce was announced on 30 April 2025 and provides tokenised credentials and a trust layer for agent transactions. On 14 October 2025 came the Trusted Agent Protocol, developed with Cloudflare and built on Web Bot Auth. Intelligent Commerce Connect, announced on 8 April 2026, is positioned as an on-ramp independent of network, protocol and token vault, names the Trusted Agent Protocol, ACP and UCP, and is in pilot. On 10 June 2026 Visa announced it would work with OpenAI under Visa Intelligent Commerce.

Mastercard Agent Pay was announced on 29 April 2025 and provides tokenised credentials and a framework for verified agents. In Türkiye, Garanti BBVA announced on 23 December 2025 that, with Mastercard, it had demonstrated the first end-to-end agentic transaction based on Agent Pay principles, with Atelier Rebul; the service was described as coming soon to Garanti BBVA Mobil and Bonus Flaş.

Stripe announced its Agentic Commerce Suite on 11 December 2025 to help businesses get ready to sell through multiple agent channels. Stripe’s Shared Payment Token (SPT) gives a seller scoped access to a customer’s payment method for agent-initiated purchases, limited by currency, maximum amount and expiry. According to Stripe’s documentation, SPT is available in the US, Canada and selected European countries; Türkiye is not on the list.

Agentic commerce in numbers: growth, conversion and illusions

The real size of agentic commerce in 2026 cannot be captured in one number, because “SI-referred traffic”, “agent traffic” and “agent-mediated sales” are measured in different ways. The table below includes only data with a clear primary source and states what each row measures. Forecasts with unclear sources and figures that circulate only through secondary sources were left out on purpose.

How should this table be read? The growth rates are striking but the base is small; increases of several hundred per cent do not change the fact that SI-referred traffic may still be a small share of total traffic. The real signal is that the conversion gap has turned positive: a year ago visitors from SI surfaces converted worse, and now they convert better. That suggests the channel has moved from curiosity to intent.

Survey data measures intent and perception, not behaviour. Most merchants saying they are preparing does not mean they are ready; the fact that a third of product page content was unreadable to machines in the same period is the clearest evidence. The most reliable planning data is your own channel’s data: measuring the share of SI-referred revenue every quarter and projecting from the trend is a sounder case for investment than external forecasts. Read the large figures that independent industry research gives for 2028 and beyond as a direction, not as a budget justification.

The real issue: the machine-readability gap

Adobe’s April 2026 report shows the most concrete bottleneck in agentic commerce: on US retail sites the average machine-readability score of product pages is 66%, so roughly a third of the content is invisible to language models. Homepages average 75%, with 82.5% for the best sites and 54.2% for the weakest. In practice the typical causes of this gap are:

• Price and stock information loaded late through JavaScript.
• Text embedded in images, especially in fashion and electronics.
• Inconsistent GTINs and SKUs across channels; one product with several identities.
• Return and shipping policies that only exist in a PDF or an FAQ page.
• hreflang and currency confusion on multilingual sites.
• Infinite scroll, pop-ups and interface layers agents cannot follow.

The conclusion is clear: the first and largest share of agent-ready investment should go into basic data hygiene, not new protocols. If product data is inconsistent, no checkout integration will help. Why agent traffic does not show up in analytics, and how to measure it, is covered in what is dark SI traffic.

Who is winning, and who is at risk?

For now the winners are the large platforms that hold distribution and data (Google, Microsoft, Amazon, Meta, Shopify, OpenAI), the payment networks and providers that take a share of every transaction, the companies providing feed, identity, security and measurement infrastructure, and merchants with strong product data and operational discipline. At risk are merchants competing on price alone with weak data and slow sites, brands entirely dependent on intermediary platforms with no first-party data, and approaches that reduce SI visibility to a single file. The position of marketplaces is unclear: outside agents can bypass them, but marketplaces are responding by building their own assistants and seller agents.

Agentic commerce protocols: who solves what?

Thinking of agentic commerce as one protocol is a mistake. Different protocols solve problems at different layers, and every layer depends on the accuracy of the one beneath it: if the catalogue is wrong, checkout fails; if identity cannot be verified, payment is not safe. The seven-layer model below shows where each protocol sits.

1. Discovery and content: robots.txt and content usage signals, sitemaps, schema.org, llms.txt, Markdown versions, product feeds.
2. Identity and authorisation: OAuth 2.x scopes, signed agent requests (Web Bot Auth), allowlists.
3. Catalogue and cart: feeds, catalogue APIs, UCP Catalog and Cart, ACP Feed API and Cart, MCP tools.
4. Checkout: ACP, UCP, embedded or native checkout.
5. Payment: payment tokens, AP2 mandates, strong customer authentication, card network programmes, x402.
6. Post-purchase: webhooks, order status, returns, exchanges, customer service.
7. Observability and governance: logs, agent identity, attribution, policy and audit trail.

Protocol comparison table

The discovery layer: robots.txt, Content Signals and llms.txt

robots.txt is still the most basic crawl control. On 24 September 2025 Cloudflare published its Content Signals Policy, which expresses a distinction between search, ai-input and ai-train inside robots.txt; domains using managed robots.txt allow search and disallow training by default. On 1 July 2026 Cloudflare added the option to manage SI traffic separately by Search, Agent and Training categories. Under the rules introduced on 15 September 2026, new ad-supported domains disallow SI training and block agent access on pages with ads by default, while search access stays open. Mixed-use crawlers such as Googlebot, used for both search and SI, are only blocked if the site owner chooses to block training access.

The implication for merchants is clear: blocking agent traffic entirely loses sales, while opening everything without distinction means uncontrolled use of content and price data. The right approach is a category-based policy: product and policy pages open to search agents and agents acting for users; checkout and account pages only through authorised sessions; admin and internal pages closed; crawling for training a separate decision based on business strategy.

The picture for llms.txt is mixed. Chrome Lighthouse’s experimental “agentic browsing” category includes an llms.txt audit that checks for a machine-readable summary at the domain root. On the other hand, Google Search’s SI optimisation guide says you do not need to create new machine-readable files, SI text files or Markdown to appear in Google Search and that Google Search does not use them, adding that keeping such a file is fine. Webtures’ recommendation: implement llms.txt as a low-cost hygiene step for multiple engines and agents, but never ahead of product data, feeds and page quality.

Identity and authorisation: OAuth, Web Bot Auth and agent directories

The critical question in agent commerce is on whose behalf the requesting agent is acting and what it is allowed to do. For authority on a user’s behalf, UCP uses OAuth 2.0-based account linking in its Identity Linking capability. For the agent’s own identity, Web Bot Auth relies on IETF drafts that define how bots cryptographically sign HTTP requests; Cloudflare has supported these signatures in its verified bots programme since 1 July 2025, and Visa’s Trusted Agent Protocol is built on the same approach. The aim is to replace easily spoofed user agent and IP information with verifiable agent identity. Card networks are also working on directories of verified agents and merchants; what a merchant needs in practice is an allowlist of agents, a reputation signal and automated policy.

MCP: the agent’s tool layer

The Model Context Protocol (MCP) standardises how SI applications access external data and tools, and since 9 December 2025 it has been governed under the Agentic AI Foundation at the Linux Foundation. The current specification version is 2026-07-28, and it brings an important architectural change: the initialisation handshake and session ID are gone, every request carries its own protocol version and client capabilities, servers gain a mandatory discovery call, and Tasks for long-running work moved from the core into an official extension. The change improves scalability but requires servers written around session assumptions to be redesigned.

For commerce, MCP lets a merchant offer its catalogue, stock lookups, cart and order status to agents as tools. The MCP Apps extension, published on 26 January 2026, makes it possible to show interactive interfaces inside a conversation. The MCP specification asks that tool descriptions and annotations be treated as untrusted unless they come from a trusted server; a malicious server may try to steer the agent.

A2A: agent-to-agent communication

A2A (Agent2Agent) lets agents built on different frameworks discover each other, hand off tasks and share results. It was started by Google, and on 23 June 2025 the Linux Foundation launched A2A as its own project. Its steering committee includes Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP and IBM. Agents advertise their capabilities through an Agent Card. In commerce, A2A covers scenarios such as a shopping agent negotiating a return with a merchant’s order agent, or flight, hotel and transfer agents coordinating a trip. MCP solves agent-to-tool communication and A2A agent-to-agent; they complement each other.

ACP: an open standard for checkout

The Agentic Commerce Protocol (ACP) is an open standard created by OpenAI and Stripe, licensed under Apache 2.0 and currently in beta; Meta joined its technical steering committee in April 2026. The current stable version is 2026-04-17 and defines REST and MCP transports. Its building blocks are:

• Agentic checkout: checkout sessions, fulfilment options, totals and order creation.
• Cart and Feed API: cart and product feed interfaces added in version 2026-04-17.
• Delegated payment: passing payment credentials to the merchant as a scoped token without exposing them to the agent.
• Delegated authentication: in ACP this term refers to card authentication (3-D Secure 2), not user account linking.
• Order webhooks: order events signed with HMAC.
• Discovery document and idempotency: a /.well-known/acp.json discovery document and mandatory idempotency.

ACP’s design principle is that the merchant remains merchant of record. The deciding factor is distribution: if ChatGPT and Stripe infrastructure are the target, ACP is the natural candidate; ACP focuses on checkout and does not cover the content and discovery layer.

UCP: an end-to-end commerce standard

UCP is a Google-led open standard covering the whole shopping journey. Its capabilities are catalogue, cart, checkout, identity linking and order. Technically it supports REST and JSON-RPC transports, connections to MCP, A2A and AP2, and embedded checkout; capabilities are named in reverse-domain form such as dev.ucp.shopping.checkout, and the merchant remains merchant of record. The Shopping vertical is fully specified, Lodging is in draft and Food is listed as coming soon.

UCP is broader in scope than ACP, but its distribution is tied mainly to Google surfaces. The smart move for a merchant is to build one internal checkout service and connect ACP and UCP to it as adapters; providers such as Stripe offer infrastructure for both protocols.

AP2: proof of payment authority

AP2 answers the question “is the agent really acting on the user’s instruction?” with signed, verifiable digital credentials. In its current terminology there are two mandates: the Checkout Mandate, which defines what is being bought, and the Payment Mandate, which defines how and how much is paid. Each can be in an open stage, holding the user’s constraints, or a closed stage, holding the finalised transaction. This chain gives the parties a non-repudiable audit trail in a dispute. The Intent Mandate and Cart Mandate terms used in the original 2025 announcement are no longer used.

On 28 April 2026 Google moved AP2, together with Verifiable Intent developed with Mastercard, to the FIDO Alliance; AP2 version 0.2 also covers payments where the person is not present at the moment of transaction. The commercial significance is high, but every party (issuing bank, payment provider, merchant, agent provider) has to support it; coverage is limited today.

x402: machine-to-machine payment

x402 uses the HTTP 402 “Payment Required” status code to set up a simple flow: an agent requests a resource, the server replies with 402 and a price, the agent pays, and the server delivers the resource. It was developed by Coinbase; Cloudflare and Coinbase formed the x402 Foundation on 23 September 2025, and on 2 April 2026 the Linux Foundation launched the x402 Foundation under its umbrella, with supporters including AWS, American Express, Google, Mastercard, Microsoft, Shopify, Stripe and Visa. It suits the monetisation of digital content, data, APIs and agent services more than physical goods; a brand offering a product data API, for example, could charge agents per use.

The agent-ready maturity model

The agent-ready maturity model describes, in six levels, how ready a brand’s digital infrastructure is for SI agents. The level is not set by the name of the protocol you have adopted. It is set by how reliably an agent can find the brand, understand it correctly, send a buyer to it and complete a transaction. A level only counts as reached when its work has stopped being a one-off project and runs as a continuous process.

The model is deliberately sequential. A level 4 checkout integration does not work without level 2 price and stock consistency: the agent carries the wrong price into the cart, the order is cancelled, and the brand is marked as an unreliable source on that surface. This is a pattern that comes up often in agent readiness audits: teams race towards protocol headlines while the basic data layer falls behind.

As of October 2026, level 5 is at pilot and limited-scope stage in most markets. For most brands the realistic and profitable goal is to make level 2 permanent first, then move to levels 3 and 4 on the surfaces that have real traffic and order potential.

Eight capabilities of an agent-ready business

Maturity is not judged on a single indicator but on eight capabilities taken together. The weakest capability sets the level of the whole chain: a flawless catalogue API is useless behind a firewall that cannot tell agent traffic apart.

How to assess your own level

Assessment should rest on observation, not on what teams believe. There is often a gap between “we have schema” and what an agent actually reads from the page. The five steps below fit into one or two weeks.

1. Sample through an agent’s eyes: pick a sample of best sellers, highest-margin products and most-returned products, and inspect each page as raw HTML with JavaScript switched off.
2. Consistency test: compare price, stock, delivery time and returns terms on the page, in the structured data and in the feed. Every mismatch is a candidate reason for an agent to drop you.
3. Log review: pull 30 days of server or CDN logs and list which pages SI crawlers and agents requested and which status codes they received. Legitimate requests being blocked is the fastest win.
4. Prompt set: write the 30 to 50 questions customers in your category ask SI assistants and record how, and from which source, your brand is cited in the answers.
5. Transaction test: place an end-to-end test order on an agent-enabled surface where one exists; otherwise test whether your checkout can be completed by automation tools.

For a quick starting point, use Webtures’ free SI Agent Readiness scan. It brings access, structured data and machine-readability signals into one report and makes the gaps in the first three levels of the model visible.

Agent-ready technical implementation

Agent-ready implementation starts before any new protocol: it makes the existing stack readable, consistent and safe for agents. Most of the investment goes into basic data hygiene: a single source of truth, product information rendered on the server, complete structured data and a feed that updates quickly. Protocol integrations are then added on top of that foundation as adapters.

The reference architecture below is designed for a mid-size or large merchant. Smaller teams can build the same logic with an e-commerce platform’s built-in channels; the order of the layers and their responsibilities do not change.

Reference architecture: four layers and a side column

• SI surfaces: ChatGPT, Google AI Mode and Gemini, Microsoft Copilot, Meta, Perplexity, Amazon and marketplace assistants. You do not control them; you only control what you offer them.
• Discovery and identity layer: CDN, WAF and bot management; robots.txt and content usage signals; verification of signed agent requests.
• Agent gateway: adapters for ACP, UCP, MCP and A2A; OAuth scopes, rate limits, idempotency keys, request and schema validation. When a protocol changes, only this layer changes.
• Commerce core: product information management (PIM) as the single source of truth; the feed service; price, stock, shipping and returns rules; cart, checkout, orders and payment provider tokenisation.
• Data and observability (side column): event stream, agent attribution, fraud and risk engine, immutable audit log, error and latency monitoring. It takes data from every layer.

The architecture has five rules. The agent gateway must be a separate layer so protocol changes never touch the commerce core. The site, feeds, APIs and marketplaces must all use the same PIM data. Every call that creates an order or a payment must carry an idempotency key, because agents retry on timeouts and duplicate orders must not happen. The audit log must be immutable and must store agent identity and proof of authority. And because agent traffic can spike suddenly, rate limits and queues have to be designed together with clear error messages.

Access policy: robots.txt, CDN and bot management

An access policy states in writing which automated visitor may reach which page for which purpose. A single “block SI bots” switch is the wrong tool, because the same company runs separate agents for training, search and acting on a user’s behalf, and blocking each one has a different commercial consequence.

• Product, category and policy pages: open to search agents and agents acting for users. Closing them means not appearing in SI answers.
• Cart, checkout and account pages: do not need crawling; agents should reach these steps through a protocol or an authorised session.
• Admin, internal search results, filter combinations: keep closed; they create crawl load and duplicate content.
• Crawling for model training: decide according to business strategy, and decide it separately from search and agent access.

robots.txt is a request, not an enforcement mechanism. Real control sits in the CDN and WAF. Check the logs regularly to make sure rules at that layer are not blocking legitimate shopping agents by mistake; agent traffic often comes from data-centre IPs and browser automation, so classic bot rules catch it easily.

Product data and structured data

Agents trust structured fields more than marketing copy. For a product to be chosen by an agent, its identity, price, stock, variants, shipping terms and return policy must be readable by a machine with a single meaning.

• Unique identifiers: GTIN, MPN and SKU must match on every channel. When the same product carries different identities on the site, in the feed and on a marketplace, agents fail to match them.
• Offer fields: price, priceCurrency, availability and the product page URL must be separate and current for every variant.
• Variant structure: size, colour and material variants should be modelled as separate products, each with its own price and stock. In schema.org, ProductGroup and hasVariant express this relationship.
• Shipping and returns: mark up shipping cost, destination country, handling and transit time with shippingDetails (OfferShippingDetails), and the return window, method and fee with hasMerchantReturnPolicy (MerchantReturnPolicy).
• Technical attributes: give dimensions, weight, compatibility and material through additionalProperty with standard units. Text baked into an image does not exist for an agent.
• Server-side rendering: price and stock must be in the HTML without JavaScript. Many crawlers and agents read pages without rendering them.

How to write product descriptions agents can use is covered in product descriptions agents can read, and conversational enrichment of feed fields in our conversational attributes guide.

Feed architecture and update frequency

The product feed is the main way to distribute a catalogue to agent surfaces, and it should be generated directly from the PIM. A feed edited by hand or kept in a separate spreadsheet soon contradicts the site. Update frequency follows product volatility: categories where price and stock change during the day need incremental updates or API-based stock lookups.

Three principles shape feed design. The first is coverage: every sellable variant should be in the feed and unsellable ones removed on time. The second is consistency: the feed price must match the page and the checkout, or platforms may reject the product. The third is richness: agents filter by the question asked, so fields such as material, use case, compatibility and warranty decide which questions a product becomes a candidate for. Why stock accuracy matters more in the agent era is covered in one inventory truth for agentic commerce.

Machine-readable policy pages

Shipping, returns, warranty, instalments and delivery area are the fields agents check most often before deciding. If this information only lives in a PDF, an image or a pop-up, for an agent it does not exist. Write policy pages with short headings, tables and clear values, and repeat the same information in structured data and in the feed. Where terms differ by country or currency, state each one separately and explicitly.

llms.txt and Markdown alternatives

llms.txt is a proposal for listing a site’s most important pages in a short Markdown index for language models. It is a low-cost hygiene step, but Google states plainly that its SI features do not use llms.txt. It should therefore never come ahead of product data, the feed and page quality. Its value is helping several SI engines and agents find the right pages quickly.

Serving clean Markdown versions of pages, especially documentation, FAQs and policy pages, lets agents read plain text instead of HTML noise. Webtures applies this on its own site as a human and machine view: both versions of the same content are generated from one source, so they never drift apart.

Designing an agent API and MCP server

An API or MCP server opened to agents is designed differently from an API written for human developers. An agent does not read documentation and experiment; it decides by reading the tool name, description and parameter schema. Each tool’s purpose should be clear in one sentence, and its parameters should be limited and verifiable.

• Few, precise tools: single-purpose tools such as search_products, get_product, check_availability, create_cart and get_order_status give more reliable results than one tool that does everything.
• Separate reading from writing: read tools can run without authentication or with light authorisation; tools that create carts, orders or payments should require user authority and explicit approval.
• Meaningful errors: machine-usable error responses such as “out of stock, next restock date is X” let the agent suggest an alternative. A generic 500 error sends the agent to a competitor.
• Pagination and limits: paginate search results and keep responses small. An agent’s context window is limited, and unnecessary fields lower decision quality.
• Idempotency and retries: write tools should accept an idempotency key and return the same result when a request is repeated.
• Tool descriptions are untrusted input: the MCP specification asks clients to treat tool descriptions and annotations as untrusted unless they come from a trusted server. Keep descriptions on your own server short and factual, and never put instructions aimed at steering agents into product descriptions.

Identity and authorisation

The core security question in agentic commerce is who the requesting agent is, and on whose behalf it is allowed to do what. The question is answered on two layers. The agent’s own identity is proven with signed HTTP requests (Web Bot Auth) and platforms’ verified bot programmes. Authority on behalf of a user is granted through OAuth-based account linking and scoped tokens.

• Keep scopes narrow: reading the catalogue, writing a cart, creating a checkout and reading orders are separate scopes.
• Keep token lifetimes short, control refresh, and let users remove a connection at any moment.
• Require extra per-transaction approval at thresholds such as amount, category or first order.
• Write every authorisation decision to the audit log with both agent identity and user identity.

Checkout and payment integration

The right starting point for checkout is an internal checkout service that is independent of any protocol. Cart calculation, tax, shipping options, coupons, stock reservation and order creation are written once in that service; ACP, UCP or a platform channel then connects to it through an adapter. Adding a second protocol no longer means rewriting checkout logic.

On the payment side, the core principle is that the agent never sees card details. Payment providers and card networks solve this with tokens limited by amount, merchant and time. The merchant’s job is to get written confirmation of which agent payment programmes its payment provider supports, how 3-D Secure and strong customer authentication work in an agent scenario, and how chargeback liability is shared.

Performance and resilience

Agents are impatient and parallel. One agent can request dozens of product pages or API calls at once, and a slow source silently drops out of the comparison. Product pages and read APIs should be cacheable, write operations should be queueable, and an agent that hits a rate limit should receive a meaningful “retry later” response. Plan separate capacity for agent traffic during campaign periods.

Agentic commerce playbooks by platform

Platform playbooks set out the steps needed to be visible and sellable on each major SI surface. The common rule does not change: the discovery layer first (data, access, feeds), then referral and measurement, and checkout last. The decision table below gives the first step by goal; the subsections that follow give platform detail. Programme coverage varies by country, so check each platform’s current country list at every step.

Protocol selection decision table

ChatGPT playbook

Product results and comparisons in ChatGPT are powered by ACP, and since March 2026 OpenAI’s priority has been product discovery. The first job is therefore making sure your products appear in ChatGPT’s product results with correct information.

1. Confirm from your logs that OpenAI’s search crawler can reach your product and policy pages.
2. Review OpenAI’s merchant and product feed documentation; generate the feed from your PIM at a frequency that matches price and stock changes.
3. If you are on Shopify, check your Agentic Storefronts settings; orders arrive in the admin with ChatGPT referral attribution.
4. Track traffic from ChatGPT as its own channel in analytics; since purchases usually complete on your own checkout, the landing page experience is decisive.
5. If you want a richer brand experience, consider the ChatGPT app option; it is a development project and no substitute for catalogue hygiene.

Google AI Mode and Gemini playbook

Google’s agent surfaces rely on Merchant Center and Shopping Graph data, so Google readiness centres on the quality of your Merchant Center feed.

1. Complete identifiers and shipping and returns settings in the Merchant Center feed; check price and stock agreement between page and feed.
2. Enrich the attributes that decide which questions your products become candidates for. Watch Merchant Center’s SI performance reporting; detail in our Merchant Center AI performance insights guide.
3. If you sell in the US, Canada or Australia, assess UCP-based checkout eligibility through Merchant Center; the programme runs with selected merchants.
4. If you run a loyalty programme, plan to carry membership benefits into agent shopping through UCP Identity Linking.

Microsoft Copilot playbook

Copilot Checkout runs in the US through PayPal, Shopify and Stripe. Shopify merchants are enrolled automatically after an opt-out window, so the first job for brands on Shopify is to confirm or switch off that participation as a deliberate decision. Merchants on PayPal or Stripe should review their provider’s programme. For Shopify merchants who want an agent experience on their own site, the Brand Agents waitlist is a separate option.

Playbook for Shopify merchants

Shopify gives its merchants access to ChatGPT, Copilot, Google AI Mode, Gemini and Meta surfaces from one admin. That is a big convenience, but it does not remove the responsibility for control. Check regularly which channels are switched on, how product data looks in each channel and whether the order source is reported. Brands that do not run on Shopify can reach the same channels through Shopify Catalog with the Agentic plan; on that plan, direct checkout is off by default.

Amazon and marketplaces

Amazon’s agent weighs in-marketplace catalogue, content, review and logistics signals, and Buy for Me can buy from brand sites. For brands selling on Amazon the priority is complete catalogue content and stock accuracy; for brands not selling on Amazon it is a site clean enough for agents to read. The detailed framework is in becoming the seller Amazon agents choose.

Perplexity, Meta and other surfaces

Perplexity’s Merchant Program targets large retailers and is free; it can be an early testing ground for high-intent traffic. Access to Meta surfaces opens through Agentic Storefronts for brands on Shopify. Success on all of these surfaces depends on the same three variables: a structured catalogue, real-time price and stock, and fast, error-free responses.

The situation in Türkiye

As of 20 October 2026, Türkiye is not within the official scope of ChatGPT Instant Checkout, Google’s UCP-based checkout, Copilot Checkout or Stripe’s Shared Payment Token. The concrete payments step in Türkiye is the agent shopping demonstrated by Garanti BBVA with Mastercard in December 2025 and described as coming soon. No official announcement was found of local payment institutions (such as iyzico, PayTR, BKM Express or Param) supporting agent payment protocols. For Turkish brands the right order is: build the discovery and referral layer today, plan the internal checkout service and the payment provider conversation now, and enter supported channels in export markets today.

Measurement, attribution and unit economics

Measuring agentic commerce starts by making visible a chain that last-click models cannot see. An agent reads your product page, cites your brand in an answer, the user may click, the agent may start checkout directly, and the order may repeat months later. Classic analytics sees only the click; the rest either disappears into “direct” traffic or is never recorded at all.

The five-stage measurement chain

Each link in the chain needs one owner and one report. Retrieval and citation sit with marketing and SEO, the click with analytics, and checkout and repeat with e-commerce and CRM; but all of them should be read on the same dashboard.

Separating SI-referred traffic

The first step in separating SI-referred traffic is to group the referring domains of known SI surfaces into their own channel in analytics. The second is to include the source parameters platforms add, and the UTMs you add to your own links, in that channel definition. The third is to estimate traffic whose referrer has been lost: sessions with no referrer and no campaign that land deep on a product page form a pool with a high likelihood of being SI-referred. The method is set out in how to measure hidden traffic in SI search.

Log analysis completes the half that analytics cannot see. Requests are classified using SI crawlers’ user agents and verified IP ranges, which shows which products agents read often, which they never read, and which pages return errors. Products that agents read often but that do not sell usually point to a problem in price, stock or policy data.

An agentic commerce KPI set

• Agent access health: the share of legitimate SI crawler and agent requests that receive a successful response.
• Catalogue coverage: the share of sellable variants present and complete in the feed and in structured data.
• Consistency rate: agreement of price and stock across page, feed and checkout.
• Answer share: the share of answers on a fixed prompt set that cite the brand, and how accurate they are.
• SI-referred revenue: revenue from sessions coming from SI surfaces and from agent-assisted orders.
• Agent order quality: cancellation, return and dispute rates on agent-assisted orders, compared with other channels.

Unit economics: is an agent order profitable?

The profitability of the agent channel should be judged on contribution margin per order, not on revenue. The contribution of an agent order is the selling price minus product cost, payment provider fees, any platform transaction or referral fee, shipping, expected return cost and the channel’s operating cost. When every channel is calculated with the same formula, the agent channel’s real position becomes visible.

Three elements behave differently in the agent channel. The first is acquisition cost: organic citation needs no ad budget today, but it does need data and infrastructure investment, which should be allocated to the channel’s cost. The second is return risk: if the agent misreads the user’s intent, returns go up, so agent orders need their own return rate. The third is lifetime value: if the customer relationship stays on the platform, repeat purchase and cross-sell weaken. Without weighing all three together, the observation that “the agent channel converts well” should not be a reason to invest on its own.

The most robust planning method is your own data rather than external forecasts: measure SI-referred revenue as a share of total revenue every quarter, project from a four-quarter trend, and stage investment to match that trend.

Security, risk and law in agentic commerce

In agentic commerce, risk adds three new questions to the classic e-commerce ones: who the agent making the transaction is, whether the user really authorised it, and who is responsible when something goes wrong. This section is general information, not legal advice; work with your legal and payments advisers on specific integrations and contracts.

A threat model for agent commerce

Fraud rules need recalibrating for agent traffic. Classic signals (data-centre IPs, automation fingerprints, non-human speed) also appear in legitimate agents. Instead of “block if automated”, you need a layered model that asks whether the agent is verified, whether it holds authority, and whether its behaviour matches that authority. Payment details are covered in our protocol map and in the AP2 section above.

Allocation of liability: who is responsible for what?

An agent-mediated transaction has at least four parties: the user, the agent provider, the merchant and the payment chain (payment provider, card network, issuing bank). Protocols make it a principle that the merchant remains merchant of record, but how liability is shared when an agent picks the wrong product, a price is passed on incorrectly or a user denies an instruction is still largely left to contracts and card network rules. The practical conclusion for a merchant: every agent channel needs written terms on liability, data use, returns and disputes, and the audit log should be kept so that it can serve as evidence under those terms.

Consumer law and personal data

A sale made through an agent is still a distance sale under consumer law. In the EU and the UK, pre-contract information, order confirmation and withdrawal rights apply in the agent channel just as they do on a website; in Türkiye, Consumer Protection Law No. 6502 and the Distance Contracts Regulation set the same kind of obligations. How pre-contract information reaches the user inside an agent interface, and how consent is recorded, should be settled with your legal team before integration starts.

On personal data, GDPR and UK GDPR require you to define for what purpose and on what lawful basis customer data shared with an agent provider is processed. For Turkish customers, the Personal Data Protection Law (KVKK, No. 6698) asks the same questions, with separate rules for transfers abroad when the agent provider’s servers are outside Türkiye.

The EU AI Act and transparency

The transparency obligations in Article 50 of the EU AI Act (Regulation (EU) 2024/1689) have applied since 2 August 2026. They cover making sure people know when they are interacting with an SI system that talks to them directly, and marking certain synthetic content. A brand offering an SI sales assistant on its own site to EU consumers must make clear that the assistant is an SI system. For brands outside the EU selling into it, this is a compliance item of the export channel.

Payment regulation and strong customer authentication

Agent payments do not sit outside existing payment regulation. Strong customer authentication (SCA) rules under PSD2 apply in the EU and their UK equivalent in the UK; in Türkiye, Law No. 6493 and the Central Bank’s regulations apply; card payments follow card network rules everywhere. In practice this means the agent must hand the user over for authentication at certain steps. The merchant should get written confirmation from its payment provider of how 3-D Secure and one-time passcode flows work in an agent scenario and which transactions qualify for exemptions.

A written agent policy

Every agent-ready brand should define its relationship with agents in a one-page policy. The policy answers these questions: which agents get access to which pages and tools? At which amounts and in which categories is human approval mandatory? How do returns and disputes work on agent orders? What data is shared with agent providers, and for what purpose? Who owns the policy, and how often is it reviewed? The policy becomes the reference document both for internal teams and for conversations with platforms.

Commercial strategy: intermediary or brand?

The most important commercial question in agentic commerce is not technical: will agent surfaces become a distribution channel that strengthens your brand’s relationship with the customer, or an intermediary that reduces your brand to a line in a result? Both can happen at once. Which one wins depends on what data, what experience and what customer relationship the brand keeps in its own hands.

What merchant of record does, and does not, give you

ACP, UCP, Copilot Checkout and Shopify’s agent channels all stress that the merchant remains merchant of record. That matters: payment goes to the merchant, the invoice is issued in the merchant’s name, the return policy is the merchant’s and the customer record lands with the merchant. But being merchant of record does not mean the moment of discovery, the comparison screen or the trust the user places in the agent belong to the merchant. When a user says “find me the best one”, the agent chooses the brand; brand loyalty can give way to agent loyalty.

Three strategic postures

For most brands the right answer is a mix of these postures by category. “Be everywhere” makes sense for fast-moving and replenishment products, while keeping the transaction or building your own agent can be more defensible for high-value products that need personalisation.

Price parity and channel conflict

Agents compare prices in seconds. A product priced differently on your own site, on a marketplace and in an agent channel leads the agent to pick the cheapest channel and erodes trust in the others. Write a channel-level pricing and promotion policy before opening the agent channel. How agents read promotion data is covered in marking up discount and promotion data.

First-party data and loyalty

In the agent era, first-party data is a brand’s ability to know its own customer. How customer records, contact consent and loyalty links are created on agent orders should be decided at design stage. Making the loyalty programme readable by agents, so that points, member benefits and personal prices can enter the agent’s comparison, is one of a brand’s strongest cards against agents. This is explored further in sell-side agentic commerce.

Marketplaces and direct selling

Marketplaces sit on both sides in the agent era. Outside agents can bypass marketplaces and go straight to brands; marketplaces respond by building their own assistants and seller-side agents. The practical conclusion for brands is to feed marketplace catalogue data and their own site from the same PIM and use the same product identity in both channels. Whichever channel an agent arrives through, it meets the same correct information.

Organisation and a 12-month roadmap

Agentic commerce is not one department’s job; it needs marketing, e-commerce, product data, engineering, payments and risk, legal and analytics to work to the same calendar. When the programme has no single owner, the most common outcome is that every team finishes its own part and the chain as a whole does not work: the feed is ready but checkout is closed, or checkout is open but the payment provider does not support the agent scenario.

Roles and responsibilities

A 12-month roadmap

The roadmap below is designed for a mid-size brand starting at level 1 or 2. Durations vary with team capacity; the order should not. Each period ends with an exit criterion, and the larger investments of the next period wait until that criterion is met.

The most often skipped part of this calendar is the first three months. Teams want to start with a visible protocol integration; but a checkout channel opened before the data foundation is fixed leads agents to attempt orders with the wrong price and stock, and the brand loses trust on that surface.

A monthly report for leadership

Leadership should receive a one-page report every month. It covers the current maturity level and the target, a summary of the five-stage measurement chain, the agent channel’s contribution margin, open risks and important changes on platforms. Because the protocol and platform landscape changes quickly, a “what changed this month and how it affects us” line should be a permanent part of the report.

Agentic commerce sector scenarios

Agentic commerce does not move at the same speed or in the same way in every sector. How much an agent can decide on a user’s behalf depends on the product’s price, its need for personalisation, how easy returns are and the cost of a mistake. The scenarios below are written to compare sectors’ readiness priorities.

Fashion and footwear

In fashion the agent’s biggest problem is size. When a user says “I usually wear a 40”, the agent has to know whether the brand runs small or large and whether that variant is in stock. Offering the size chart as structured data rather than an image, marking fit information at product level and stating returns terms clearly are the first three steps to being agent-ready in fashion. Track the return rate on agent orders separately; a wrong size is a direct cost.

Electronics

In electronics, agents compare specifications line by line. Inconsistent model numbers and GTINs make one product look like several, or different products look the same. Compatibility (which device it works with, which accessory it needs) and warranty cover should be provided in structured form. Since user approval will remain part of the process for high-value products, a landing page built to let the person arriving from an agent confirm the comparison affects conversion.

Grocery and FMCG

Grocery is the category closest to rule-based autonomous buying: the same products are bought regularly and the cost of a mistake is low. What decides success here is real-time stock and substitution rules. The agent must know what it may offer instead of an out-of-stock product. Delivery windows and minimum basket conditions also need to be machine-readable.

Travel and hospitality

In travel, agents build multi-part plans: flight, accommodation, transfer. Giving the correct total price, including taxes and fees, from the start, structuring cancellation terms and making availability queryable in real time are critical. Agent-to-agent workflows (A2A) are among the earliest to matter in this sector. The sector’s SI transformation is covered separately in our super intelligence in travel and hospitality report.

B2B procurement

In B2B, agents take over procurement teams’ repetitive work: gathering quotes, reordering from approved suppliers, comparing price and lead time. Being agent-ready in this sector means contract prices, minimum order quantities and approval flows are accessible through an API. Identity and authority matter even more than in consumer commerce: it must be clearly defined on whose behalf, for which budget and which category the agent can order.

Notes for brands in Türkiye

Agent commerce in Türkiye is moving on two tracks. Marketplaces are rolling out their own SI assistants and seller-side tools, while global SI surfaces are used in Türkiye for discovery and research; the built-in checkout programmes of those surfaces do not yet cover Türkiye (details in the platform playbooks section). For Turkish brands the priority in the sector scenarios above is therefore to make the fields in each sector’s critical data column complete and consistent today; being able to join from day one when checkout opens depends on that preparation.

Common mistakes and checklists

Most mistakes in agentic commerce projects are not technical; they are mistakes of sequence and ownership. The list below sums up patterns that come up again and again in agent readiness assessments, with the right move for each.

Ten common mistakes

1. Starting with a protocol: entering a checkout integration while data is inconsistent. The right move is to tie page, feed and structured data to the same truth first.
2. Blocking or opening all SI crawlers with one rule: training, search and user-acting agents need separate decisions.
3. Not noticing the WAF is blocking legitimate agents: without regular log review, bot rules silently lose sales.
4. Loading price and stock only through JavaScript: agents that do not render see the product without price or stock.
5. Burying policies in PDFs or images: if shipping and returns information does not exist for the agent, the product drops out of the comparison.
6. Treating llms.txt as a visibility strategy: it is a low-cost hygiene step and no substitute for data quality.
7. Giving agents broad, long-lived authority: scopes should be narrow, tokens short-lived and thresholds clear.
8. Skipping idempotency: retried requests produce duplicate orders and return costs.
9. Not measuring agent orders separately: without an order source field, the channel’s profitability cannot be discussed.
10. Tying yourself to one platform: every integration built without a protocol-independent core gets rewritten for the next channel.

Technical checklist

• Price, stock and variant information is in the HTML of product pages without JavaScript.
• Product and Offer markup is complete for every variant; GTIN, MPN and SKU match across channels.
• shippingDetails and hasMerchantReturnPolicy are marked up; policy pages are written in text and tables.
• The feed is generated directly from the PIM and updated at a frequency that matches price and stock changes.
• robots.txt and CDN rules match the written access policy; legitimate agent requests receive successful responses in the logs.
• API or MCP tools opened to agents are narrowly scoped, paginated, idempotent and return meaningful errors.
• Write operations require scoped OAuth authority and extra approval above an amount threshold.
• The audit log stores agent identity, user identity and proof of authority.

Data and content checklist

• Page, feed and structured data consistency is checked monthly for best sellers and highest-margin products.
• Product descriptions state use cases, compatibility and limitations explicitly.
• Sizes, dimensions and specifications are provided as text and structured data, not images.
• Validity dates and terms of promotions and discounts are machine-readable.
• The category prompt set is defined and the brand’s place in answers is recorded monthly.

Payments, risk and legal checklist

• The agent payment programmes and token structure your payment provider supports are confirmed in writing.
• The 3-D Secure and strong customer authentication flow has been tested in an agent scenario.
• Fraud rules assess verified agent traffic separately.
• How pre-contract information, order confirmation and withdrawal rights are delivered in the agent channel is documented.
• Data shared with agent providers, its purposes and lawful bases are recorded.
• Liability, returns, disputes and data use clauses have been reviewed in every platform contract.
• A written agent policy is published and has an owner.

Measurement checklist

• SI-referred traffic is defined as its own channel group in analytics.
• Server or CDN logs are classified for SI crawlers and agents.
• An order source field separates agent-assisted orders.
• Return and dispute rates on agent orders are reported separately.
• The agent channel’s contribution margin is calculated with the same formula as other channels.

A one-page leadership assessment

Brands preparing for the year-end peak will find a shorter, calendar-based list in our peak season agentic commerce readiness checklist.

Example files and templates

The examples below are starting templates; domain names, paths and values are fictional. Adapt each file to your own access strategy, product data and legal requirements, and test it with the relevant validation tools before going live.

Example robots.txt: a category-based access policy

This example opens product and content pages to search and agents, keeps cart, checkout and account paths out of crawling, and shows a separate decision for model training. The Content-Signal line is the content usage signal proposed by Cloudflare; not every crawler recognises it, but it states your preference in a machine-readable way.

# Example access policy (adapt to your own strategy)
User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search?
# Example decision: no crawling for model training
User-agent: GPTBot
Disallow: /
Sitemap: https://www.examplebrand.com/sitemap.xml

When you write a separate group for a specific crawler, that crawler follows only its own group; the rules in the general group no longer apply to it. robots.txt is a request; real enforcement happens in CDN and WAF rules.

Example llms.txt skeleton

# Example Brand
> Example Brand makes running and outdoor shoes and sells across the UK and EU.
> Prices in GBP and EUR, delivery in 1-3 working days, 14-day returns.
## Products
- [Running shoes](https://www.examplebrand.com/running/): category, linked to the size guide
- [Size guide](https://www.examplebrand.com/size-guide/): fit notes, measurement table
## Policies
- [Shipping and delivery](https://www.examplebrand.com/shipping/): regions, times, costs
- [Returns and exchanges](https://www.examplebrand.com/returns/): window, method, exceptions
## Optional
- [About us](https://www.examplebrand.com/about/)

Example Product JSON-LD: offer, shipping and returns

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Running Shoe X1",
  "sku": "X1-42-BLACK",
  "gtin13": "5060000000009",
  "brand": { "@type": "Brand", "name": "Example Brand" },
  "image": "https://www.examplebrand.com/img/x1-black.jpg",
  "description": "Lightweight shoe with a breathable upper for everyday running.",
  "offers": {
    "@type": "Offer",
    "url": "https://www.examplebrand.com/x1-black-42/",
    "price": "119.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "GBP" },
      "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "GB" },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
        "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 3, "unitCode": "DAY" }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "GB",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 14,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

The GTIN only illustrates the format; real products need a valid number issued through GS1. For products with variants, model each variant separately with its own Offer and group them under a ProductGroup.

Example MCP tool definition

In MCP a tool is defined by its name, a human-readable title, a description the agent reads and an input schema written in JSON Schema. Annotations indicate that a tool only reads or can be safely repeated; clients do not treat these hints as evidence when they come from untrusted servers.

{
  "name": "search_products",
  "title": "Search products",
  "description": "Searches the catalogue. Returns only sellable variants, with current price and stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Product or feature to search for" },
      "max_price": { "type": "number", "description": "Maximum price in GBP" },
      "size": { "type": "string", "description": "Size, for example 42" },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20, "default": 10 }
    },
    "required": ["query"]
  },
  "annotations": { "readOnlyHint": true, "openWorldHint": false }
}

Tools that create carts or orders do not use readOnlyHint; they are designed to require user authority, an idempotency key and explicit approval.

Agentic commerce glossary

This glossary gives short definitions of the key terms used in the guide. For a longer list, see our agentic SI and agentic commerce glossary.

Agentic commerce FAQ

What does being agent-ready mean?

Being agent-ready means a brand’s products, prices and policies can be found, correctly understood, trusted and transacted with by SI agents. It is not a single file or protocol but an operating model made of an access policy, consistent product data, agent-facing tools, identity and authorisation, payment, performance, measurement and governance.

What is the first step in agentic commerce?

The first step is not a protocol integration but consistent product data. For best sellers, the page, the structured data and the feed must state the same price, stock, delivery time and returns terms. Then you write an access policy, confirm in the logs that SI crawlers get successful responses, and start measuring SI-referred traffic as its own channel in analytics.

Should I choose ACP or UCP?

The choice depends on your distribution goal. ACP is the natural candidate if ChatGPT and the Stripe ecosystem are the target, UCP if Google AI Mode and Gemini are. The most robust approach is not to choose one but to build a protocol-independent internal checkout service and connect ACP and UCP to it through adapters, so adding a new channel never means rewriting checkout logic.

Do I need llms.txt?

llms.txt is not required, and Google Search states plainly that it does not use it. It can still be added as a low-cost hygiene step that helps several SI engines and agents find important pages quickly. Product data, feed quality, server-side rendering and page speed always come before llms.txt.

Can brands in Türkiye sell through ChatGPT or Google agents?

As of 20 October 2026, Türkiye is not within the official scope of ChatGPT Instant Checkout, Google’s UCP-based checkout or Copilot Checkout. Turkish brands can be visible on these surfaces through discovery and referral and complete the sale on their own sites. Exporting brands can join these channels today in supported markets such as the US.

Who is liable when an agent places a wrong order?

Protocols keep the merchant as merchant of record, and under consumer law the sale is a distance sale between merchant and consumer. How liability is shared between the agent provider, the payment chain and the merchant when an agent picks the wrong product or a user denies an instruction depends largely on contracts and card network rules. Every agent channel therefore needs written contract clauses and an immutable audit log.

Why does agent traffic not show up in analytics?

Agents and SI crawlers mostly read pages without running analytics tags; those requests appear only in server and CDN logs. When a user clicks through from an SI answer, in-app browsers and copied links can lose the referrer. The fix is to combine log classification, a separate channel definition for SI surfaces and an order source field.

Should I block SI crawlers and agents?

Blocking or opening everything with one rule is wrong. Blocking search agents and agents acting for users means not appearing in SI answers and losing sales. Crawling for model training is a separate decision based on business strategy. A category-based policy is recommended: product and policy pages open, checkout and account pages tied to authorised sessions, internal pages closed.

How long does agentic commerce readiness take?

It depends on the starting level and team capacity. The guide’s 12-month roadmap puts foundations and visibility in the first three months, referral and the first channel in months three to six, transactability in months six to nine and scale and governance in the last quarter. Order matters more than duration: do not move to the checkout layer before the data foundation is fixed.

How do I measure my brand’s agent-ready level?

The level is measured by observation, not by assertion: inspecting product pages with JavaScript off, comparing page, feed and structured data, reviewing logs, recording SI answers on a fixed prompt set and running an end-to-end transaction test. For a quick start, Webtures’ free SI Agent Readiness scan brings access, structured data and machine-readability signals into one report.

Sources and next step

The dates and figures in this guide were checked against the primary sources below as of 20 October 2026. Protocol specifications change often, so read the current version at source before integrating.

Protocols: Agentic Commerce Protocol, ACP specification repository, OpenAI commerce documentation, Universal Commerce Protocol, Agent Payments Protocol (AP2), MCP versions, MCP Apps, MCP and the Agentic AI Foundation, A2A at the Linux Foundation, x402 Foundation at the Linux Foundation, Cloudflare on x402.

Google: UCP announcement (11 January 2026), UCP updates (19 March 2026), Universal Cart (19 May 2026), Merchant Center UCP checkout eligibility, AP2 announcement, AP2 and the FIDO Alliance, Google Search SI optimisation guide, Lighthouse agentic browsing.

OpenAI, Stripe, Microsoft, Shopify, Amazon, Perplexity: Instant Checkout announcement, Product discovery in ChatGPT (24 March 2026), Stripe ACP announcement, Stripe Shared Payment Tokens, Stripe Agentic Commerce Suite, Microsoft Copilot Checkout and Brand Agents, Shopify Agentic Storefronts, Shopify Help: Agentic Storefronts, Amazon Buy for Me, Alexa for Shopping, Perplexity Shop like a Pro.

Payment networks: Visa Intelligent Commerce, Visa Trusted Agent Protocol, Visa Intelligent Commerce Connect, Visa and OpenAI, Garanti BBVA and Mastercard.

Access and identity: Cloudflare Content Signals Policy, Cloudflare Search, Agent and Training options, Cloudflare on mixed-use crawlers, Web Bot Auth, Cryptographic signatures for verified bots.

Market data: Adobe, 2025 holiday season, Adobe, SI traffic and machine readability (16 April 2026), HUMAN Security, AI agent traffic statistics, Checkout.com, Agentic Commerce 2026.

Regulation: EU AI Act, Regulation (EU) 2024/1689; the 2 December 2026 transition for Article 50(2) for systems already on the market was introduced by Regulation (EU) 2026/1744.

Related reading

To go deeper, see our agentic commerce protocol map, sell-side agentic commerce, the agentic commerce readiness report and agent-native transformation.

Let’s assess your agent-ready level together.

Run the free SI Agent Readiness scan to see where your brand stands with SI agents, explore our agentic commerce readiness service for a programme from discovery to checkout, or book a conversation with our team.