Shoppers are starting to ask an AI assistant to find, compare and buy things for them — and increasingly that assistant is not yours. Agentic commerce is the discipline of making your catalog usable by an AI agent: exposing search, detail, comparison and cart as tools an assistant can call, returning results it can render as real product cards, and doing all of it without handing a stranger's model the keys to your store. The good news for anyone who already grounded an on-site assistant: most of the work is done.
What agentic commerce actually means
Strip the hype and it's specific: an AI assistant, on behalf of a user, calls functions against your commerce systems and acts on the results — "find a magnesium supplement under €20 that ships to a locker", "compare these two", "add the cheaper one". The assistant supplies the conversation; you supply the ground truth and the actions. This is the same contract as an on-site assistant (see the assistant architecture), with one difference that changes everything: the model calling your tools is one you don't control, so the boundary has to be airtight.
Why care now, before shoppers are doing this at volume? Because the surface is being defined this year, and the stores that are callable will be the ones assistants reach for — the same first-mover dynamic that made mobile-friendliness a ranking reality long before most traffic was mobile. Being present as a clean, callable catalog is cheap if you already grounded your on-site assistant, and expensive to retrofit if you didn't. It is a discoverability bet as much as a features bet.
MCP: the commerce tools an assistant calls
The emerging standard for this is the Model Context Protocol (MCP) — a way to describe tools so any compatible assistant can discover and call them. For commerce the tool surface is small and stable: search the catalog, fetch product detail, compare a set, check availability, add to cart, get delivery options. Each tool has a typed input and a typed return, which is exactly the structured-output discipline pointed outward.
| Tool | Input | Returns |
|---|---|---|
| search | Query, filters | Ranked products with price, stock, link |
| product detail | Product id | Full attributes, variants, availability |
| compare | Set of product ids | Aligned attribute table |
| cart | Product id, quantity | Cart state, per-vendor totals |
| delivery | Destination | Methods, fees, estimates |
The protocol spec lives at modelcontextprotocol.io; the commerce-specific work is deciding which actions you're willing to expose and hardening each one.
Why grounded architectures port for free
We exposed our commerce stack as MCP tools plus inline product cards so third-party AI assistants can browse and compare our catalog conversationally — and it was nearly free to build, because the hard part was already done. The same tools that ground our on-site assistant (search, detail, compare, cart, delivery) are the tools an external agent needs. Teams that invested in tool-grounding get agentic commerce almost for nothing; teams that shipped a wrapper chatbot get to start over, because a wrapper has no clean tool surface to expose.
This is the strategic argument for grounding done properly (RAG over product data): it isn't just cleaner on your own site — it's the asset that lets your catalog show up wherever shoppers are asking, without a rebuild per surface.
Inline product cards and the response contract
An assistant that returns a wall of text about your products is a worse experience than your website. The win is inline product cards — structured results the assistant renders as tappable cards with image, price, availability and a link back to the real product page. That means your tool returns should be shaped for rendering, not prose: stable fields, a canonical URL, a price with currency, a clear in-stock flag. Treat the return shape as a contract the way you'd treat any UI-driving output, because on someone else's surface you can't patch the rendering afterward.
Deep-link every card back to the real product page rather than trying to complete the whole purchase inside the conversation. Attribution, returns, payment and per-vendor cart rules are hard enough on your own checkout; handing them to an arbitrary assistant is where the risk concentrates. Let the agent do discovery and comparison brilliantly, then land the shopper on your page for the parts that carry money and legal weight — a division of labour that keeps the conversational surface useful without making it your merchant of record.
Auth boundaries and policy risk
Two risks deserve real engineering. First, auth boundaries: read actions (search, detail, compare) can be open; write actions (cart, and anything touching an account) need a scoped, revocable credential and hard rate limits, because the caller is an autonomous agent, not a person clicking. Second, and subtler, policy hallucination: an external assistant may confidently state your shipping, returns or price-match policy — and get it wrong. The mitigation is to make policy a tool too: expose shipping, returns and pricing as structured, queryable facts so the correct answer is one call away, and never something the assistant has to invent. The same guardrail thinking applies at the boundary: assume the caller is adversarial and validate accordingly.
Machine-readable products: llms.txt and structured data
Not every assistant will call your MCP tools; many will read your pages. So the baseline is machine-readable product data: Product and Offer structured data, an accurate dynamic sitemap, and an llms.txt that points AI crawlers at your fact-dense summaries. This is where agentic commerce overlaps with discoverability — the same work that gets you cited by AI answers, covered in generative engine optimization and marketplace SEO. Tools for the agents that can call them; clean structured data for the ones that can only read. The two reinforce each other: structured data makes your pages parseable today, and it's the same fact model your tools already return, so you're not maintaining two truths — you're publishing one truth in two formats.
Key takeaways
- Agentic commerce is exposing your catalog as tools an AI agent can call — search, detail, compare, cart, delivery — with typed inputs and returns.
- MCP is the standard for the tool surface; keep it small and stable, and harden each action you choose to expose.
- Grounded architectures port for free — the tools that ground your on-site assistant are the ones an external agent needs; wrapper chatbots start over.
- Shape tool returns for inline product cards, not prose — stable fields, canonical URL, price and stock — because you can't patch someone else's rendering.
- Fence the boundary — scoped revocable credentials and rate limits on write actions, and expose your policies as tools so assistants can't hallucinate them.
- Ship machine-readable data (structured data, sitemaps, llms.txt) for the assistants that read rather than call.
Frequently asked questions
What is agentic commerce?
How does MCP relate to ecommerce?
Do I need to rebuild my assistant to support AI agents?
How do you stop an external AI assistant from misstating your policies?
Your catalog, wherever shoppers ask.
The MCP tool surface here is exposed from the commerce stack behind the managed marketplace we operate.
Request early access See the live marketplace →