Why Most AI Product Advisors Fail

Here's a demo I've now watched some version of a dozen times. A contractor types into a chat box on a waterproofing manufacturer's site: “Water is coming through the basement wall after heavy rain.” A moment later the AI comes back with a confident recommendation, a coverage estimate, a price, and a link to buy. The room nods. It looks like a digital sales engineer that never sleeps.

Then it meets a real catalog and real customers, and the cracks show. It recommends a surface coating for a wall that's actively leaking — which any technical rep would tell you fails within weeks. It quotes a price that ignores the customer's contract. It calculates coverage by, essentially, guessing. The demo was real. So was the liability.

The reflex is to blame the model, or to conclude AI “isn't ready” for technical selling. I think that's the wrong lesson. The model is doing exactly what language models do. The failure is architectural: we asked one probabilistic system to perform jobs that belong to fundamentally different disciplines. Understanding language, engineering a solution, calculating quantities, resolving contract pricing, and reserving inventory are not variations of the same problem. They're different problems that reward different kinds of reasoning.

So the useful question was never “Should we use AI?” It's this:

Which decisions are probabilistic, and which decisions must remain deterministic?

Once you take that question seriously, the whole design of an industrial product advisor changes.

The temptation of the all-knowing assistant

The seductive version of an AI advisor is a single “smart assistant” that owns everything. One contractor sentence goes in, and the same model is expected to understand the problem, identify the failure mode, read the substrate, choose the right system, calculate material coverage, pick pack sizes, apply regional pricing, check stock, and produce a recommendation the manufacturer can legally stand behind.

On a slide, that architecture is elegant — one box, one brain. In production it's a single point of confident failure. A language model is superb at interpreting messy human language. It is not a pricing engine. It is not an ERP. It is not an inventory database. And it is emphatically not a deterministic engineering calculator. Ask it to be all of those, and it will happily sound like all of them, right up until the moment a hallucinated spec becomes a returned pallet.

The strongest AI systems I've seen don't replace those other systems. They orchestrate them. Each layer does the one job it's actually good at.

One brain, or a team of specialists

Think about how the recommendation would happen with humans. The customer talks to someone who understands their problem. That person leans on shared vocabulary, pulls the relevant data sheets, applies hard engineering rules, hands the numbers to a calculator, checks the price list, and only then writes the order. Nobody expects the salesperson to also be the pricing database. The software version should respect the same division of labor.

Notice where the AI lives. It sits at the top, where ambiguity is real, and it steps back as the pipeline moves toward things that must be exact. That's not a compromise that limits the AI. It's the design that makes the whole system trustworthy.

AI belongs only where uncertainty lives

Read the flow from the top down and you can watch the certainty increase at every step:

AI does the messy interpretive work at the front. Everything downstream becomes progressively more deterministic — which is exactly what you want the moment money, warranties and safety enter the picture.

A good advisor knows when it doesn't know

The most underrated feature of a real technical rep isn't knowledge. It's restraint. When a customer says “I have cracks in my floor,” a bad system rushes to recommend something. A good one recognizes it doesn't have enough to be safe yet, and says so:

“I need a little more before I recommend a repair system.”

Then it asks the single question that removes the most uncertainty — is the substrate concrete or stone? Indoors or out? Any chemical exposure? Vehicle traffic? That turns a product search into a guided diagnosis. It's an interview, not a lucky guess, and it's only possible when a deterministic layer can detect what's missing rather than papering over the gap with fluent prose.

Deterministic rules are what build trust

Industrial recommendations have consequences — warranties, liability, safety, compliance. So the advisor can't just be right; it has to be able to show its work. The difference is the gap between:

“The AI recommends Product X.”

and

Product X was recommended because it's rated for forklift traffic, tolerates damp concrete, meets your chemical-resistance requirement, and is available in your region. Product Y was excluded because it can't take continuous immersion.

Every line of that second answer traces back to either documented product knowledge or an explicit, version-controlled business rule. The experienced sales engineer already carries thousands of those rules in their head; the software just makes them explicit, auditable and reviewable. That traceability is what earns the confidence of customers, distributors and your own technical team.

And it isn't only coatings. The same architecture applies anywhere products are specified rather than casually bought — adhesives, sealants, industrial chemicals, filtration, agricultural products, engineered components, medical devices. Anywhere expertise has traditionally lived inside a handful of experienced people.

How Selrite addresses every layer

This is the part I'm closest to, so I'll be concrete. Selrite is built as this separation of responsibilities, not as one clever prompt. The AI handles intent. A structured knowledge base and ontology give the reasoning something real to stand on. A deterministic inference layer applies the exclusions and compatibility rules. Coverage, pricing and commerce stay in the systems that own them. Each layer does its job and hands off.

The layer most people never see — and the one that quietly decides whether any of this works — is the knowledge base. If the ontology and the documented rules are thin, every layer above them inherits the gaps. So we made curating that knowledge a first-class, human-legible activity rather than a buried config file.

Each term isn't just a word in a list — it carries the relationships and rules that let the inference layer act on it. Adding knowledge is a deliberate, reviewable step: you capture the concept, the evidence behind it, and how it connects to products, substrates and exclusions. That's the point where an experienced engineer's judgment becomes something the system can apply consistently, at scale, to every customer.

A knowledge base that never stops learning

Here's the part that makes this compound over time instead of going stale the way a hand-tuned prompt does. The knowledge base is designed to keep learning from three sources, continuously:

From new writing. Every technical article, application note and blog post the team publishes — including the one you're reading — becomes source material the system can absorb into its structured knowledge, so newly articulated expertise doesn't stay trapped in a PDF.

From real customer questions. The actual language customers use to describe their problems is the best training signal there is. Every real query sharpens intent understanding and surfaces the concepts and edge cases the ontology hasn't captured yet.

From expert answers. When a technical rep replies to a genuine customer question, that reply is copied to the knowledge base as a matter of course. A CC on the email is all it takes. The expert's judgment — the reasoning, the exclusion, the “actually, in that case you'd want…” — gets captured at the moment it's given, reviewed, and folded into the knowledge every future customer benefits from.

That last loop is the quiet superpower. Institutional expertise usually walks out the door when a senior engineer retires. Here, every expert answer makes the advisor a little smarter and a little more complete — the knowledge base absorbs the team's reasoning as fast as they can give it, and it never forgets.

AI doesn't replace expertise. It scales it.

That's the reframe I'd leave you with. The biggest misconception about enterprise AI is that it eliminates expertise. It doesn't — it distributes it. The ontology captures the language. The inference engine captures the engineering. The pricing engine captures commercial policy. The commerce platform captures the transaction. The AI is the conductor, not the whole orchestra.

The strongest AI product advisors won't be the ones running the biggest language model. They'll be the ones with the clearest separation of responsibilities — and a knowledge base that gets better every week, from every article written, every question asked, and every expert answer given.

Understanding is probabilistic.Decisions are deterministic.Transactions are transactional.

Get those three principles right, and AI stops being an impressive chatbot and becomes something far more valuable: a trusted technical advisor.