A customer may soon reach your business through an interface you do not control, carrying a request assembled by an AI agent rather than typed into your website.
The agent might compare options, check stock, prepare a basket or initiate a payment within limits set by its user. That changes more than the acquisition channel. It changes how your business explains an offer, verifies authority, fulfils a promise and resolves a dispute.
The person remains the customer. The agent becomes an intermediary acting on their behalf, with varying degrees of authority. That distinction matters: an agent that can read a catalogue should not automatically be allowed to buy, change an address or request a refund.
This week's useful question is not whether agentic commerce will replace the website. It is whether your organisation can serve this new intermediary without losing control of the customer relationship.
Five developments make that a practical question. They span current platform documentation, earlier protocol launches, industry research and a payment-security announcement published this week. They are signals of direction, not a measured ranking of market popularity or proof of commercial success.
Five signals behind the shift
1. Product discovery is becoming a structured-data task. OpenAI's current Agentic Commerce Protocol documentation describes an open standard connecting merchants with shoppers in ChatGPT. It highlights structured catalogue data, inventory and contextual product discovery. For a business, the implication is simple: attractive product pages are not enough if the underlying feed is incomplete, contradictory or stale.
2. Interoperability is moving beyond bespoke integrations. Google's 11 January 2026 explanation of Universal Commerce Protocol describes a common language for commerce capabilities, including discovery and checkout, with options for APIs, A2A and MCP. It also describes integration with existing retail infrastructure and payment providers. This is a protocol design, not evidence that every platform implements every capability consistently. Leaders still need to check supported versions, transports and deployment constraints.
3. Delegated payments are acquiring more explicit boundaries. On 28 September, IDEMIA Secure Transactions announced an agentic commerce solution for domestic schemes, regional networks and private-label issuers. Its stated capabilities include tokenised credentials, passkey-based authentication, restrictions by merchant, amount, category or time, and proof of consent available for later disputes. These are supplier claims about the solution, not independently verified adoption or outcomes. The important signal is the attention to authority and evidence, not merely transaction speed.
4. Service policies are becoming inputs to shopping decisions. Microsoft's current agentic commerce guidance describes UCP-ready product feeds and richer signals such as returns and support policies. It also says Copilot Checkout preserves the merchant as merchant of record. The page specifies eligibility constraints, including English-language merchants selling to US buyers in USD. This is not a universal channel available to every UK business, but its design makes customer support part of commerce readiness.
5. Trust and merchant readiness are becoming leadership concerns. Visa's analysis, updated on 5 July 2026, argues that consumer control, secure payment infrastructure and merchant integration matter as much as agent capability. It cites research reporting that 63% of merchants were exploring or planning agentic AI payments. That figure measures intention, not operational readiness. It is a reason to investigate the gap, not to assume competitors have already solved it.
Together, these signals point to a familiar transformation problem with a new interface: systems, policies and teams must agree about what the business can actually deliver.
Make the offer understandable to a machine
A human shopper can sometimes work around poor information. They may read a description, inspect a photograph, compare a sizing chart and ask an adviser a question. An agent needs reliable attributes and a way to recognise uncertainty.
Start with the offer, not the chatbot. Product identifiers, variants, prices, taxes, availability and delivery conditions need clear definitions. A "delivery from Friday" message means little unless the system knows the destination, stock location, cut-off time and relevant fulfilment rules.
The same applies to services. A subscription needs explicit renewal terms, cancellation conditions and eligibility. A service appointment needs location coverage, availability and a clear distinction between a quotation and a confirmed booking.
The operational risk is not simply that an agent describes a product badly. It may construct a confident recommendation from inconsistent sources. A product feed might show one price, checkout another, and a support article an obsolete returns policy.
Give each material fact an accountable source. Decide how frequently it changes, who maintains it and how stale data is detected. Where a fact cannot be confirmed, expose that uncertainty rather than let a downstream interface turn it into a promise.
This is digital transformation work in a precise sense. It requires agreement between commercial teams, product information, fulfilment and customer service. A feed adapter cannot compensate indefinitely for contradictory business rules.
Separate agent identity from permission to act
Recognising an agent does not prove that it may act for a particular customer. Nor does permission to perform one task imply permission to perform another.
An agent could be legitimate but hold an expired instruction. A customer might have authorised a purchase up to a fixed amount but not a substitute product. A delivery address change might be acceptable before dispatch and unsafe afterwards.
Treat these as distinct checks: who or what is making the request; whose account is involved; what authority has been granted; whether it remains valid; and whether the requested action falls within it.
Payment infrastructure can help. IDEMIA's announcement describes restricted-use credentials and retained proof of consent. That is useful direction, but payment approval should not be mistaken for authorisation over every connected customer-service action. Reading an order, cancelling it and obtaining a refund involve different rights.
For a pilot, write the delegation boundaries in plain language before implementing them. Which actions require fresh confirmation? Which can proceed within a standing instruction? What happens when an agent changes its plan? How does the customer revoke access?
Then test the boundaries. An otherwise valid request should fail safely when it exceeds the allowed amount, uses the wrong merchant, arrives after expiry or seeks an unapproved substitution. The goal is not maximum autonomy. It is behaviour that matches what the customer actually authorised.
Keep responsibility when the interface moves elsewhere
An external shopping surface may own the conversation, but it does not necessarily own the consequences.
In its 29 September 2025 Instant Checkout launch explanation, OpenAI said merchants accept or decline orders, process payments and handle fulfilment and customer support through their existing systems. That historical explanation should not be read as a complete statement of current availability. It is useful evidence of the operating boundary: a different front end need not remove the merchant's responsibilities.
Microsoft's current guidance similarly preserves the merchant-of-record role. Leaders should therefore resist treating agent-led purchases as somebody else's service channel.
If a customer disputes a charge, a support adviser needs an intelligible record of the order, the terms presented, the consent captured and the actions completed. A transcript alone may not show whether the customer approved a particular product, quantity or delivery option.
Build the evidence into the transaction. Link the request to the confirmed offer and resulting order. Retain the appropriate versions of material terms under a defined retention policy. Make records accessible to authorised staff without giving every adviser unrestricted access to payment or identity data.
Also provide a route for the person to regain control. Customers should be able to inspect an order and seek help without reconstructing an agent's internal conversation. The service relationship must remain understandable even if the agent is unavailable.
Do not make protocol adoption the whole strategy
ACP and UCP offer useful ways to connect participants. They do not eliminate the need to design a dependable internal operation.
A business may support one platform through an approved commerce partner and another through a different integration. Coverage, eligibility and commercial terms can differ. A feature in a protocol specification may not yet be offered by the chosen channel.
The architectural priority is a stable internal account of products, orders and permitted actions. External adapters should translate into that account rather than become separate sources of business truth.
That does not mean every company needs an ambitious new commerce platform. Smaller businesses may reasonably use a provider's supported integration. The requirement is to understand what it handles, what remains your responsibility and how you will leave if it no longer fits.
Before choosing a route, ask about version support, error handling, duplicate requests, payment reconciliation, refunds and audit records. An apparent network failure should not create a second order when an agent retries. A successful payment should not hide a failed fulfilment update.
These are conventional engineering concerns. Their importance increases when software, rather than a person watching a screen, initiates the next action.
Give the pilot a business owner
Agentic commerce crosses acquisition, operations, payments, security and customer service. If nobody owns the complete journey, each team can optimise its part while the customer inherits the gaps.
Assign one accountable business owner and a small cross-functional team. Commercial leadership should define the offer and acceptable economics. Operations should own fulfilment. Security and payments specialists should define the authority and evidence requirements. Customer service should help specify exceptions and recovery.
Technology leadership must make the boundaries executable, but should not silently choose the business policy. Whether to accept a substitution, honour an old price or permit a cancellation is an operational decision with technical consequences.
Agree the success measures before launch. Conversion is relevant, but it is not enough. Track incorrect orders, pricing discrepancies, failed fulfilment, repeat contact, refunds, disputes and time spent resolving exceptions. Compare those measures with the existing channel where the comparison is meaningful.
Include the cost of operating the channel: integration maintenance, payment and platform charges, fraud controls, support work and manual reconciliation. A channel can generate sales while worsening the economics of serving them.
Visa's distinction between merchant interest and readiness is helpful here. A leadership team should be able to show what works, under which conditions, rather than merely say that an integration has been enabled.
A 30-day readiness exercise
Choose one product range or simple service, one channel and a limited set of actions. Avoid beginning with subscriptions, discretionary exceptions or complex fulfilment unless those are the actual business requirement.
Week one: inspect the promise. Compare product data, checkout rules and support policy. Find contradictions in prices, variants, delivery, returns and cancellation. Identify the system and owner responsible for each fact.
Week two: define authority and recovery. Specify what the agent can read or do, what requires customer confirmation and what evidence must be retained. Design a route for the customer to inspect, cancel where permitted and seek human help.
Week three: test realistic failures. Use a controlled environment where available. Try expired consent, unavailable stock, a changed price, duplicate submission, an interrupted payment and a failed order update. Confirm that the customer and support team see a coherent result.
Week four: review the operating case. Examine fulfilment accuracy, exception workload and service costs, not just successful checkouts. Decide whether to expand, narrow the scope or stop. Document the reasoning so that enthusiasm for a channel does not become a substitute for evidence.
Not every business needs to transact through an agent immediately. Cleaning product data, clarifying support policies and improving order records can be worthwhile preparation even when channel eligibility or demand is uncertain.
For the broader operational questions, the site's customer experience AI page is the primary next step. The recent article on AI customer-service handoffs addresses a related but different boundary: how work moves from your AI-supported service to a human team.
Serve the customer, not just the agent
The commercial opportunity is real enough to investigate, but readiness should not be confused with accepting every automated request.
A dependable business can explain its offer accurately, distinguish identity from authority, execute a permitted transaction once and resolve the aftermath. Those capabilities matter whether the request arrives through a website, a person or an AI intermediary.
The leadership task is to make the service coherent across that new boundary. Protocols and payment tools can support it. They cannot supply missing ownership, contradictory policy or reliable fulfilment.
Start with one offer and one bounded journey. Prove that the customer can understand what happened and that your team can put things right. That is a stronger foundation for agentic commerce than a checkout demonstration alone.