A pre-launch checklist for an AI agent that answers product questions

A shopper asks whether a jacket is available in their size and whether the displayed price includes a promotion. The agent gives a confident answer, but its product information is out of date. The exchange may sound helpful while leaving the shopper with a false expectation that a staff member has to resolve later.

Reviewing an AI agent that answers product questions takes more than checking its tone. Follow the whole path: what the customer asks, where the answer comes from, what happens when information changes, and who takes over when the agent cannot help. Use the checks below before making it available to shoppers.

1. Set boundaries for the questions it can answer

Start with actual enquiry types: features, sizing, materials, compatibility, promotions and comparisons. Separate questions answerable from approved product content from those that require a current operational check or a judgment about an exception. For each type, identify the source, the conditions under which an answer is allowed and the fallback if those conditions are not met.

Be specific about promises it must not make. An agent should not guarantee delivery for an event without a confirmed date for that order. Nor should it infer a returns policy from product copy. Test whether it asks for a missing model number or variant rather than silently choosing one.

Some repeated questions point to a simpler fix: clearer product pages, a better size guide or a structured selector. Conversational AI is useful when people ask varied questions or combine several attributes. It should not be expected to repair a catalogue that nobody owns or maintains.

2. Audit the information behind the answer

List everything the agent can use: catalogue records, specification sheets, sizing information, commercial policies and any connected systems. Check for conflicting versions and missing fields. Who owns corrections? How does an update reach the agent? Fluent wording does not make an outdated document reliable.

Test closely related items, similar names and incomplete listings. Ask about a feature present in the approved source, then one that is absent. The agent should answer the first and acknowledge the gap in the second, rather than fill it with a plausible guess. Reviewers should be able to trace an answer back to its supporting information, even if internal source details are not shown to customers.

Keep a record of each failure: question, product, answer, source and required correction. If several failures originate in the same catalogue field, fix that field first. Rewriting the agent’s instructions while leaving bad source data in place creates another layer to maintain, not a dependable answer.

3. Check how prices and stock are handled

Prices, offers and inventory can change after a product description is prepared. Before the agent states a price or confirms availability, establish which system supplies the information, which variant it refers to and when it was checked. An appropriate system connection may allow a current lookup; a static copy should not be described as a live stock check.

Define distinct responses for verified, stale and unavailable information. If stock cannot be checked, the agent should say so and offer a way to confirm it instead of asserting that an item is available. Examine price context as well: variants, promotion conditions and channel differences. Selecting the applicable price is a rules and data problem, not something to leave to the model’s conversational confidence.

Run a controlled change test. Update a price or stock value in a test setting, then inspect what the agent says before and after that change reaches the information it uses. If the team cannot explain that sequence, hold back definitive claims about those fields until the data path is clear.

4. Test uncertainty and the human handoff

Easy questions show whether the agent can answer; awkward ones show whether it knows when to stop. Try partial product names, ambiguous sizes, discontinued items and questions that combine multiple products. Check whether it requests the minimum missing detail, describes a specific limitation or passes the enquiry on. A fabricated answer should count as a failure even when it sounds natural.

A handoff should give the staff member useful context: the original question, the product and variant identified, what has already been confirmed and why the case remains unresolved. Ask for contact details only when needed to continue, and tell the shopper when a person will take over. Decide who receives these cases, through which channel, and how unresolved enquiries are tracked. Without an owner, “someone will get back to you” is not a working process.

5. Make a limited launch decision

Build a test set covering common questions, higher-impact mistakes and failures found during review. For each case, check accuracy, support from current information, appropriate disclosure of uncertainty and correct handoff. Run the checks again when catalogue data, price rules or agent instructions change.

Limit the initial launch to the product categories and question types that have passed review. Give staff a straightforward way to flag problematic answers, and assign responsibility for fixing the source, workflow or rule involved. Look at what gets handed off too: repeated questions may indicate gaps in product pages or customer information, not just a flaw in the agent.

The goal is not to make the agent answer everything. It is to help shoppers without making commitments the business cannot keep. If you want to test these checks against your catalogue and support process, contact Cibercoding to review a specific use case before launch.