Compatibility-driven commerce

Consider the actual request: I want to upgrade from my current machine, I make two flat whites a day, and I have 32 centimetres of counter. Three constraints, spread across a specification table, a compatibility chart and a product description that mentions width in a footnote.

That is not a shopping problem, it is a research problem, and it is the reason this category converts badly and returns heavily. It is also precisely the shape an agent is good at — provided your site can answer.

Which shops this applies to

• Many specifications per product, several of which are hard constraints rather than preferences.
• Accessories with real compatibility rules — mounts, filters, cartridges, cables, sizes.
• A basket large enough that a wrong choice is expensive to return.
• Customers who already research across three tabs before buying.

Camera systems, espresso, PC components, car parts, prototyping electronics, professional audio, bike components, industrial fasteners. If your support inbox is full of will this fit my…, you are in this category.

A first tool set

search_products(query, filters)        // free text plus hard constraints
get_product_details(id)                // full specifications, typed
compare_products(ids[])                // side by side, differences highlighted
check_compatibility(productId, accessoryId)
get_cart() / add_to_cart(id, quantity)
apply_coupon(code)
get_my_orders()                        // only when signed in

compare_products and check_compatibility are the two that change the conversation. Everything else an agent could approximate by clicking; those two encode knowledge that only exists in your data.

Conditional tools are the interesting part

Signed out, an agent sees search, details and compatibility. Signed in, it also sees the cart, order history and reorder. Nothing was configured to make that happen — the browser session carries the login, and your tool registration reads the same session state your UI does.

Compare that with the alternative: issuing an API key so an assistant can read a customer's order history. One of those requires a security review and a revocation story. The other is the customer was already logged in.

The prerequisites nobody wants to hear

1. Specifications as data, not prose. width: 31 cm in a field beats approximately 31cm wide in a paragraph. Emit it as a QuantitativeValue with a unit code — see structured data.
2. Compatibility as a relation. If the rule lives in a PDF chart, no tool can answer it. It has to be queryable.
3. Product pages that render server-side. A tool on a page an agent reads as blank is a tool nobody finds. See content without JavaScript.
4. No challenge on the cart path. A CAPTCHA between an agent and a checkout ends the session.

What it is worth

The honest framing is not extra traffic. It is the same traffic, converting further. A broken agent journey is not a ranking loss you can see in a dashboard — it is an abandoned basket attributed to nothing, in a channel you are not measuring yet.

The measurable version: how many of your top ten customer questions can be answered from your own site by a machine, without a human reading a chart. Today, for most shops in this category, the answer is none of them.