Rationale

One of Lab651’s clients – manufacturer of Automotive aftermarket products Old World Industries (OWI) – has a great feature on their site that we call the Product Finder.

The Product Finder allows the User to submit their vehicle’s information – year, make, model – through a series of dropdown menus. Once a full set of product information has been provided, the User is directed to a product listing page that displays all OWI products that fit the User’s vehicle. At the heart of this feature is the Opticat API, which provides both vehicle year/make/model hierarchies as well as product fitment information.

The existing Product Finder feature has served users well, though entering vehicle information through the sequence of dropdown inputs can be cumbersome, especially on mobile devices.

Since the core of the original feature is gathering and submitting structured information (a vehicle’s make, model, etc.) we decided to create a new product finder interface that would take in raw, unstructured text requests from the User, then use an LLM to extract relevant vehicle information. This feature, which we call the AI Vehicle Finder (AIVF), takes the form of an unobtrusive chatbot. When opened, AIVF prompts the user for the required vehicle information. The User submits their vehicle information request to the AIVF as natural language. The LLM cleans the entry and extracts relevant information. When a complete set of vehicle information is retrieved, the user is then redirected to the product results page.

Considerations

Before we started development of the AIVF feature, we set aside some time to identify any issues that might arise. One of our major concerns was the potential for the LLM to be used to generate responses outside of the feature’s purview. To prevent the LLM from responding to, for example, the User’s request for a Chicken Bolognese recipe, we carefully crafted the prompt to keep the project on track. This involved not only narrowing down the topics that the AI could respond to (‘automotive vehicles’, ‘products sold by OWI’) but also instructing it to redirect the conversation to these topics if an off-topic request was attempted.

Another consideration was that we needed the LLM’s response to include both a human readable response for the user (asking, for instance, to provide any missing information) but also machine readable, structured information (a JSON structure holding the extracted vehicle information). While LLMs’ ability to generate convincing natural language is well known, it is also very capable at producing well-formatted and structured JSON. During development, we found that the LLM we were using occasionally returned the JSON part of the response structure as markdown, not valid JSON, so we had to update the system instructions to specify that this part of the response be returned as valid JSON.

The final consideration was around security: while a user’s vehicle information is not currently considered PII, with the ever growing importance in data privacy, laws and practices we wanted to minimize the storage of user information on our servers. This resulted in a choice to keep as much user information on their machine (and off of our servers) as possible.

Architecture/Services

Our app already had an endpoint for retrieving vehicle hierarchy information from the Opticat API, so the majority of the work centered around the following:

• Developing the front-end UI
• Setting up the LLM (developing the prompt and configuring the LLM back-end)
• Creating a web API to pass requests from the front end to the LLM
• Setting up logic to handle sending the user’s raw text to the web API
• Setting up logic for handling the LLM’s response

To avoid saving identifiable user information on our servers, we placed the bulk of the logic on the front-end and run the majority of the logic in the browser.

This resulted in the following flow:

The User submits a request, the front-end passes the User’s raw text to our app’s LLM servlet which does a little processing, then hands it off to the LLM, the LLM returns a response consisting of 1) a human readable request for any missing information and 2) structured JSON containing extracted Vehicle information, the front end parses the extracted Vehicle information and sends a request to the Vehicle Hierarchy endpoint to verify the Vehicle Information.

In addition to storing identifiable user information out of our servers, this sequential front-end flow can allow the cascade of server requests to execute in sequence allowing a single request to appear to the user to complete somewhat ‘faster’.

During prototyping and development we chose to use OpenAI as our LLM because of its rapid set-up speed and ease of use. As we were finishing up development, we decided that – for increased flexibility, security, and billing considerations – AWS would be a better home for our production AI needs. AWS offers a huge range of AI options, most of them either not suited or overkill for the AIVF. After surveying these options, we chose to use a pure-text model hosted through Bedrock. Bedrock not only provides an array of models, but it also allows direct access on demand through the Bedrock Runtime. Since we did not need to build an agent we chose a foundation model that could be accessed directly through the Bedrock Runtime and that could take into account not only the user’s most recent request, but the user’s entire session history.

Anthropic’s Claude Haiku model fit the bill perfectly. Setting up Bedrock Runtime requests with the Java AWS SDK package was a breeze.

Another benefit to using AWS was the Analytics and Alarm ecosystem provided by CloudWatch. This allows us to not only measure usage of the AI service but also track errors that arise, as well. We came into this product with an existing analytics dashboard, so adding AIVF’s usage metrics dashboard was trivial. We were also able to set up basic monitoring and error notification easily through CloudWatch.

On the front-end, we added GA4 events that fire during each new session and completed session. This gives us a good sense of how users are interacting with the service itself as well as the AIVF flow completion rate.

Real World Usage

After extensive testing and input from internal stakeholders, the AIVF went live in production in April. Adoption has been organic, steadily increasing from 50 new sessions per day to, at the time of writing, over 300. About 80% of AIVF ‘sessions’ are completed, which suggests that the overwhelming majority of users find the AIVF to be easy to use and useful for finding products.

Users tend to use the AIVF on their mobile devices, which matches overall web usage, while about a quarter of engagement occurs on the desktop.

Summary

By partnering with Lab651, Old World Industries transformed a critical feature into a seamless, AI-powered experience that drives engagement, boosts conversions, and strengthens customer trust. If your organization is looking to modernize legacy tools or explore the power of AI to enhance user experience, our team is ready to help turn vision into value.