AI applications need direct access to live operational data from databases, warehouses, and APIs to make useful business decisions.
2
Retrieval augmented generation and vector stores can lose the structure, context, and freshness of the source data.
3
Snow Leopard uses AI to understand a question and route it to the right sources, then uses deterministic query-building methods for each data system.
Summary
Deepti Srivastava argues that enterprise AI will remain limited until it can use operational business data directly. Most current applications sit beside production systems and focus on documents, PDFs, or other unstructured sources. Moving structured data into a lakehouse or vector store can make it stale and remove the business context encoded in the original system. Snow Leopard's approach is to interpret a natural-language question, identify the relevant sources, and retrieve information from them when needed. AI handles understanding and routing. Data-system techniques handle precise query construction for systems such as PostgreSQL, BigQuery, Salesforce, and delivery APIs. Deepti is also critical of MCP as a connector standard because it does not define the business logic or production hardening required for accurate answers. She expects dashboards to remain useful, with conversational retrieval answering follow-up questions about the data behind them.
Enterprise AI needs live operational data to affect real business work
Deepti says LLMs are a genuine platform shift, despite her background in production infrastructure and her dislike of hype. For AI applications to change how people work, they need access to a business's operational data. She means structured information in SQL and NoSQL databases, warehouses, and APIs. She sees a large gap between those systems and LLM-based applications, which is the problem Snow Leopard was created to address. Demetrios Brinkmann agrees that companies often connect models to documents, Notion, or Jira while leaving databases and APIs outside the new AI stack.
Applications built beside the production stack miss the business value
The conversation contrasts AI applications that chat with PDFs with applications embedded in a company's critical path. Deepti says teams she spoke with, including platform and AI leaders, lacked a good way to put LLMs into their existing stack. Enterprise technology works in an ecosystem, so a new system has to fit the data sources, workflows, and business context already in place. A separate AI layer may be interesting, but it does not automatically create new business or user value. She says Snow Leopard was preceded by conversations that validated this problem across enterprises and smaller companies.
Reasoning cannot compensate for stale or irrelevant data
Deepti's first major objection is that moving all data through ETL into a lake, lakehouse, or similar store does not solve the retrieval problem. Her second is that more intelligent agents will still make poor decisions when the data is wrong or stale. She uses a person returning from a six-month coma as an example: intelligence alone cannot answer who currently holds a political office without updated information. The data must be available in the right place at the right time. Demetrios adds that supplying a large amount of irrelevant context can also produce a bad answer, because the model may focus on the wrong detail.
Vector stores change structured business data into fuzzy context
Deepti says many hallucinations come from failing to retrieve the right information, although models also have inherent reasons to hallucinate. She warns that too much context can create another failure mode. In her view, typical RAG systems extract data from business systems, place it in a vector store, and use similarity search at query time. Vector stores are designed for fuzzy matching, not exact point lookups. Extracting records from databases, warehouses, Salesforce, or HubSpot can remove their structure and business context. The result can also be stale because the source data was copied earlier.
Direct retrieval can replace many data pipelines for ad hoc questions
Deepti describes an architecture with a box between business data systems and LLM systems. Instead of building a pipeline for every new question, the system connects to sources and fetches data when needed. Her coffee-order example requires information from an order system and a delivery provider, followed by a join across those sources. Snow Leopard is intended to identify both sources, build the appropriate query or API request for each one, and return current information. This avoids copying data into a common store solely to perform a cross-source join. Deepti says data engineers and analysts can spend 70 to 80 percent of their time maintaining this kind of infrastructure.
Dashboards will remain useful when users can ask follow-up questions
Deepti does not expect dashboards to disappear because visual displays make large amounts of information easier for people to understand. She wants users to ask questions about the data behind a dashboard without waiting for a new dashboard or warehouse change. She recalls needing several weeks to get a churn dashboard and then waiting again for follow-up cuts by geography and industry. In the proposed model, a user could ask BigQuery or another source for those details and join the result with current customer information from Salesforce. The dashboard stays useful while the retrieval around it becomes more immediate.
MCP connectors still leave routing and business logic unresolved
Deepti calls MCP a useful open-source start for connecting tools, but says it does not solve the hardest parts of the problem. An MCP server can connect to PostgreSQL, yet it may not know which query to run, how a business defines a field, or whether two similarly named columns mean different things. Different people can build MCP servers differently, so production teams may need to test, harden, and modify them. Demetrios describes a more controlled setup in which different agents have access to different databases and glossaries. Deepti says Snow Leopard aims to handle routing and business logic without requiring those boundaries to be hardcoded.
AI should handle interpretation while deterministic systems build exact queries
Snow Leopard divides retrieval into three parts. First, it uses natural-language understanding to interpret the question. Next, it combines the question with data infrastructure and business logic to decide which sources to use. Finally, it constructs the precise query for each source using deterministic data-system methods rather than asking an LLM to perform text-to-SQL. PostgreSQL, BigQuery, Snowflake, and other systems have different dialects and rules, so the query must match the target system. Deepti says an internal comparison produced 98 to 99 percent accuracy for this SQL lookup task without fine-tuning, while the system it was compared with produced about 6 percent accuracy.
Production retrieval still depends on accuracy and reliability
Deepti says the main production concerns for these AI systems are currently reliability and accuracy. Teams may accept a 15-minute wait if the answer is correct, but a fast answer that uses the wrong source or query is not useful. She points out that an MCP server built in a few hours may be easy to try, while production use requires testing and hardening. She wants systems engineers and AI practitioners to work together because LLMs handle interpretation well and deterministic infrastructure handles precise retrieval. Her argument is practical: AI applications need both capabilities to move beyond prototypes.
"For LLMs to be the platform shift that they are, for Gen AI, for AI applications to truly change the way people live, work, behave, you need to connect them to the crown jewels of any business, and that is operational data."Deepti Srivastava04:10
Who should watch
You are building an AI assistant or agent that needs current information from operational databases, warehouses, or APIs.
Your RAG system gives plausible answers but loses source structure, business context, or freshness.
Your team is deciding whether MCP and text-to-SQL are ready for production use, and you want a design that limits the LLM's responsibility.
