AI Can Read Your Catalog. Can It Buy From It?

Somebody is going to type this sentence into an AI assistant this week, and it will not be on your website: “I need to coat about 600 square feet of garage floor. The concrete's old, I think there's damp coming up through it, and I park two cars on it.” No category, no SKU, no search term. Just a job, described the way people describe jobs.

That is roughly the future Phil Risher sketches in a video called Your Website Won't Matter in 3 Years — customers stop visiting business websites and start asking an assistant to research, compare, decide, and increasingly transact on their behalf. It's worth watching in full. I agree with most of it, and I agree hardest with the unglamorous middle of the argument: if that's where buying goes, the asset that matters is machine-readable knowledge about what you sell, not a beautifully art-directed page.

Then I ran the argument through a coatings catalog, and it broke in an interesting place.

Knowing that a product exists gets an agent nowhere. It has to know whether that product suits this floor, which variant, how much, what goes underneath it and over it, and when the honest answer is that it shouldn't recommend anything at all. Being findable and being buyable-from are different engineering problems, and almost everyone is currently solving the first one.

A web page was never a good place to keep knowledge

For twenty-five years the website was the digital asset. Product facts went into pages. Application guidance went into PDFs. The awkward stuff — what not to use, what it depends on, what usually goes wrong — went into data sheets, distributor portals, spreadsheets, email threads and the heads of four experienced people. The customer was expected to assemble all of it themselves, via search, browse, compare, enquire.

A page is a terrible container for this. It mixes navigation, brand voice, persuasion, images, specs, disclaimers and pricing into one blob optimised for a human eye moving down a screen. It is designed to be convincing, which is precisely the wrong property for something a machine is going to reason with. An AI system reading your product page can tell you what your marketing team wanted to say. It cannot reliably tell you when the product fails.

What a decision system actually needs is closer to a set of structured answers: what this product is, what applications it's meant for, which surfaces it bonds to, what conditions it tolerates, which variant applies where, what must be applied before and after it, what evidence supports each of those claims, and when any of it was last verified. That is a different artefact from a page. The page can render from it. It should not be it.

I've made a version of this argument before in From Product Pages to Product Intelligence. What's changed since is who's asking. It used to be your own site's search box. Now it's somebody else's agent.

Finding a seller and choosing a product are different problems

Here's where I part company with the video, and it isn't a disagreement so much as a difference in depth.

The knowledge catalog it describes — services, pricing, policies, credentials, availability, coverage area, common questions — is aimed at helping an agent qualify and route. Does this company do the thing? Do they operate near me? Are they credible? What do they charge? Can I book them? For a plumber, a dentist or an agency, that's most of the job. Once the agent picks the seller, a human takes over and works out the specifics.

For specified products there is no such handoff. The specifics are the purchase. Getting to “buy from this manufacturer” leaves every hard question unanswered.

The first column helps an agent decide who to contact. The second decides what should be purchased. You need both, but only one of them can lose you a warranty claim.

The buyer describes a job, not a product

Traditional e-commerce quietly assumes the customer already knows roughly what they need. They search “industrial epoxy” or “floor primer” and the store's job is to narrow the list. That assumption holds for the trade professional who has bought this category forty times. It falls apart for everyone else, which in most industrial catalogs is the larger and more profitable half of the market.

First-time buyers don't know the category, the terminology, the grade or the pack size. They know the outcome. I need to stop a joint leaking. I want to coat a balcony. I need something to stick outdoor stone down. I want to protect a factory floor from chemicals. These aren't searches. They're incomplete descriptions of applications, and the missing pieces are exactly the pieces that determine the answer.

Which means the system's first job isn't retrieval. It's interrogation — the polite kind. What's the substrate? Indoors or out? How much area? New or previously coated? Will it see water, heat, chemicals, movement, vehicles? What finish? Any cure-time constraint? Is a professional applying it? A good technical rep asks three or four of those and stops, because they know which ones actually move the answer. That's the behaviour to reproduce — not a twenty-field form, and not a chatbot that guesses to avoid seeming slow. The goal isn't a plausible paragraph. It's enough facts to make a decision somebody would sign their name to.

Knowing the products isn't enough to recommend one

You can build a decent retrieval layer that finds the right data sheet and hands it to a language model. That gets you further than most sites are today, and it is still not sufficient, because a good chunk of a real recommendation is arithmetic with conditional inputs.

Take the garage floor. How much material depends on the area, the coverage rate per litre, the number of coats, how porous the concrete is, expected wastage, the mixing ratio, the pack sizes on offer, the minimum order quantity, and whether a primer and topcoat are mandatory for that substrate. None of those steps is hard. Together they're conditional in a way that free-form generation handles badly: a porous slab drops coverage, the second coat consumes at a different rate, and a two-component system has to be bought in combinations that don't strand half a tin of hardener.

The division of labour that works looks like this, and I'd defend it in any category where a wrong number costs somebody a weekend:

The language model understands the buyer's words. The decision engine applies the product rules.

The model can absolutely turn “my garage is about 20 by 30” into 600 square feet. It should not be the thing deciding how many litres that is. That belongs to manufacturer-approved logic that produces the same answer twice and can show its working. I've written the longer version of this in Why Most AI Product Advisors Fail — the short version is that one model doing five jobs is one confident failure waiting to happen.

The most valuable knowledge you have is what your products can't do

Catalogs are built to describe capability. Decision systems live or die on the opposite.

Not suitable for continuous immersion. Not recommended on certain plastics. Can't be applied below five degrees. Won't hold over rising damp. Incompatible with that primer. Not for structural repair. Requires professional application. Must never be mixed with another manufacturer's system. None of that appears on a product page, because none of it sells the product. All of it is the difference between a recommendation and a liability.

Strip that knowledge out and an AI assistant will still produce an answer. It will be fluent, confident and occasionally wrong in ways that only become visible six weeks later when the coating lifts. So the model of a product needs more than features: suitability, exclusions, prerequisites, incompatibilities, warnings, a confidence level, and the conditions under which a human has to take over.

Which leads to the answer nobody demos, and the one I'd most want in a system recommending anything I had to stand behind:

“There isn't enough here for me to recommend safely — this needs technical review.”

That's not the system failing. That's the system knowing its edges, which is the trait that makes the other 95% of its answers worth acting on. It also happens to be the trait buyers verify you on. If your assistant has never once declined, they'll assume it can't.

A catalog stores facts. A decision graph stores relationships.

This is the upgrade the knowledge-catalog idea needs before it can carry a specified product. Facts in a list get you keyword matching with better manners. What you want is the relationships between the job, the product, the environment and the rest of the system: suitable for, unsuitable for, requires, compatible with, replaces, applied before, applied after, mixed with, calculated using, approved for, restricted in, superseded by, needs human review when.

Say a buyer asks for an exterior stone adhesive. A catalog returns everything with “stone” and “adhesive” in the text and lets them sort it out. A decision graph knows the questions that separate those products — natural or engineered stone, porous or sealed, vertical or horizontal, exposed or sheltered, frost and movement, staining risk, cure window, which primer, which grout. Same catalog, entirely different output. One is a shortlist. The other is an answer, with the rejected candidates and the reason each one was rejected.

Building that graph used to be the objection — too much manual work. Language models changed the economics: they can read manuals, data sheets, application notes and years of support email and propose the structure, with the low-confidence and safety-relevant claims routed to a human before anyone sees them. Models keep commoditising. An evidence-linked decision graph of your products doesn't. You can see how this plays out per category in coatings, adhesives and sealants and industrial consumables.

The order isn't the end of the decision

In service businesses the agent-driven journey ends when the appointment is booked. In technical products, the purchase is the beginning of a relationship that can run for a decade.

A commercial buyer describes an application, gets candidates, requests samples, tests them, approves a specification, raises a purchase order, reorders on a cycle, and then — the part everyone forgets — needs to know whether anything has changed since. Reformulated? Renamed? Discontinued? Is the SKU your distributor is now shipping genuinely equivalent to the one their spec was written against?

That's the real long-term asset here, and it isn't product discovery at all. It's the decision context behind the purchase: why this product was selected, which conditions were recorded, which sample was approved, what documentation applied at the time, and what has changed since. Keep that and you have a commercial memory around the specification that makes reordering safe and substitution auditable. Lose it and every repeat order is a fresh act of faith. Nobody has ever churned a specified account because the checkout was slow. They churn because a substitution went through that nobody could defend.

Some knowledge should be public. Some really shouldn't.

The video is right that businesses should publish detailed, useful information for AI systems to find. But “publish everything” is the wrong conclusion from a good premise, and it's the point where I'd slow a manufacturer down. Two planes, connected, with different rules.

The public plane is what gets you into the consideration set — the retrieval-and-grounding argument I made in LLM Product Discovery Isn't SEO. The controlled plane is what happens after, behind authentication, where the rules are current and approved and somebody is accountable for them. Publishing your exclusion logic to the open web doesn't make you more discoverable. It makes your competitor's catalog smarter.

Your support inbox is the roadmap for the knowledge base

The strongest idea in the original video is that companies already own the knowledge they need — it's sitting in customer conversations. That's true, and for technical products it's more than true, because the questions are diagnostic.

Every sales call, support ticket and distributor email tells you something specific: an application question you never thought to ask, a claim customers keep querying, two products people constantly confuse, a job type with no good recommendation, a quantity calculation buyers push back on, a companion product everyone forgets to order, the word customers use that isn't the word on your label. That last one alone is worth mining. Your catalog says “cementitious levelling compound.” Your customer says “the stuff that flattens the floor.”

What matters is that none of it enters the system automatically. The loop runs through review:

• Customer interaction — a real question in real language, captured where it happens.
• Knowledge gap — the system flags what it couldn't answer, or answered with low confidence.
• Evidence — the data sheet, the test result, the technical rep's reply. A CC on the email is usually all it takes.
• Technical review — a human who is accountable signs it off.
• Approved knowledge object — versioned, dated, and now available to every interface you have.

That's how you get compounding knowledge instead of accumulating drift. The alternative — letting an AI write its own facts back into the system — produces something that gets more confident and less correct every quarter.

Websites will matter. They just won't be the only door.

The claim that websites will stop mattering is deliberately provocative, and I think the accurate version is narrower. Websites stop being the only interface, and probably stop being the primary one. They keep doing plenty: human trust and verification, brand, deep exploration, legal and policy, comparison, documentation, direct purchase, support, and the fallback for every journey an agent can't finish — which, going by how buyers currently treat AI recommendations above a few hundred dollars, will be most of the expensive ones for a while yet.

The shift isn't from websites to no websites. It's from the website is the product knowledge to the website is one interface to the product knowledge. Once that separation exists, the same knowledge serves your site, your assistant, your sales team, your distributors, your customers' procurement systems and, when they arrive in volume, external shopping agents. One place to correct a fact. Every channel gets it right.

Today that shows up as a Finder on a manufacturer's own site, helping a human describe the job and walk out with the right products in the right quantities. Tomorrow the same decision service should be callable by somebody else's agent: describe an application, tell me what's missing, find suitable products, explain the exclusions, calculate consumption, pick the pack combination, add the companions, check availability, request a sample, reorder against an approved spec. The external agent stays the buyer's interface. It just stops inventing your technical logic from search results, which is what it will otherwise do. How it works covers the mechanics of the flow underneath.

AI-readable isn't the same as AI-actionable

The next phase of this won't be decided by whether AI systems can read your information. Most of them already can. It will be decided by whether they can act on it without anyone getting hurt.

A product description is readable. A defensible recommendation — right product, right variant, right quantity, right companions, exclusions honoured, evidence attached — is actionable, and that requires structure, context, currency, provenance and deterministic rules underneath the fluent part. Very few catalogs have any of it today, which is either a problem or a lead, depending on how fast you move.

A product description is AI-readable.A defensible recommendation is AI-actionable.One is content. The other is infrastructure.

The goal was never to help AI talk about products more persuasively. It's to help a first-time buyer — or the agent acting for them — get the right product, in the right quantity, with the right supporting materials, for the job actually in front of them. That's the point where product knowledge stops being marketing and starts being plumbing.

Source acknowledgement. This piece was prompted by Phil Risher's video “Your Website Won't Matter in 3 Years”. The agreements, the disagreements and the application to specified products are mine.