How it works

Every answer the assistant gives is built from your real WooCommerce data. The model never speaks from memory about your catalogue. It runs an agentic tool loop, grounds each fact in what a tool actually returned, and shows products as trusted cards that the model never rewrites.

The grounded answer loop

When a shopper sends a message, the plugin drives a bounded, multi-turn agent loop. On each turn the model can either reply or call a tool. When it calls a tool, the plugin runs that tool against your live store, hands the result back to the model, and lets it take another turn. The loop continues until the model has what it needs to answer, then it stops.

1. The shopper asks a question, for example "what do you have for under $50?"
2. The model decides it needs catalogue data and calls a tool such as search_products with the budget as a filter.
3. The plugin executes the tool against WooCommerce and returns the real result: matching products, their actual prices, and live stock.
4. The model reads that result and either calls another tool or writes a short, grounded reply.
5. The matching products are shown to the shopper as cards, and the model's text is streamed alongside them.

The loop is bounded, so it always terminates. If it ends without a usable reply, the shopper sees a friendly fallback rather than a raw error, and any cards already gathered are kept.

The tools the model can call

The model has no direct access to your database. It can only reach your store through a fixed set of tools, and each tool returns structured data that becomes the only source for the answer. The core shopping tools are:

• search_products, find products by query, category, budget, or sale status, and return the matches.
• get_product_details, read one product in full, including its variations such as size and colour.
• add_to_cart, add a confirmed product or variation to the WooCommerce cart.
• view_cart, read the current cart contents and totals.
• remove_from_cart, take an item back out of the cart.

Beyond these, the same loop can call feature tools when they are relevant: wallet and store credit, reviews and ratings, coupons, shipping, checkout summaries, reorder, stock alerts, and more. Every one of them reads or writes real store state, and every one returns grounded data the model summarises rather than invents.

Products render as trusted cards

After search_products or get_product_details runs, the storefront shows the matching products to the shopper as visual cards: photo, name, price, stock, and View or Add to cart buttons. The card data comes straight from the tool result, not from the model's text. The model is told not to restate each product's price, description, link, or image in prose, because the card already carries all of that from trusted data.

The model still writes at least one line of text alongside the cards, a short intro, recommendation, or comparison, so the reply is never silent cards alone. It can highlight or compare a couple of options in words, but it does not paraphrase the catalogue into new claims. Facts stay on the card; wording stays in the text.

Streamed over SSE

Replies are streamed to the widget over Server-Sent Events, so text appears as the model writes it and cards appear the moment a tool returns them. The endpoint sends an text/event-stream response and emits one JSON event per step. The event types map directly onto the loop:

event: tool       { "name": "search_products" }
event: products   { "products": [ /* trusted card data */ ] }
event: chunk      { "content": "Here are a few under $50 ..." }
event: done       { }

A tool event signals which tool the model is calling, a products event carries the card data for the storefront to render, chunk events stream the reply text, and done closes the turn. A product surfaced by more than one tool call in a turn is shown once, so the shopper never sees a duplicate card.

Trust guardrails are absolute

A trust and honesty policy is appended to the system prompt last, after the base instructions, any merchant configuration, and any filter. That ordering makes it structurally non-overridable: nothing a merchant or a filter sets can weaken it. The guardrails are absolute and override any instinct to make a sale.

• No fabricated scarcity. Never invent "only N left", countdowns, "selling fast", or "limited time". Stock levels are mentioned only when a tool result actually reports them, and the real number is stated.
• Ground every fact, or abstain. Product details, prices, stock, reviews, ratings, order data, and wallet data come from tools. If the model does not know or a tool returns nothing, it says so and offers a real next step rather than guessing.
• Respect stated budgets. The model never pushes a product priced above a budget the shopper gave. If nothing fits, it says so plainly instead of steering them higher.
• Never narrate an unconfirmed action. The model only describes an action a tool actually confirmed. If a tool returns an error or a plain "no", that is what the shopper hears, never a fabricated success.
• Never block human support. For order, account, refund, or return issues, the model points the shopper to your support team or asks them to log in for their own data.

The plugin even strips long dashes from the model's output before streaming, so replies stay in the same plain, dash-free voice as the rest of this site.

Why this matters

Because the answer is assembled from tool results and the cards carry trusted data, the assistant behaves the same whichever AI provider you connect. The provider supplies fluent language; your store supplies every fact. The shopper gets a helpful, conversational reply that is grounded in what is genuinely true about your catalogue, your cart, and your prices, right now.