Agentic commerce: letting AI agents shop a Crystallize store

SEO and GEO is the passive half: making the store readable for answer engines. Agentic commerce is the active half: giving agents tools to search the catalogue, read a product, build a basket and hand it to the shopper.

Build them on the same functions the storefront uses: the same Discovery queries for search and product detail, the same Shop API calls for the cart and checkout, the same ranking. Use the same tool names on every surface (search_products, get_product, add_to_cart, view_cart), so an agent that knows one knows the others. None of them needs Core, and none of them keeps server-side state.

Agents filter and compare on facts, so the model matters more than the prompt:

• Typed specifications. Numbers with units, booleans and selections become Discovery filter fields. An agent can then search for "18 V, over 60 Nm, under 2 kg" as hard filters instead of guessing from text.
• One unit per numeric field. Discovery range filters compare numbers and ignore the unit, so a field that holds both grams and kilograms can't be filtered reliably.
• Variants with their own SKU, price and stock, and attribute names an agent can read ("Version: bare tool", "Kit with 2 × 5.0 Ah").
• Relations as item relations, not text: what fits what, accessories, consumables, the rental version of a tool.
• Unset booleans are `false` in Discovery. An agent filter on "has Bluetooth: no" also matches products where nobody said. Decide which booleans are reliable before you expose them as filters.

• Hand off by default. The cart tool returns a link that opens the same cart in the shopper's browser, where they review and pay. Tell the model, in the server instructions, to prefer the link unless the shopper asks it to order.
• Mark the checkout tool destructive (destructiveHint: true) so hosts ask for confirmation, and limit what it can do. In the demo stores, a guest must give an email and a name, and invoice or quote orders are only for a signed-in trade buyer whose credit limit is checked. Card payment belongs in the store, behind the hand-off link, not in the conversation.
• Bookings are confirmed after the order exists, exactly as in the storefront. See Cart, checkout and orders.
• Never let the model invent links. Every URL a tool returns is built by your code (product pages, a "view these products" page, the cart hand-off). Say so in the instructions.

An assistant in your own header is the third surface: a chat panel whose server route runs a model with your tools.

• Stream the answer, and run the last round without tools (tool_choice: none), so a reply always ends with words rather than a dangling tool call.
• Render results as your own product cards, ranked as the store ranks them, and personalised with the shopper's taste when they are signed in. See Vector Search.
• Retry when a streamed tool input fails to parse. Streaming tool arguments eagerly sometimes produces invalid JSON.
• Render the model's Markdown as elements, never as raw HTML, and keep conversations in sessionStorage, not localStorage.
• Announce messages, not tokens (see Accessibility).

• MCP server: a stateless shopper MCP server on Discovery and the Shop API, with typed-spec search, baskets without sessions and OAuth sign-in.
• MCP Apps: interactive product cards inside the assistant.
• WebMCP: tools declared by the storefront's own pages.