Building a Grounded AI Product Assistant

A useful answer has to respect the business boundary

I implemented the first U.S. GolfJoy website assistant to help visitors understand products, packages, room requirements, software, and published policies. Someone comparing two launch monitors needs a useful answer and a way to check it. A confident paragraph assembled from unrelated regional information can make that buying decision worse.

I separated explanation from authorization. The assistant could explain a published return policy, but it could not approve a refund, determine an individual warranty claim, invent a discount, promise a delivery date, or diagnose a complex repair. Those requests needed a human follow-up. This boundary was part of the application flow, rather than a request for the model to be careful.

Use a small, controlled knowledge set

The knowledge set was deliberately narrow: the U.S. product and package catalogs, published CMS content, FAQ, public policies, contact information, and approved supplemental knowledge. Supplemental entries had publication state, region, language, enablement, ownership, risk level, and optional expiry. Draft, disabled, expired, or out-of-region material did not become customer-facing evidence.

For this structured catalog, I used lexical retrieval with product recognition, the current page, question category, and source risk. A larger retrieval stack would not resolve a bad authority rule. The first question was whether the selected source was eligible to answer the visitor, followed by whether it matched the question.

Product identity required particular care. A model name with a suffix must not collapse into a different product. The acceptance set included comparisons between GR2 and GR3, as well as the distinction between GR3 and GR3 Pro. That kind of exact entity handling matters more than adding another conversational flourish.

Do not spend a model call to look up a known price

Basic prices, specifications, included items, and explicit product comparisons could be answered directly from structured facts. I routed those questions through deterministic answers before considering model generation. This reduced the number of places where a factual lookup could become a probabilistic rewrite.

When a question required synthesis, the model received the selected, eligible sources and returned structured output with source identifiers. The server checked those identifiers against its allowed set. Missing or invalid source identifiers led to a safe fallback. A citation needed to resolve to a source the application had actually supplied, rather than a URL the model happened to produce.

The source link was also useful to the visitor. They could inspect the product or policy page and continue the buying journey. The assistant remained a guide to the product system, without gaining authority over checkout or customer accounts.

Carry conversational context without trusting client history

Follow-ups such as 'How much do they each cost?' need the products from the preceding question. I preserved that context from user messages, including plural references and explicit comparisons. Otherwise an apparently correct answer can silently drop one of the two products.

I did not treat assistant messages supplied by the browser as verified facts. A client can alter its stored conversation and send a fabricated previous answer. The application resolved entities from the user's questions and grounded the next answer again. Injection and cross-region boundary checks ran before the model call, and the model had no arbitrary URL or tool access. These were tested controls, not a claim that all prompt injection is solved.

The failure path still needs to help the visitor

A provider outage, exhausted daily allowance, or missing source should not remove the customer's next step. The fallback returned the closest verified source where available and offered human follow-up. High-risk requests used that path intentionally, even when the model was healthy.

Human follow-up was a separate, explicit action. The visitor reviewed an editable summary and supplied contact details before confirming submission. Chat history stayed in bounded browser storage with expiry and a clear action to remove it. The application did not persist full conversations or AI answers as analytics. Consent-controlled, redacted question events supported knowledge-gap review, and the server checked consent rather than trusting a boolean in the request body.

Evaluate the boundaries, then the generated answers

The July 2026 acceptance record reports 61 of 61 standard routing and boundary questions passing, followed by 53 of 53 live model cases. The sets covered exact products, multi-turn comparison, plural price questions, historical model isolation, missing sources, cross-region policies, injection, and provider failure. These are results for that reviewed revision and those test sets. They are not a measured customer success rate or proof that every possible question is handled.

I also tested the surrounding system: desktop and mobile presentation, source links, storage being unavailable, consent enforcement, and an explicitly marked test lead reaching the receiving system. A form returning success was insufficient if the lead had not actually arrived.

Later U.S. preview release records continued to include real assistant-question smoke checks. The public product evidence remains the U.S. preview. My main lesson is to evaluate the evidence pipeline and the handoff path as product behavior, rather than grading only whether the final text sounds helpful.