Posted by Mahdi
Agentic Commerce Is Coming: Is Your eCommerce Platform Ready for AI Shoppers?
Learn how to prepare Shopify, commercetools, or Adobe Commerce for AI shopping agents with structured data, APIs, UCP, MCP, and checkout controls.
The checkout page is no longer the only place a purchase can happen. In an August 2026 a16z interview, Stripe President of Technology and Business Will Gaybrick discussed why checkout pages could eventually disappear as commerce becomes more agent-led. The important word is eventually. Most businesses still need an excellent storefront and checkout today, but they should also prepare for purchases that begin and finish somewhere else.
That second route is taking shape now. Google has launched the Universal Commerce Protocol (UCP). Shopify is connecting merchants to AI shopping surfaces. commercetools exposes governed commerce tools through MCP. Adobe Commerce has committed to UCP and ACP support. Stripe and OpenAI have already demonstrated in-conversation checkout patterns.
For Australian businesses, this is not a reason to replace a working commerce platform or rush into autonomous purchasing. It is a reason to ask a sharper question: can your systems provide an authorised agent with the same accurate product, price, stock, checkout, and post-purchase information that a human shopper expects?
This guide explains what agentic commerce changes, where CMS and PIM data fit, how UCP and MCP differ, why composable architecture helps, and what teams using Shopify, commercetools, or Adobe Commerce should prepare in 2026.
The Storefront Journey Now Has an API-Led Companion
The newer journey does not remove the website. Both paths depend on the same product truth, commercial rules, payments, fulfilment, and customer service underneath.
Website-Led Commerce
Google → Website → Site Search → Product Page → Cart → Checkout
The merchant controls the interface. Pages, navigation, merchandising, content, and checkout guide a person from discovery to purchase.
Agent-Led Commerce
Customer → AI Agent → Product Discovery → Commerce API → Purchase
The agent may control the interface, while the merchant still controls product truth, pricing, availability, transaction rules, fulfilment, and the order.
What Agentic Commerce Means in Practice
Conversational commerce helps a shopper ask questions. Agentic commerce goes further: software can discover products, compare options, assemble a cart, request a price, select fulfilment, present terms, initiate payment, and retrieve order information on the shopper's behalf.
The distinction is important because an agent is not simply another website visitor. A browser can render a product page designed for people. A commerce agent needs dependable facts and callable actions. If it has to infer a variant from an image, scrape a promotion from a banner, or guess whether stock is current, the journey is fragile.
In 2026, the sensible planning assumption is coexistence. A shopper may research through an AI assistant and complete on the merchant's site. Another may use an embedded checkout inside an AI surface. A complex order may start with an agent but require a person to confirm delivery, identity, finance, or product configuration. Platform support and regional availability will also vary.
The business goal is therefore not to remove people from buying. It is to let authorised systems perform appropriate parts of the journey without losing accuracy, control, or accountability.
UCP, MCP, and APIs: What Each Layer Does
Protocols can make agentic commerce sound more complicated than it needs to be. Think of the stack in three layers.
APIs expose business capabilities
Your commerce APIs remain the execution layer. They answer questions such as: Which variants exist? What is the current price? Is this item available for a Sydney postcode? Can a promotion apply? Which delivery options are valid? Can the cart be completed? What is the order status?
MCP exposes approved tools and context
Model Context Protocol (MCP) is a general way for an AI system to discover and invoke tools or retrieve context. A commerce MCP server might offer a read-product tool, a cart tool, or an order lookup tool. The commercetools Commerce MCP documentation, for example, covers product retrieval, carts, orders, customer data, configurable tools, and field filtering.
UCP defines a shared commerce language
UCP is commerce-specific. Google describes it as a common language across consumer surfaces, businesses, and payment providers. The official UCP documentation lists catalog search and lookup, cart building, identity linking, checkout, and order management. It uses REST and JSON-RPC transports and includes support for MCP, A2A, and AP2 interoperability.
UCP is not a replacement for your commerce platform, CMS, PIM, payment provider, or APIs. It is a standard contract above those systems. Your platform still needs to calculate the right price, enforce the right promotion, reserve or validate stock, create the order, and manage fulfilment. UCP is designed so the business remains merchant of record and keeps its business logic and customer relationship.
ACP, co-developed by OpenAI and Stripe, is another emerging commerce protocol. Platform providers may abstract some of these standards for merchants. Before building a custom protocol layer, check what your commerce and payment vendors support, in which markets, and with which limitations.
Agent Readiness Starts With Structured Product Content
An agent cannot reliably act on information it cannot identify. Product facts hidden inside hero banners, PDFs, image text, page-builder blocks, or free-form descriptions may be readable to a person but difficult to validate and transact against.
A useful product model separates at least:
- Identity: product, variant, SKU, GTIN or other identifiers, brand, category, and canonical URL.
- Attributes: size, colour, material, dimensions, compatibility, ingredients, capacity, technical specifications, and use constraints.
- Commercial data: currency, GST-inclusive price where applicable, customer-group pricing, promotion conditions, start and end dates, and minimum quantities.
- Availability: stock state, location or channel availability, lead time, back-order rules, and substitution options.
- Fulfilment: delivery methods, costs, postcode restrictions, pickup options, estimated timing, and dangerous-goods or bulky-item constraints.
- Policy and proof: returns, warranty, care, certifications, reviews, FAQs, evidence for claims, and seller information.
The CMS, PIM, commerce engine, ERP, and order system should not each maintain their own version of these facts. Define ownership. The CMS may own editorial guidance and brand narrative. The PIM may own enriched specifications and relationships. The commerce platform should usually own live pricing, promotions, carts, and checkout rules. ERP, warehouse, or order systems may own fulfilment and availability inputs.
Then publish derived outputs—product pages, structured data, feeds, search indexes, and agent APIs—from those sources. VaniTech's guide to keeping AI shopping product data fresh explains how to reconcile pages, schema, feeds, stock, and checkout. For the discovery layer, see SEO, GEO, and AEO for commerce product pages.
Why Headless and Composable Commerce Help—But Do Not Guarantee Readiness
Headless commerce separates the customer interface from commerce services. Composable commerce goes further by assembling replaceable capabilities—CMS, PIM, search, promotions, checkout, payments, OMS, loyalty, and analytics—through APIs and events.
That is a useful starting point for agentic commerce because the capabilities already exist independently of a particular web page. An agent can call a product search service or checkout service without pretending to click a menu. A new AI channel can be added without rebuilding the entire storefront.
But headless is an architecture pattern, not a readiness badge. A headless build can still have duplicated prices, undocumented APIs, inconsistent identifiers, excessive permissions, slow inventory updates, and brittle orchestration. Agent readiness requires production-grade contracts around those services:
- stable identifiers and versioned schemas;
- clear read and write boundaries;
- scoped authentication and authorisation;
- validation, idempotency, timeouts, retry rules, and rate limits;
- events or webhooks for material changes;
- audit logs and correlation IDs across agent, gateway, commerce, payment, and order systems;
- fallbacks when an agent, protocol, or upstream service fails.
If your stack is tightly coupled, do not replatform only to claim agentic readiness. First isolate the highest-value capabilities behind stable interfaces. The broader principles are covered in VaniTech's composable architecture and AI guide. Payment architecture also deserves separate review; see our comparison of payment gateway options for headless commerce.
What Shopify, commercetools, and Adobe Commerce Teams Should Do Now
Use native capabilities where they fit, but verify availability and keep your own source data, policies, and integration controls clean.
Shopify
Review product categories, variants, identifiers, metafields, policies, and inventory accuracy before expanding AI channels. Shopify says supported integrations are managed through Agentic Storefronts and backed by Shopify Catalog and checkout. Confirm channel eligibility, market availability, merchandising controls, attribution, and whether purchases finish in conversation or on your store.
commercetools
Treat product types, attributes, prices, inventory, carts, discounts, customers, and orders as governed capabilities. Start Commerce MCP with the smallest tool set and read-only access where possible. Use separate API scopes, redact unnecessary fields, test extensions and asynchronous processes, and only enable cart or order writes after approval and audit controls work end to end.
Adobe Commerce
Audit catalog structure, product content, pricing, inventory, storefront APIs, checkout customisations, and order-management endpoints. Adobe has committed to UCP and ACP support and is moving toward machine-readable catalog, price, and inventory access. Confirm the release path for your Adobe Commerce deployment and ensure custom extensions do not bypass standard services or controls.
Checkout Is an Authorisation Problem, Not Just a User-Interface Problem
A human checkout page performs more work than it appears to. It collects identity and delivery information, presents terms, recalculates totals, applies discounts, checks availability, obtains consent, invokes payment, runs fraud controls, creates an order, and provides confirmation. Moving the interface into an AI conversation does not remove those responsibilities.
Design agent access as a ladder of permissions:
- Discover: search products and read public policies.
- Validate: retrieve a current price, availability, delivery option, or loyalty eligibility.
- Prepare: create or update a cart without spending money.
- Commit: complete checkout only with explicit authority, bounded totals, approved payment handling, and replay protection.
- Support: retrieve an order, track fulfilment, request a return, or escalate to a person under separate permissions.
Each step should have its own authentication, allowed fields, rate limits, approval rules, logging, and failure behaviour. Do not give a discovery agent a broad admin credential. Do not let a probabilistic model calculate the authoritative price or tax. Do not rely on prompt wording as a security control. Deterministic commerce services should validate every action.
Stripe's Agentic Commerce Protocol announcement describes scoped payment tokens and merchant-side control over order acceptance, tax, fulfilment, and returns. UCP likewise keeps the merchant's business logic intact. These patterns point to a practical rule: the agent can orchestrate the journey, but the merchant's systems must remain authoritative.
An Agentic Commerce Readiness Checklist
Score each layer as ready, partial, or blocked. A pilot should not proceed to purchasing while a material control is blocked.
| Layer | Questions to answer | Evidence of readiness |
|---|---|---|
| Product truth | Are product and variant identifiers stable? Are specifications structured? Are claims supported? | Documented models, validation rules, completeness reports, and named data owners. |
| Price and inventory | Can an agent retrieve a current, channel-correct price and availability state? | One authoritative calculation path, freshness targets, reconciliation, and mismatch alerts. |
| Policies | Are delivery, returns, warranty, subscription, promotion, and eligibility rules machine-readable? | Structured policy fields, versioning, effective dates, and human-readable equivalents. |
| APIs and protocols | Which actions are available through APIs, MCP, UCP, ACP, or platform connectors? | Versioned contracts, sandbox access, authentication, field filtering, and documented limitations. |
| Checkout and payment | Who confirms the purchase? How are totals, consent, fraud, tokens, and retries controlled? | Explicit authorisation, idempotency, scoped credentials, deterministic validation, and safe failure states. |
| Post-purchase | Can the customer track, change, cancel, return, or escalate the order? | Order APIs, policy enforcement, status events, service handoff, and traceable communications. |
| Governance | Who owns data, access, monitoring, incidents, privacy, and channel decisions? | Named owners, audit logs, dashboards, approval thresholds, incident playbooks, and rollback. |
The score is less important than the evidence. A vendor setting marked “enabled” is not proof that prices are fresh, permissions are narrow, or post-purchase exceptions work.
Australian Consumer, Privacy, and Operational Controls Still Apply
An AI channel does not reduce the need for accurate commerce information. The ACCC says product and service information must be accurate and truthful, including prices, images, descriptions, benefits, shipping options, and delivery times. If an agent presents a stale price or invents a delivery promise from inconsistent source data, the fact that a third-party interface displayed it does not make the customer impact disappear.
Privacy also needs to be designed into identity linking, personalisation, saved addresses, loyalty, and order support. The OAIC's AI privacy guidance says privacy obligations apply when AI systems handle personal information for organisations covered by the Privacy Act. It recommends due diligence, transparency, human oversight, regular review, and privacy-by-design.
Practical controls include:
- share only the customer data required for the current task;
- separate public catalog access from authenticated account and order access;
- record consent and the authority given to an agent;
- define retention, disclosure, and deletion responsibilities across providers;
- provide a clear human support and dispute path;
- review contracts, privacy notices, payment obligations, and consumer-law implications with appropriate advisers.
Agentic commerce should make a purchase easier to complete, not harder to understand, reverse, or resolve.
A Practical 90-Day Preparation Plan
Days 1–30: Map the truth and the journey
- Choose one product category and map both the website-led and agent-led journey from discovery to support.
- List every source for product, variant, price, inventory, promotion, delivery, returns, customer, payment, and order data.
- Name the authoritative system and owner for each field.
- Measure mismatches across product page, structured data, feed, search index, cart, and checkout.
- Document which AI surfaces and platform capabilities are actually available for your market and account.
Days 31–60: Strengthen interfaces and controls
- Refactor high-value product facts and policies into structured fields.
- Stabilise identifiers and API contracts for catalog, price, inventory, cart, and order lookup.
- Create separate credentials and scopes for public discovery, authenticated read, cart write, checkout, and post-purchase actions.
- Add idempotency, validation, rate limits, logs, correlation IDs, alerts, and safe fallbacks.
- Build a test set covering stale stock, price changes, invalid variants, restricted delivery, promotion conflicts, payment failure, duplicate requests, cancellation, and return exceptions.
Days 61–90: Pilot one bounded use case
- Start with read-only product discovery or price-and-stock validation for a limited catalog.
- Compare agent answers with the authoritative systems and customer-facing page.
- Track data mismatch, API failure, latency, fallback, human intervention, cart completion, payment decline, fraud review, cancellation, return, and attribution.
- Add cart creation only after discovery is reliable. Add purchase only after authority, payment, fraud, and order recovery controls pass.
- Review the pilot with commerce, content, security, privacy, customer service, finance, and fulfilment owners before expanding.
This sequence creates useful capability even if agent-led checkout adoption moves slowly. Better product models, APIs, observability, and governance improve the website, feeds, marketplaces, support, and internal operations too.
Frequently Asked Questions
Short answers for commerce, content, and technology teams planning their next steps in 2026.
Sources Checked
- The a16z Show: Stripe's AI Strategy—Build More, Not Less
- Google: New tech and tools for retailers to succeed in an agentic shopping era
- Universal Commerce Protocol official documentation
- Google: AI shopping gets simpler with Universal Commerce Protocol updates
- Stripe: Instant Checkout and the Agentic Commerce Protocol
- Shopify: The agentic commerce platform
- commercetools documentation: Commerce MCP
- Adobe: Adobe Commerce commits to agentic commerce standards
- ACCC: False or misleading claims
- OAIC: Guidance on privacy and commercially available AI products
Make Your Commerce Stack Ready for People and Agents
VaniTech can help audit product and content models, map system ownership, strengthen commerce APIs, and design a staged agentic-commerce pilot with practical controls.