The next person to buy a t-shirt from us might not be a person.

Over the last few months, "agentic commerce" went from a slide-deck phrase to working infrastructure. Stripe and OpenAI shipped the Agentic Commerce Protocol behind ChatGPT's shopping flow. Google published an open commerce protocol aimed at agent-to-retailer interoperability. The payment networks ran their first live agent-initiated transactions. IBM's January survey put 45% of consumers as already using AI for some part of a purchase. The buyer in the loop is increasingly a model with a budget and a goal, not a human with a mouse.

Which raises an awkward question for anyone running a store: can an agent actually buy from you right now?

For most ecommerce sites, the honest answer is no — not because the products aren't for sale, but because the store is built entirely for human eyeballs. The catalog lives inside client-rendered JavaScript. The only path to checkout is a form behind anti-bot challenges. An agent shows up, can't parse the catalog, can't drive the checkout, and bounces.

We did the work to make our store transactable by an agent before the trend forced it. It comes down to two halves: a catalog an agent can read, and an action surface an agent can call.

Half one: a catalog the agent can read

An agent deciding whether to buy needs a small set of facts: what is this, what does it cost, is it in stock, how long is shipping, and can it be returned. A human extracts those from a product page by looking at it. An agent shouldn't have to reverse-engineer your layout to find them.

The fix is older than the trend: schema.org Product data, emitted as JSON-LD in the page head. Every product page on our site carries a structured block like this:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Vibe Coder Badge Tee",
  "sku": "UT-142",
  "brand": { "@type": "Brand", "name": "Ultrathink" },
  "category": "T-Shirts",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "24.99",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-01",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": { "minValue": 2, "maxValue": 5, "unitCode": "DAY" },
        "transitTime": { "minValue": 3, "maxValue": 7, "unitCode": "DAY" }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "merchantReturnDays": 30,
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

Look at what's in there. Price, currency, in-stock state, condition, handling and transit windows as numeric ranges, a 30-day free-return policy. Those are exactly the fields an agent needs to make a buy / no-buy decision — and they're handed over as typed values, not buried in prose an agent has to interpret.

This is the same markup people generate for Google rich snippets. The interesting shift is the consumer. For years this data existed to win a search-result star rating. Now a different reader is parsing it: an agent comparing your offer against three others and picking one. The catalog page becomes an API you didn't have to design, addressable by any agent that knows how to read application/ld+json.

Our category and listing pages carry their own structured layer — an ItemList of product URLs, a BreadcrumbList for hierarchy, and a site-level WebSite entry with a search action. An agent can walk from the homepage to a category to a specific offer entirely through structured nodes, without parsing a single rendered <div>.

The cost of this is close to zero if you already have product data. We render it from one helper that turns an item record into the schema graph. The hard part isn't generating it — it's deciding to treat your own catalog as a machine interface and keeping the fields honest (real stock state, real shipping ranges) so an agent isn't acting on stale promises.

Half two: an action surface the agent can call

Reading is only half of buying. To actually transact, the agent needs to do things: put an item in a cart, supply a shipping address, get a payment link. A product page rendered for humans gives it nowhere to push.

That's the job of the MCP server we published. It exposes our shopping flow — ultrathink_browse, ultrathink_product, ultrathink_cart_add, ultrathink_cart_view, ultrathink_checkout — as typed tools any MCP client can call. An agent inside Claude Code can browse the catalog, build a cart, and get a hosted payment link without ever touching the HTML page a human would use.

The earlier post covered how that server is built — the tool schemas, the translation layer, the way customer data is kept out of model context. The point worth pulling out for the agentic-commerce framing is simpler: the catalog is the read half, the MCP server is the write half. Structured data lets an agent decide; the tool surface lets it act. You need both, and they're different problems with different shapes.

This is also why the protocols converging right now — the Stripe/OpenAI commerce protocol, Google's open standard, MCP underneath as the connectivity layer — all describe the same two halves. A structured product feed an agent can discover, and an agent-callable action API it can transact against. The industry is standardizing the exact pair of interfaces we already wired by hand.

Why most stores bounce an agent

Put the two halves together and the gap in a typical store becomes obvious.

The catalog half fails when product data only exists after JavaScript runs and renders it into the DOM. An agent fetching the page gets a near-empty shell. No structured offer, no machine-readable price, nothing to act on without driving a full browser and interpreting pixels — slow, brittle, and easy to get wrong.

The action half fails because the only route to purchase is a checkout form designed to keep automated traffic out. CAPTCHAs, anti-bot challenges, and human-shaped flows are doing their job — but they treat every non-human caller as an attacker, including the agent a customer explicitly sent to buy something.

Neither failure is about hostility to agents. It's that the store was built when every buyer was assumed to be a human looking at a screen. That assumption is quietly expiring.

The cheap insurance

Here's the part worth acting on: the read half is mostly free. If you sell anything online you probably already emit some product structured data for SEO. Auditing it for the fields an agent needs — accurate availability, real shipping windows, a return policy — gets you most of the way to a machine-readable catalog without new infrastructure.

The write half is the real project, and it's the one most stores haven't started. An action surface — MCP today, an agentic-commerce protocol endpoint tomorrow — is what turns a readable catalog into a buyable one. We built ours small and local-first, six tools deep, because we'd rather an agent transact cleanly through a typed interface than fight its way through a form meant to stop it.

The buyer being an agent isn't a future scenario anymore. It's a traffic source you either parse for or get parsed badly by.

Next: the part the structured-data spec leaves undefined — how an agent should trust an offer it can read, when the merchant controls every field in it.