GenAI Research Assistant for a Virtual Software Company

A Global Software Company Serving The Retail Sector

Our client is a global technology company delivering virtual solutions for retail. Its software supports retail companies in planning, testing, and validating shelf-level commercial decisions in a digital environment, ahead of execution in physical stores.

Each study the platform runs produces a substantial analytical output: performance results across tested scenarios, model predictions, and explanations of which variables moved which metrics. That output is the product the client’s customers actually pay for, and its value depends entirely on how easily those customers can get to it.

The Insight Existed. Reaching It Required an Analyst.

Study results lived in a data platform that only specialists could query directly. Anyone outside that group, including the client’s own customers and much of its internal research staff, had to request analysis and wait for someone to produce it.

This produced a familiar set of constraints:

• Every follow-up question became a ticket. Research findings arrived as fixed deliverables, so any question the deliverable did not anticipate required a new round of manual analysis.
• Access depended on SQL skills. The people with the strongest commercial understanding of a study were frequently the least equipped to interrogate its data.
• Analyst time went to repetitive extraction. Specialists spent hours answering variations of questions they had already answered rather than on new work.
• Model explanations stayed internal. SHAP values quantified which factors raised or lowered sales-related metrics, but that layer was effectively unavailable to the people who would act on it.

The client needed a way for non-technical users to ask questions of study data directly, in plain language, and get answers they could act on and share.

Chat Over Data Is Easy to Demo and Hard to Trust

A conversational interface over an analytical database is straightforward to prototype and difficult to put in front of paying customers.

The failure mode is well known. An assistant that generates free-form SQL against a production warehouse will eventually write an expensive query, misread a schema relationship, or answer confidently from a partial result. When the user is an internal analyst who can sanity-check the output, that is an inconvenience. When the user is the client’s customer reading a research finding, it is a credibility problem for the platform itself.

There is a second, less obvious gap. Most assistants built over analytical data answer descriptive questions well: what the result was, how one scenario compared to another. The commercially valuable question is different. Users want to know which factors drove the outcome, which is an attribution problem that requires model explanations rather than aggregation over a table.

The design followed from both points. Rather than giving the model open access to the data and hoping for the best, we gave it a bounded set of purpose-built tools, including one that surfaces SHAP-based driver analysis. The model decides which tool to call and how to frame the answer. It does not decide how the data is reached.

A Bounded-Tool Agent Behind a Conversational Front End

We built a full-stack GenAI assistant: a Chainlit chat interface, a FastAPI backend, and a LangGraph agent orchestrating an Azure OpenAI model over a controlled tool set.

The agent layer.
A LangGraph agent interprets the user’s question, selects the appropriate tool or sequence of tools, and composes the response. Because the graph makes the reasoning path explicit, tool usage stays inspectable rather than emergent.

The tool set.
The agent works through a defined set of capabilities rather than improvising data access:

• Spark and Delta SQL access for querying study results
• Research context management, so the assistant knows which study, client, and scenario a question refers to
• Research summarization for condensing findings
• SHAP-driven analysis identifying which factors increased or decreased sales-related metrics
• Chart generation for visual answers
• Excel export for outputs users need to take elsewhere

The backend.
FastAPI handles data access, tool execution, session persistence, response streaming, and telemetry. Persistence matters more than it appears: analysis is iterative, and a conversation a user can leave and resume is what separates a working tool from a demo.

The front end.
Chainlit provides role selection, resumable conversations, inline chart rendering, and downloadable files, so an answer arrives as something usable rather than as text to copy elsewhere.

Why bounded tools rather than open generation?
Constraining the agent to a fixed tool set trades a small amount of flexibility for the properties a customer-facing product requires: predictable queries, controlled data access, and behaviour that can be tested and audited. In an internal experiment that trade is optional. In software exposed to the client’s own customers, it is the entire basis on which the feature can ship.

Why SHAP through conversation?
Model explanations are usually reserved for data scientists, largely because reading them requires context. Wrapping SHAP output in a conversational layer moves that interpretive step to the assistant, so a commercial user can ask why a metric moved and receive an answer grounded in the model rather than in speculation.

Technology Components

How The System Works

• User question. A user asks a question in plain language through the Chainlit interface, within a selected role and study context.
• Agent interpretation. The LangGraph agent determines what the question requires and which tools to invoke.
• Controlled data access. The relevant tool queries study results, prediction outputs, SHAP values, or client metadata through the Spark and Delta layer.
• Analysis and composition. The Azure OpenAI model composes an answer from the returned data, including driver analysis where the question concerns causes rather than outcomes.
• Delivery. The response streams back as text, a rendered chart, or an Excel export, depending on what was asked for.
• Persistence and telemetry. Session state is retained for resumable conversations, and Application Insights captures usage and performance data.

• Direct access to study results. End clients and internal research teams query outcomes conversationally instead of routing requests through specialists.
• Answers about causes, not only outcomes. SHAP-based analysis is available on demand, so users can ask which factors raised or lowered a metric and receive a model-grounded response.
• Analyst capacity returned to analytical work. Repetitive extraction and re-cutting of existing findings no longer consume specialist time.
• Outputs that leave the conversation. Generated charts and Excel exports move directly into client presentations and internal reporting.
• A governed foundation for AI-assisted research. Controlled tool usage, persistent sessions, and telemetry give the client an architecture that can extend to new tools and studies without loosening data access.
• Product-grade rather than internal-grade. Role selection, session persistence, and monitoring make the assistant suitable for exposure to the client’s own customers, not only to internal staff.

Turning Data Into Production-Grade AI Systems

If the insight in your data is reachable only through the people who know how to query it, we can help you open it up safely. Contact us to discuss your use case.