Agentic Commerce: Making a Subscription Store Usable by AI Shopping Agents

When the Customer Is Software

For most of my career the question "who is the customer?" had a simple answer: a person, on a device, looking at a page we designed. Agentic commerce changes that. An AI assistant acting for a person can now read your product pages, compare you with three competitors, fill a basket and, increasingly, pay. The person still pays, but the thing interacting with your store never sees your hero banner.

For a one-off retailer this is mostly a discovery and conversion problem. For a subscription business it is harder, because the purchase is not a single event. It is an agreement to take money repeatedly, with delivery schedules, skips, pauses and a cancellation path that regulators care about a great deal. When I was CTO at Freddie's Flowers, the most sensitive parts of the platform were never the checkout button. They were recurring billing, the consent records behind it and the flows that let people change their minds: exactly the parts an agent will touch.

This post is how I would think about it now, in October 2026, for a mid-size subscription store: what genuinely changes, what you can do cheaply today, and what is worth waiting for.

What Actually Changes

Three things change when an agent sits between you and the customer.

Your persuasion layer stops working. Agents do not respond to urgency banners, lifestyle photography or a carefully ordered pricing page. They extract facts: price, recurring price, delivery days, what happens if you skip, how to cancel. If those facts are buried in a modal or only in an FAQ, the agent either guesses or picks a competitor whose terms are clearer.

Ambiguity becomes a liability. A human skims "from £X per box" and clicks through to find out. An agent asked to "find me a flower subscription under £30 a month" needs to calculate the monthly cost reliably. An introductory discount that silently reverts is a trap for a person and a source of wrong answers for an agent.

Identity gets a third party. Today you authenticate a person. Tomorrow you also need to know which agent is acting, for whom, and with what permission. "The customer clicked confirm" is no longer the whole story.

Machine-Readable Offers First

The cheapest and most durable thing you can do is publish clean, structured data about what you sell. Agents and search engines read it, and it forces you to write your terms down unambiguously.

schema.org gives you most of what you need. Product and Offer are familiar, but subscription stores rarely use the parts that matter: UnitPriceSpecification with billingDuration for the recurring charge, OfferShippingDetails for delivery areas, and MerchantReturnPolicy for refunds.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Weekly Seasonal Flower Box",
  "sku": "FLOWER-WEEKLY-STD",
  "description": "Seasonal stems delivered weekly. Skip, pause or cancel online at any time before the weekly cut-off.",
  "offers": {
    "@type": "Offer",
    "price": "30.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "priceSpecification": [
      {
        "@type": "UnitPriceSpecification",
        "price": "15.00",
        "priceCurrency": "GBP",
        "name": "First box introductory price"
      },
      {
        "@type": "UnitPriceSpecification",
        "price": "30.00",
        "priceCurrency": "GBP",
        "name": "Recurring price per box",
        "billingDuration": { "@type": "QuantitativeValue", "value": 1, "unitCode": "WEE" },
        "billingStart": 2
      }
    ],
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "GBP" },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "GB",
        "postalCodePrefix": ["E", "N", "SE", "SW", "W"]
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "GB",
      "returnPolicyCategory": "https://schema.org/MerchantReturnNotPermitted"
    }
  }
}

The numbers here are illustrative. The point is that the introductory price, the recurring price, the cadence and the delivery area are each stated once, as data. schema.org has no first-class property for "how to cancel", so I put the cancellation terms in plain, specific language in the description and link to a stable, crawlable terms page that does not require login or JavaScript to read. Agents read prose well; what they cannot do is read terms that only render after a cookie banner and three clicks.

Beyond on-page markup, keep a product feed current. Treat it as a first-class output of your catalogue rather than a marketing export, and include the recurring price and cadence, not just the headline price. Several assistant platforms ingest merchant feeds, and the specification differs per platform, so build one canonical internal model and generate each format from it.

APIs Versus Agents Driving Your UI

Right now most agents interact with stores the way a person would: they load pages, read the DOM or a screenshot, and click. That works often and fails invisibly. A redesigned checkout, an A/B test that moves the delivery date picker, or a bot challenge on the payment step, and the agent is stuck or, worse, completes the wrong thing.

The alternative is to give agents a proper interface. The useful surface for a subscription store is small:

If you already separate your API from your website, as I argued in API and website isolation, most of this is a thin layer over endpoints you have. The real work is in the quote: a single call that returns exactly what the person will be charged, when, and under which terms version. That object becomes the thing the agent shows the human and the thing you store as evidence.

Exposing tools through MCP

The Model Context Protocol is the most widely adopted way to describe tools to AI assistants, and it is a sensible way to expose these operations. A tool definition is just a name, a description and a JSON Schema for inputs:

{
  "name": "create_subscription_quote",
  "description": "Return the exact first charge, recurring charge, cadence, next delivery dates and the cancellation terms for a plan and postcode. Does not take payment.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "plan_sku": { "type": "string" },
      "postcode": { "type": "string" },
      "start_date": { "type": "string", "format": "date" },
      "promo_code": { "type": "string" }
    },
    "required": ["plan_sku", "postcode"]
  }
}

Two opinions. First, keep read tools (catalogue, availability, quote) separate from write tools (create subscription, pause, cancel), and make the write tools require a quote ID so nothing is charged that was not quoted. Second, write descriptions for the model, not for your developers: say what the tool does not do as well as what it does. Vague tool descriptions produce confident mistakes.

There are also commerce-specific protocols emerging. OpenAI and Stripe published the Agentic Commerce Protocol for checkout inside assistants, and Google published the Agent Payments Protocol (AP2), which focuses on verifiable mandates that record what the user authorised. I would read both, because the concepts (a signed record of user intent, a merchant-controlled checkout, a delegated payment credential) are converging even if the wire formats are not. I would not rebuild my checkout around either one yet.

Identity and Delegation

The question you must be able to answer for every agent action is: who is this agent acting for, and what did that person allow?

The OAuth family already has most of the building blocks. An agent should obtain a token through a normal authorisation flow in which the person logs in to your site and grants specific, narrow scopes. Useful standards here include OAuth 2.0 Token Exchange (RFC 8693), whose act claim expresses "this party is acting on behalf of that subject", and Rich Authorization Requests (RFC 9396), which lets a grant carry structured limits rather than a flat scope string. MCP's own authorisation model is built on OAuth.

A delegated grant for a subscription store might look like this:

{
  "sub": "customer_8f21",
  "act": { "sub": "agent:assistant-example" },
  "scope": "catalogue:read quote:create subscription:create subscription:pause",
  "authorization_details": [
    {
      "type": "subscription_purchase",
      "max_recurring_amount": { "value": "35.00", "currency": "GBP" },
      "max_cadence": "P1W",
      "expires_at": "2026-12-31T23:59:59Z"
    }
  ]
}

Notice what is missing: subscription:cancel. Whether agents can cancel is a product and policy decision, and I come back to it below. Spending limits belong on your side as well as the agent platform's, because you are the one who will handle the complaint. Enforce them in the service, log every decision with the actor and principal, and show the person a list of connected agents with a revoke button in their account.

Recognising agents at the edge is a separate problem. Many automated clients now identify themselves, and there is IETF work on letting bots sign their requests using HTTP Message Signatures (RFC 9421). That is helpful for allowing known agents through bot defences, but a signed request tells you which agent it is, not which customer it serves. User delegation still has to come from an OAuth-style grant.

Payments, SCA and Agent-Initiated Purchases

This is where I would be most careful, because the rules were written for people and the standards for agents are still settling.

A quick recap from my guide to SCA and recurring payments: in the UK and EEA, customer-initiated remote card payments need Strong Customer Authentication, usually through 3D Secure, unless an exemption applies and the issuer accepts it. Subscriptions work because the first payment or card setup is authenticated with the customer present, and later charges are merchant-initiated transactions (MITs) under that agreement, which sit outside SCA.

Agents complicate both halves.

The sign-up. When an agent buys a new subscription, the person is usually not looking at your checkout. Yet this is the transaction that establishes the mandate, so it is exactly the one that should be authenticated. Treating an agent-initiated sign-up as "customer not present, so MIT" would be wrong: there is no prior agreement to rely on. In practice the safe patterns are either to hand the person a 3DS challenge or a passkey prompt through the agent's interface, or to use a payment credential that was authenticated when the person set up the agent's payment ability.

Delegated and tokenised credentials. That second option is where the industry is heading. Visa and Mastercard have both announced agent payment initiatives built on network tokenisation, where a token is issued for a specific agent, bound to the person's authentication and constrained by limits. Major payment providers have announced support for agent-initiated payments too. The common shape is that the merchant never sees raw card data, receives a credential scoped to this purchase or this agent, and gets signals that an agent was involved. How issuers will treat these for SCA purposes, and how liability shifts, is not fully settled across schemes and markets, so I would rely on your payment provider's documented flows rather than your own interpretation.

The recurring charges. Once a subscription exists and the mandate was properly authenticated, ongoing charges are still MITs, whoever set it up. What changes is the evidence: your mandate record should note that an agent created it, which grant it used, and the exact terms version and quote shown. When a dispute arrives months later saying "I never agreed to this", that record is your defence.

My rule of thumb: never let an agent pathway weaken the authentication on the transaction that creates the mandate. Add convenience after that point, not before it.

Subscription-Specific Risks

Agents signing people up

An assistant asked to "sort out flowers for my mum's birthday" might decide a subscription with an introductory discount is the cheapest option. That is a terrible outcome if the person did not realise it was recurring. Require the agent to pass back an explicit acknowledgement that the person was shown the recurring price and cadence, and send your own confirmation email or message immediately, written for a human, with a one-tap cancel.

Cancellations and pauses by agents

I think agents should be able to skip and pause with the right scope, and I lean towards allowing cancellation too. Regulators in the UK and EU are pushing hard on making exit as easy as sign-up: the UK's Digital Markets, Competition and Consumers Act 2024 contains a subscription contracts regime being brought in in stages, and EU consumer law now requires an easy online withdrawal function for distance contracts. Blocking an authorised agent from cancelling while allowing it to sign up is precisely the asymmetry those rules target. Check the current commencement position with your legal advisers rather than relying on a blog post, but design for symmetry now.

What I would not do is let cancellation flows become retention theatre aimed at agents. A save offer is fine if it is a single, clear response the agent can relay; a maze of screens is not.

Refunds and disputes

Agents will make mistakes, and so will you. A generous, fast refund for an obviously mistaken first box is usually cheaper than a chargeback and the damage to your dispute ratios. Make the agent and grant visible to customer service.

Fraud defences blocking good agents

Your bot defences were built to keep automation out. Now some automation is a paying customer. Expect legitimate agents to hit CAPTCHAs, rate limits and device fingerprint checks, and expect fraudsters to pretend to be agents. The answer is not to weaken defences; it is to give verified agents a better door (an authenticated API with scoped tokens) and keep the web front door as strict as it is today. Noisy decline patterns from card testing still matter, as I discussed in involuntary churn and failed payment recovery.

A Phased Plan for a Mid-Size Subscription Business

Teams I advise usually ask whether to start now or wait. My answer is to do the cheap, durable things now and keep the expensive, protocol-specific work on a watch list.

Phase 1: now, cheaply (weeks)

• Publish complete schema.org markup with intro and recurring prices, cadence and delivery areas.
• Rewrite subscription terms into plain, specific, crawlable text with a stable URL and version number.
• Make the product feed generated from the catalogue, including recurring prices.
• Review bot defences and analytics so you can at least see agent traffic and where it fails.
• Store the terms version and price shown alongside every mandate you already create.

Phase 2: next (one or two quarters)

• Build read-only agent endpoints: catalogue, availability and quote.
• Expose them as MCP tools and test them with the assistants your customers actually use.
• Add OAuth-based delegated access with narrow scopes, a connected-agents page and revocation.
• Allow skip and pause through scoped write tools, then cancellation.

Phase 3: wait for the standards (watch, then act)

• Agent-initiated checkout using network tokens or a commerce protocol, once your payment provider supports it in your markets and has documented the SCA and liability treatment.
• Platform-specific checkout integrations, once one assistant clearly drives a meaningful share of your traffic.

A short decision checklist

Before you open any write operation to agents, you should be able to answer yes to each of these:

1. Can an agent get the exact first and recurring charge from a single call?
2. Is every agent action attributable to both an agent and a person?
3. Are spending limits enforced in your service, not just trusted from the agent?
4. Is the mandate-creating payment still strongly authenticated?
5. Is cancelling at least as easy as signing up for an authorised agent?
6. Can customer service see which agent did what, and refund quickly?
7. Can the person revoke an agent from their account in one step?

The Takeaway

Agentic commerce is real enough to prepare for and immature enough that you should not bet your checkout on any single protocol. For a subscription business, the work that pays off regardless is unglamorous: state your prices and terms as clean data, put a small, well-scoped API in front of your subscription logic, and record who authorised what. Keep strong authentication on the transaction that creates the mandate, make exits as easy as entrances, and let the payment networks and providers finish settling the delegated credential story before you build deeply on it. A store an agent can understand and safely manage is also a clearer store for humans.