Chat tools
The built-in tools an agent version can call (product cards, clarifying questions, quick replies, web search, and page reading) and how to choose them per version.
Beyond the connectors it can call, a version has its own list of chat tools: built-in features the assistant itself decides to call to answer richer than plain text. The five below render as a component inline in the chat, not as a wall of text; two more, covered further down, give it access to the open web instead.
Not the same as capabilities
Chat tools are things the assistant chooses to call. A version also has capabilities (file upload and voice dictation), which are shopper-controlled composer affordances the assistant never calls itself. The two are configured in separate checklists on the same form.
| Tool | What shoppers see |
|---|---|
| Product carousel | A swipeable row of product cards for the products the assistant settled on, each with a price, a short pitch on why it fits, and (when the assistant flags it) a short badge over the photo (e.g. "On sale"). Tapping the photo or title opens the product page; an "Add to cart" button always sits below it. A product with 2 or more variants also gets a picker that swaps the photo and price instantly. |
| Product comparison | A side-by-side table of 2 to 4 products, with the assistant's pick highlighted, a 1-to-5 star rating plus a short take for every product, and (on any product with 2 or more variants) a picker that swaps that column's own photo and price instantly. |
| Product detail | A full product page inline in chat: an image gallery, price, a short sales pitch, and both an "Add to cart" and a "View product" button, always together. A product with 2 or more variants also gets a picker that swaps the gallery for that variant's own photo and updates the price instantly. |
| Clarifying questions | Up to 4 quick multiple-choice questions (with a free-text option) the assistant can ask before it searches or recommends, instead of asking in plain text. |
| Quick replies | Up to 3 tappable suggestions the assistant can offer after it's answered something: a next step written in the shopper's own words, sent as their own message the moment they tap it. See Quick replies below for when they show up and how they behave. |
Web search and page reading
Two more tools give the assistant access to the open web, for questions the catalog, connectors, and the model's own knowledge can't answer: comparing against a product outside your catalog, checking a factual claim, or pulling up independent reviews.
| Tool | What it does |
|---|---|
| Web search | Searches the live web and gets back a short list of results (title, URL, a content snippet) for the assistant to read and answer from. |
| Web page reading | Fetches and reads the full content of one specific page, typically a URL a prior web search turned up, or one a shopper pasted in. |
Unlike the five tools above, these don't render a card. While the assistant is using one, the chat shows a short status ("Searching the web for you…" / "Reading that page…"); the answer itself comes back as an ordinary written reply, not a component.
Both tools are capped at 3 combined calls per conversation turn. Once that's used up, the assistant answers with what it already has instead of continuing to search or fetch.
The Tools page
Every site has a Tools page listing all seven chat tools above: Tools in the dashboard sidebar, under Assistant, or /dashboard/sites/{siteId}/tools.
Each row shows the tool's name, its one-line description, and a Used by column: Active on N agents when N of the site's agents have that tool enabled on their live version, Not used otherwise. The count looks at champion versions only: a tool you're trialling on a draft or candidate version still reads Not used.
This page never turns a tool on or off. Enablement belongs to an agent's configuration version (see Choose a version's tools below); the Tools page only says what exists, whether it's live, and (for the two web tools) how it behaves.
Five of the seven tools have nothing to configure at site level; their row shows a dash instead of an actions menu. Web search and Web page reading each open their own configuration page: click the row, or use Configure in its ··· menu (which also has View documentation, opening this page in a new tab).
Configuring tools requires a permission
Opening the Tools pages requires the Agents: View permission; saving a configuration requires Agents: Edit. Without either, Tools doesn't appear in the sidebar and going there directly shows a restricted-access message. A view-only member sees a configuration page read-only: the settings are all visible, but the controls are disabled and no card has a Save button. See Roles to check or grant these on a custom role.
Restrict which domains they can reach
Both tools reach the whole open web by default: no configuration needed to make them useful. To narrow one (only your own domain plus two retailers) or block one (a named competitor, say), open its configuration page from the Tools page.
Each page presents that tool's domain policy as one of three modes:
- Open web: no restriction (the default).
- Allow only certain domains: only the domains you list, and their subdomains, are reachable; everything else is blocked. While the list is empty this behaves exactly like open web; the list's description says so.
- Block certain domains: the domains you list, and their subdomains, are blocked; every other domain stays reachable.
Add domains one at a time as bare host names: example.com, no https://, no path, no port. Anything else is rejected with a message naming what you typed. Entries are lower-cased for you, a domain already in the list is ignored rather than duplicated, and a list holds up to 100 domains. Switching mode clears the list you were editing: an allow-list carried over under a "blocked" label would mean the exact opposite, so a mode change starts from empty.
Nothing is written until you press Save at the bottom of the card you edited, and it stays disabled until you actually change something there. A successful save confirms with a short toast. Leaving the page first discards your edits; there's no "unsaved changes" warning. Widening a policy back to Open web isn't confirmed separately either; Save is the deliberate act.
A saved policy belongs to the site, not to an agent version. It applies to every agent version on the site as soon as you save: no new version to create, nothing to promote.
The two policies are fully independent: set both
Web search and page reading each have their own domain policy, edited only on their own page. Neither page shows or touches the other's. Restrict search but leave page reading open and the assistant searches inside your allow-list, then happily reads any page it's handed. Whatever you want to apply to both, save it twice.
Web search
Configured at Tools → Web search (/dashboard/sites/{siteId}/tools/web-search). Its policy decides which sites a search may return results from. The restriction is sent to the search provider and re-applied to the results that come back, so a domain you blocked can't reach the assistant even if it slips through the provider's own filtering.
Domains, modes, and saving work exactly as described above; there's nothing web-search-specific beyond the policy itself.
Web page reading
Configured at Tools → Web page reading (/dashboard/sites/{siteId}/tools/web-fetch). Its policy is separate from web search's and decides which pages the assistant may fetch, including a URL a shopper pasted into the chat. A blocked host is refused before any external request is made.
This page holds one setting web search doesn't have: Always enable JavaScript rendering. Some pages only show their real content after running JavaScript. Web page reading already retries once with rendering on when a plain fetch comes back close to empty. Turning this on skips that wasted first attempt for a site you already know needs it. Off by default, and every retrieval is a little slower once it's on. It sits in its own card with its own Save, so switching it doesn't commit whatever you may have been editing in the domain list above, and saving the domain list doesn't reset it.
Defaults depend on the agent's type
- A Shopping assistant agent starts with all five card tools above enabled on a new version: the checklist is there to turn some off, not to opt in. Web search and Web page reading are the exception: they start off for every agent type, Shopping assistant included, each an explicit opt-in.
- A Custom agent (an agent whose type is Custom, which starts with no built-in persona at all: everything it does comes from that version's own instructions) starts with nothing in the checklist enabled. You decide which, if any, it can use.
Choose a version's tools
Chat tools are part of an agent's configuration version, in the same form as its connectors.
Open the agent and go to its Capabilities tab. You're already editing its current configuration, no separate "new version" step needed (see Edit or create a version).
Under Chat tools, tick the ones this version should be able to use; each row shows the tool's name and a one-line description. The list is prefilled from the champion (or the version you chose to duplicate). The Web search and Web page reading rows carry a small cog on the right that opens that tool's configuration page; it's a shortcut only, and clicking it never ticks or unticks the tool.
Save, save as candidate, or publish, as usual. A new version is minted with the tools you selected.
A tool you leave unticked isn't just hidden from the assistant's replies: it's never made available to the model in the first place, so it has no way to call it.
Fixed for that version
Which tools a version can use is part of that version and can't be changed afterward. Like its instructions and connectors, changing the set means creating a new version.
Quick replies
After the assistant has delivered something this turn (a product carousel, a comparison, a product detail, a factual answer, or even a "not in stock"/"no such code" answer), it can offer up to three quick replies: short tappable suggestions for what the shopper might want next. Tapping one sends its full message on the shopper's behalf, exactly as if they'd typed it themselves, so the assistant answers it like any other message. A zero-result search is treated the same way: instead of a dead end, the assistant can offer ways forward (a wider search, a different budget, a related idea).
Every chip looks the same (plain text, no icon, no highlighted "best pick"), so nothing nudges the shopper toward one option over another; which one they tap is a genuine signal of interest. Chip text is set at the same size as the conversation's own messages.
The row sits right above the message box rather than back up in the conversation history, and it doesn't push the layout around when it appears or disappears. It has no close button: typing a new message is what dismisses it, and once the shopper does (or the assistant starts a new action), the row is simply gone.
On a wide enough chat panel the chips wrap onto a second line when they don't all fit. On a narrow one (a phone, or the assistant embedded in a slim column), they stay on a single line that scrolls sideways instead, so the row costs one line of height rather than three and leaves the conversation visible. Every chip in the row stays reachable either way; none is hidden to make room.
Why a row sometimes carries fewer chips
The assistant drafts more suggestions than the row can hold and ranks them, best first. The row then shows the first three that pass the checks below, so a rejected suggestion is normally replaced by the next one down rather than leaving a gap. A row carries fewer chips only when not enough of them pass: sometimes two, sometimes a single chip, sometimes no row at all.
Two different checks reject a suggestion, and it's worth knowing which is which.
Your store can't support it in that moment. "Go to checkout" before anything has been added to the cart, "compare these" when the shopper has only been shown one product so far, "add to cart" when the connector exposes no cart tool at all. The action behind the chip has nowhere to go, so the chip never appears.
The answer isn't actually in the source. Every suggestion also declares where its answer would come from. When that's a source the assistant can read up front (one product's catalog fields: title, price, availability, its sizes or shades; that product's own description text; or what your shop published in its policies and FAQ), it reads that exact source before the row is shown and checks whether the fact the chip promises is really in there. Being on the right topic isn't enough: "Your delivery times" is dropped when your shipping page lists carriers and options but never states a timeframe, and "What's in it exactly?" is dropped when the product description is a paragraph of positioning that names two hero ingredients and no ingredient list. This is the check you can act on: the more specific your product descriptions and your published policies are, the more of these suggestions survive.
That second check has limits worth being clear about. It covers those sources only: a chip that adds a product to the cart or opens the cart promises no answer, so there's nothing to read, and a chip offering a fresh search of the catalog is answered by whatever that search returns, so it isn't checked before it's shown. And when the source can't be read at all (your policy content doesn't come back in time, or the product a chip names can't be resolved), the chip is kept rather than dropped. The check makes a suggestion the assistant then can't answer rarer; it doesn't rule one out.
When quick replies stay silent
Quick replies deliberately show nothing in a few situations: while a clarifying question is still pending (answering it comes first), at the very start of a conversation, on a request outside shopping entirely, while the assistant is collecting personal information, and right after the shopper confirms adding something to their cart. There, the only chips still on the table are going to checkout or resolving a delivery/returns doubt, never a chip that pulls them back into browsing.
Clarifying questions and the composer
When the assistant asks a clarifying question, answering it (or skipping or closing it) is what lets the conversation continue. Typing and sending a new message instead does not answer the pending question for you; the composer doesn't currently hold your next message back until the open question is resolved.
Add to cart
"Add to cart" on a product carousel, comparison, or detail card doesn't call a cart API directly: it sends a message asking the assistant to add that product to the cart, and the assistant takes it from there in the conversation.