Agentic commerce still needs a content layer

extract

Agentic commerce still needs a content layer TLDR - Agentic commerce went through a full hype cycle. Agent checkout launched, then got scaled back in some places. Agent discovery, however, didn't go anywhere. - Shopping agents decide what to recommend by reading your product data and your content. If they can't read it, or it contradicts itself, you're not in the answer. - Commerce platforms own price, stock, and checkout. The CMS owns everything that explains why someone should buy. Agents need both, cleanly separated and very, very consistent. - The fix isn't a new tool. It's structured product content, canonical facts, and machine-readable versions of your pages. Y'know, all the "boring" stuff. Last year I wrote that Shopify vs. Headless CMS is a false binary. Shopify handles commerce, DatoCMS handles content, and everyone gets along tip-top. Then agents showed up to go shopping, and a lot of people started asking whether any of that still matters when the "shopper" is ChatGPT. It matters more (not to me tho, I'm deffo not trusting Claudia with my CC details yet 💅). Here's why. A very quick recap of the last 12 months It's only been "a year" but since every day we have a "totally unprecedented historic moment" coming out of the world of AI, I'll try to find the most relevant bits. In September 2025, OpenAI and Stripe launched Instant Checkout in ChatGPT, along with the Agentic Commerce Protocol (ACP). The idea was straightforward: find a product in a chat, buy it in the chat, without ever leaving the chat. In January 2026, Google announced the Universal Commerce Protocol (UCP), co-developed with Shopify, Etsy, Wayfair, Target and Walmart. UCP covers the whole journey from discovery to fulfilment, and businesses publish what they support in a manifest at /.well-known/ucp. Then in March 2026, OpenAI scaled Instant Checkout back, roughly five months after launch. Purchases now get routed to merchants and third-party apps instead of happening inside ChatGPT. So the "agents will buy everything for you" part is… a bit wonky. But look at what DIDN'T change. People still ask ChatGPT, Claude, Gemini, and Perplexity which running shoes to get, which espresso machine to buy, and whether that jacket is actually buy it for life (yes, these examples clearly show my mid-life crisis coming out). The agent still does the research. It still builds the shortlist. The checkout just happens on your site afterwards. Which means the part that decides whether you make the shortlist, the discovery part, is where the room for improvement is. And discovery runs on content and context. What an agent actually reads When an agent researches a product, it pulls from a few places: - Product feeds. ACP's product feed is structured data (CSV or JSON) with identifiers, descriptions, prices, inventory and media. Google Merchant Center feeds do the same job on the Google side. - Your product and category pages. Crawled like any other page, which comes with the usual caveat: most AI crawlers don't execute JavaScript. If your product details render client-side, the agent sees an empty shell (more on that in another post on making your website agent ready). - EVERYTHING around the product. Buying guides, size charts, care instructions, compatibility tables, comparison pages, reviews, FAQs, return policies. - Third Party information around the product. Reviews, testimonials, third-website mentions, the usual backlinking stuff. Brand "reputation" also comes in, but I'm lacking empirical data at my fingertips to drone on about it. That third bucket is what decides recommendations, mainly. Price and stock tell an agent whether it can recommend you. The descriptive content tells it whether it should. "Are these boots good for not slipping and breaking my back on black ice in Berlin in Feb?" isn't answered by a SKU and a price-tag. It's answered by the waterproof rating, the fabric, the fit notes, and the guide you wrote about layering (and whatever GPT knows about winters in Berlin). That's content, and in most headless setups, it lives in the CMS. Who owns what The split we described in the Shopify post still holds. It just gets more important when the reader is a machine. The commerce platform owns "transactional truth": - Price and currency - Stock and availability - Variants and SKUs - Checkout, payments, tax, shipping - The protocol endpoints (ACP, UCP) that let an agent transact and generate product cards in-chat The CMS owns "descriptive truth": - Long-form product descriptions and specs that go beyond what the feed would know - Buying guides, comparisons, how-tos, variations - Sizing, materials, care, compatibility - Brand story, sustainability claims, certifications, reputation, ratings, reviews - Localised versions of all of the above The trouble starts when the same fact lives in both places and they disagree. If Shopify says "machine washable" and your CMS product page says "hand wash only", an agent is going to pick one. It might not be the right one, and it definitely won't flag the conflict to your customer. So the rule we'd suggest: every fact has one home. Transactional facts live in the commerce platform. Descriptive facts live in the CMS. The product record in the CMS references the commerce product (by ID or handle) instead of copying price and stock into text fields. In DatoCMS, that's what the Shopify, Centra, and other commerce plugins are for: editors pick the product, the CMS stores a reference, and the frontend fetches live price and stock from the commerce API. What an agent-friendly product record looks like "Structure your content" is advice we've been saying since the early days of Headless CMS, and everyone loves it in theory, but not everyone adapts it in practice, so let's be specific. A product page modelled as one big rich-text field is basically a PDF. A human can read it. A website can render it (not ideally). An agent can read it too, but it has to guess which part is talking about the fabric, which is the fit, and what is just marketing fluff. Compare that to a product content model with actual fields: - Commerce reference (Shopify product, Commerce Layer SKU, etc.) - Short description with a character limit, written to be quoted and summarize everything simply - Specs as structured blocks: material, dimensions, weight, compatibility, each a proper set of fields with a unit - Use cases as tags or references ("hiking", "commuting", "travel") instead of adjectives buried somewhere in an irrelevant paragraph - Care and sizing as their own fields, or as references to shared records so you update them once and they carry along consistently to that product everywhere - Claims (sustainable, waterproof, certified) as fields with a source or certificate attached rather than just vibes - Related guides as references, so the product and the buying guide point at each other Every one of those fields is something an agent can pick up without guessing. It's also exactly what you need to generate a clean product feed anyways for things like the schema.org Product markup. Bonus points if your CMS or frontend or Commerce tool can generate .md versions of your content/pages because agents LOVE reading boring old plain text. That last part is a nice payoff. When content is structured, "agent readiness" is just more templates. When it's trapped in an old and clunky page builder, it's a scraping project for you to figure out how to get your content agent-ready from scratch. Been there. 10/10 would NOT recommend. Did you forget about product visuals? Well, no, because CMS vs. PIM for visuals is a preference call most of the time, but since agents don't just read, here's why I am on team-CMS for managing visuals. Most of the big models are multimodal now, image_link is a required field in Google Merchant Center feeds, and the first thing anyone sees on an in-chat product card is... 🥁... the image. So your assets deserve the same treatment as the rest of your product content: one source, properly described, consistent everywhere. This is where the boring Media Area stuff pays off in a CMS, so let me walk you through it with the example of DatoCMS. Upload one high-res master image and let the imgix-powered Images API do the rest. You get square crops for your feeds, WebP or AVIF for your product pages, and tiny thumbnails for comparison tables, all generated on the fly from URL parameters. Nobody has to export 14 versions out of Figma. Set a focal point once and every crop keeps that pink shoe in frame, instead of a very nicely but pointless cropped shoelace. Alt text, titles and custom metadata live on the asset itself (per locale), so the description an agent reads goes wherever the image goes. And if you're behind on alt text, the Alt Text AI plugin can help you catch up. Video gets the same treatment through Mux. Upload once and you get adaptive streaming, MP4 renditions and thumbnails, and you can pick the exact frame that represents the video. That's pretty much what schema.org VideoObject and most feeds ask for. A properly described unboxing or "how it fits" clip is something an agent can actually point to. Getting your product content in front of agents With the content model in place, the rest is housekeeping and boring old concepts: - Render product pages on the server. Price and stock can be fetched live, but the descriptive content should be in the HTML the crawler receives (bonus points if that HTML instantly tells the agent there's a .md version available and to go there instead). - Add schema.org Product markup generated from CMS fields plus live commerce data. Name, description, brand, offers, availability, reviews. JSON-LD was equally important and boring in 2010, but it's hyped again as "AI readiness". - Generate Markdown versions of product and guide pages. Same content, no nav, no cookie banner. We covered how to generate these from a headless CMS already. - Enrich your feeds from the CMS. Most feeds end up with thin, truncated descriptions pulled from the commerce platform. Feed the long-form description, specs, and use cases from the CMS into the feed instead. - Keep facts consistent across locales. If the German page says 3-year warranty and the English one says 2, an agent will find both, and rather than try and confirm things, it'll recommend one or the other to a potential buyer without clarification. - Let the commerce platform handle the protocols. If you're on Shopify or another platform that supports UCP or ACP, that's where the checkout endpoints belong. Your CMS doesn't need to be a payment processor. (Please don't make it one. You caaan. But don't.) So what does this mean if you're an editor? Honestly, not that much changes in your day-to-day. What changes is how you write: - Put facts in fields, not in paragraphs. If there's a field for material, use it, even if the description also mentions it. If there isn't a field for material, ask your devs to create one. - Write short descriptions that make sense on their own. An agent will quote them out of context, and so will Google. The same old SEO habit of well structured and keyword-richness with relevance applies. - Back up claims. "Eco-friendly" with nothing behind it is a claim an agent can't verify, and in the EU, generic green claims are getting harder to make legally anyway. Which is ✨load-bearing✨ - Update facts in one place. If the warranty changed, fix the shared record, not 40 product pages individually with greater chances for mistakes. If your content model doesn't have fields for these things, sit down with your devs to work with you on improving the schema of your project, don't make it into a writing problem when it isn't one. Agentic checkout might come back, or it might just settle into this "discover in the agent, buy on the site" for good. Nobody knows yet, but given the pace at which things change here, it's good to be ready for both possibilities. What we DO know is that agents are already doing the research, and they're doing it by reading your content. The brands that show up in those answers won't be the ones who adopted every new protocol first. They'll be the ones whose product content is structured, consistent, and readable by something that isn't a human. That's not a new commerce stack. That's a content model. And good news, you already have a CMS for that 😌