Most people don’t think about databases.

They sit quietly underneath modern software systems, powering applications, storing operational data, and enabling everything from simple transactions to complex business workflows. It’s only when something fails—a payment doesn’t go through, a page doesn’t load, a number looks wrong—that their importance becomes visible.

Over the past decade, the demands on these systems have changed significantly. The rise of the internet and SaaS reshaped how they were used and what was expected of them. We are now entering another transition, where the shift is in how software systems are constructed and used in the age of AI.

This is a reflection on how databases evolved over the last ten years, and what those changes suggest about the decade ahead with the full adoption of AI in the enterprise.

Let’s quickly recap the old world. Prior to the SaaS era, most operational systems operated in environments where growth was relatively predictable. Databases were designed accordingly. Systems like Oracle RAC and IBM DB2 dominated, optimized for large enterprises with stable workloads, centralized infrastructure, and the ability to provision capacity ahead of demand.

These systems were sophisticated and powerful, but they were also shaped by assumptions that suddenly no longer held true: that scale would increase gradually, that vertical scaling was sufficient, and that cost of reliability was high. In many cases, they provided capabilities well beyond what the average workload required, but enterprises were tuned towards paying for peaks and pre-provisioned capacity.

SaaS and Internet-Scale Growth

The shift to SaaS disrupted all those assumptions.

Internet distribution enabled companies to reach large user bases almost immediately, and growth curves became both steeper and less predictable. Instead of steady increases in load, systems had to accommodate sudden surges in users, transactions, and data volume, often within compressed timeframes.

More importantly, operational data became tightly coupled to revenue. Systems managing customers, orders, inventory, or advertising were no longer back-office infrastructure—they were the business itself. Database performance and reliability moved directly onto the critical path.

At the same time, with the explosion of SaaS, companies experiencing this growth were not large enterprises. They were cost-sensitive and operationally lean startups or SMBs, which made traditional enterprise database solutions too costly and impractical for their initially simple needs.

Adapting Existing Systems

Rather than replacing databases outright, teams adapted what was available.

One path involved using systems that were already capable of handling large volumes of data—key-value stores, early NoSQL systems, and even data warehouse infrastructure. These systems provided scalability, but they were not designed for transactional workloads. Key-value stores sacrificed structure, and warehouses were optimized for analytical queries, not low-latency operations.

Using them for operational systems meant relinquishing relational models, transactional guarantees, and SQL as a unifying abstraction. The cost of that decision was not always immediately visible, but it manifested as increased complexity in application logic. Responsibilities traditionally handled by the database—joins, consistency, integrity—were pushed outward into the application layer.

The other solution that companies reached for to preserve transactional consistency was to extend relational systems themselves.

Sharding became (and in a lot of cases still is) a common strategy: partitioning data across multiple databases and routing requests at the application level. This approach preserved familiar semantics within a shard, but introduced significant complexity. Data had to be continuously rebalanced, cross-shard queries became difficult, and application logic grew more complex and brittle.

Many large-scale systems relied on some form of sharded architecture, but the operational overhead was substantial. It worked, but it required constant intervention by teams of data engineers and DB experts.

Architectural Constraints

Across both approaches, a common pattern emerged – systems were being stretched beyond the assumptions they were originally built on.

Relational databases like MySQL and Postgres were fundamentally designed for a single-node architecture. Scaling them beyond that model required layering additional mechanisms—sharding, replication, routing—on top of that core assumption.

This led to an increasingly clear realization that architectural boundaries aren’t easily bypassed. Systems can be extended beyond their original design, but scaling will hit the limits of the original architectural constraints, and the complexity of doing so will compound exponentially over time.

Globally-distributed Databases

This realization led to the next phase in database evolution where adjustment wasn’t incremental, but a fundamental shift in the relational database architecture.

A new type of operational database designed from the ground up with scalability as a first-class concern. Systems like Spanner integrated ideas from distributed storage and file systems directly into the database layer. Instead of treating scale and data distribution as an external concern, it became part of the core design.

This had several implications. Storage models became more append-oriented. Concurrency control mechanisms changed. Transactional guarantees were preserved, but required new approaches to coordination and consistency.

Perhaps more importantly, tradeoffs that were previously implicit became explicit. Concepts like snapshot reads, consistency levels, and latency versus correctness were directly surfaced to the application developers.

The system did not eliminate these tradeoffs. It made them visible.

A New Shift: Who Uses Databases

If the last decade was defined by how databases adapted to scale, the next shift is defined by how they are used—and by whom.

Two distinct but overlapping patterns are emerging.

Agents as Users

In the world of AI agents managing and controlling business workflows, databases are created, used, and discarded by agents as part of a task.

An agent may provision a database to organize intermediate state, populate it with structured data, query it, and tear it down once the task is complete. In this model, the database is not a persistent system of record but a transient tool. Decisions about schema, storage, and lifecycle are made internally by the agent and never exposed to the end user.

This shifts the emphasis toward:

• rapid provisioning and teardown

• API-first interaction models

• systems that can be composed and discarded efficiently

The database becomes part of the execution environment rather than a system directly managed by humans.

Existing systems with (non-AI) users

At the same time, human-operated systems—and the databases underlying them—are not going away anytime soon.

Most business-critical data continues to reside in long-lived systems of record:

• relational databases and warehouses

• SaaS platforms exposed through APIs

• internal services built over years of iteration

These systems encode not just data, but business processes and institutional knowledge. Replacing them completely is just not practical.

Instead, agents automating existing workflows explicitly need to operate within this existing landscape—querying data, triggering workflows, and integrating across systems that were not designed with them in mind.

The result is a dual mode of interaction: databases as ephemeral tools within agent-driven workflows, and databases as durable systems of record shaped by human decisions over time but accessed by agents.

Semantics: the old new frontier

In both cases, access to data is no longer the primary challenge. Understanding it is.

Databases provide structure through schemas and store the underlying data, but they do not fully capture the meaning of that data. Concepts such as “churn,” “active user,” or “revenue” are dependent on business context, internal definitions, and assumptions that vary across teams and over time.

This type information exists outside the database and is fragmented. It lives in the heads of data engineers and analysts, in documentation that is often incomplete or outdated, in application code where business logic is embedded in calculations, and sometimes in internal catalogs that themselves require maintenance.

For human teams, this fragmentation is manageable through shared context and communication. For AI systems to be effective with operational data, this fragmented knowledge needs to be understood and codified. A semantic layer becomes the way these definitions, assumptions, and business meanings are made explicit and usable.

That is why it is such a hot topic of discussion in the current zeitgeist. Model intelligence and reasoning are no longer the bottleneck; getting the right information accurately to the agent is.

Implications for the Next 10 Years

As AI gets fully embraced into enterprise workflows, the importance of agents understanding and operating on the right information will become critical. In fact, it is one of the key gaps holding operational agents back today.

Data has always been and will continue to be distributed across systems—databases, APIs, and services. Schemas will remain necessary, but insufficient on their own to convey meaning. Correctness will depend not just on executing queries accurately, but on selecting the appropriate sources and interpreting them within context.

At the same time, interfaces to data systems will need to accommodate both human users and programmatic agents, which places different demands on abstraction, clarity, and efficiency. So data system APIs will need to evolve to accommodate this shift.

A Practical Perspective

The evolution of databases over the past decade reflects a consistent pattern – systems adapt to the constraints imposed on them, whether those constraints are scale, cost, or operational complexity.

The next decade introduces a different set of constraints—how systems are constructed, how they are interacted with, and how meaning is conveyed across increasingly complex environments.

Understanding how data systems are structured, what assumptions they make, and where their boundaries lie is essential to working with them effectively, especially when AI is ultimately managing the interactions and workflows.

Why Fundamentals Still Matter

One of the biggest misconceptions that I see today in the age of AI is that systems knowledge and engineering fundamentals are becoming less important.

The opposite is true.

Agents will increasingly write code. They will build systems. They will interact with infrastructure. But they will do what you ask them to do.

This means it is extremely important that those guiding the AI to build complex software systems:

• Understand systems deeply

• Make the right architectural decisions

• Orient the agent toward correct outcomes

Even as systems evolve, query planning continues to influence performance, indexing strategies shape access patterns, and operational tasks such as index backfills become more complex in distributed environments. Databases remain on the critical path of application performance, where small inefficiencies can have outsized effects.

Understanding these systems is not simply a matter of familiarity with tools, but of understanding the tradeoffs embedded in their design.

The more clearly we understand the fundamentals of the underlying software infrastructure, the better positioned we are to navigate what comes next.

Thanks to Prof. Ed Solovey for inviting me and to the students for their great questions and interactions!

Subscribe to our blog to follow our journey as we share our learnings!

I was recently reminded of that on a flight from SF to the east coast.

Sitting next to me in the middle seat was someone that seemed to be a college student. I couldn't help but notice that he was having a deep conversation with ChatGPT on his laptop, perched on the tray table. At a glance, the conversation was about revenue, scaling marketing activities etc. I assumed that he was doing a project for a business class or something like that. But I couldn't help my curiosity, so I actually asked him what he was doing.

Turns out, he was not a student at all!

He had in fact started a power-washing business right out of high school. He had bought a handful of power-washers, recruited high-school students who were looking for supplemental jobs and had built a growing, profitable business. ALL USING AI!!!

He had used ChatGPT to come up with and refine his business plan, OpenClaw agents to run his entire recruitment, marketing and ads campaign, on all the social platforms, and ChatGPT to again help him refine the next steps for sales and revenue generation. That is how he was running and growing his business.

His plan was to convert what he had built into a software solution he could sell to other similar businesses. It was incredible to watch his excitement about the whole thing!

Here's the part that was the most interesting — He had never learned to code, and he admitted that using the coding agents was his biggest challenge. BUT he taught himself, again using AI.

He had unlocked a whole new life for himself with the help of AI and his willingness to learn, adapt and try new things!

This reminded me of when I first witnessed the mobile phone revolution in India. It democratized access to better markets, better wages, better outcomes for so many millions of people!

Here's the thing — any technology, from nuclear to cell phones to AI, can be used for good or harm. But in such chaotic times, it is good to remind ourselves of that, so we can ground our freak-outs and realize that new tech that democratizes access to knowledge can also uplift those that are eager, flexible and willing to learn!

I hold out hope for ourselves and our kids. Maybe I am naive :)

(Image courtesy ChatGPT. BTW, I didn’t tell it anyone’s gender ;-) #IYKYK)

Subscribe to our blog to follow our journey as we share our learnings.

We’re excited to announce the launch of Snow Leopard’s Playground APIs — a fast, simple way to build AI agents that use structured enterprise data with high accuracy and reliability, right out of the box.

We recently introduced the Snow Leopard Self-Service Playground, where you can upload a SQLite database and try Snowy (our simple conversational BI chatbot) directly with your data. That release focused on exploration — giving you a hands-on feel for how Snow Leopard retrieves structured data accurately and deterministically.

Today’s API release takes the next step.

With the new Playground APIs, you can now integrate Snow Leopard directly into your agents and workflows using your own dataset, without any of the setup or iteration cycles that typically slow teams down.

Operational Data Shouldn’t Be the Hardest Part of Building AI Agents

Nearly every developer trying to build AI agents hits the same bottlenecks:

• Connecting to databases is painful — each data source requires its own MCP server, custom setup, and brittle tool-calling logic.

• Accuracy is unpredictable — LLM-based Text2SQL requires weeks of schema prompting and context engineering just to get to acceptable accuracy.

• Pipelines add more complexity — ETL, data dumps, and RAG snapshots all introduce staleness and drift.

• Scaling across multiple data sources compounds the problem — each integration becomes its own multi-week project, exponentially increasing complexity.

These issues mean that most AI agent projects rarely graduate from POCs. The core data plumbing and accuracy tuning end up consuming the schedule long before any useful agent logic can be built.

Snow Leopard is designed to remove that entire class of complexity and “busy work”.

What Becomes Possible When Data Isn’t the Blocker

With Snow Leopard handling structured data retrieval under the hood, AI agent builders get:

• High accuracy out of the box — our semantic intelligence engine handles even complex schemas and inconsistent internal naming.

• Deterministic data access — Snow Leopard says “no” clearly when data doesn’t exist, instead of hallucinating.

• Real-time access to source-of-truth systems — no pipelines, no caching, no data drift.

• Zero schema prompting or tool-call orchestration — Snow Leopard does the heavy lifting for you.

And now, with the Playground APIs, you can plug Snow Leopard into your own agents instantly and experience a better way to build agents firsthand!

How It Works

1. Upload your dataset to the Snow Leopard Playground
   See FAQ for details. (Today we support SQLite; more formats coming soon.)

2. Snow Leopard automatically constructs a semantic understanding of your data, capturing relationships, business logic, and internal conventions, without any manual configuration.

3. Use the Playground API endpoints in your agent – use live data for agentic decisions or ask real-time questions over your dataset, with Snow Leopard generating accurate SQL and retrieving live results. See our API docs for more details.

That’s it.

• No MCP server to set up and tune.

• No context engineering cycles or schema prompting.

• No ETL pipelines or data dumps.
  

You go from zero to live, reliable data for your agent in minutes, not days or weeks.

Why We Built This

AI developers should be able to spend their time building agent logic, not wrestling with connectors, schemas, or LLM tooling fragility.

Snow Leopard’s mission is simple: to make enterprise operational data as easy to use as unstructured text, so developers can ship meaningful agents to production faster.

The Playground APIs let you experience this directly. Teams get a lightweight, low-friction way to prototype real agent workflows using Snow Leopard before moving to full production deployments.

Try the APIs Today!

If you’ve been blocked by accuracy issues, unreliable Text2SQL, schema complexity, or endless setup cycles — give the Playground APIs a try and see what becomes possible when structured data just works.

Upload your dataset, connect your agent, and start building agents backed by live, accurate, operational data.

See our API docs for more details. Start for free today!

If you’d like to go deeper or bring Snow Leopard into your production stack, we’d love to talk: hello@snowleopard.ai

Subscribe to our blog to follow our journey as we share our learnings.

Today, we are launching a self-service playground with Snowy (alpha) – a simple chatbot interface on top of Snow Leopard, so you can experience Snow Leopard’s 90%+ response accuracy right out of the box.

Upload a SQLite file and start chatting with your data within minutes! No need to set up MCP servers, go through lengthy configuration cycles, or spend weeks tuning LLM prompts and context engineering for Text2SQL accuracy. Just connect your data and go!

Zero to ad-hoc data exploration in minutes!

The Challenge: Making Structured Data Work for AI

Building useful AI agents that rely on structured data remains one of the most challenging problems in enterprise AI.

Today, the majority of the effort goes into configuring appropriate connectors and adding business context so LLM-based agents can use structured data effectively, rather than building the actual agent logic.

To integrate even one internal database, you typically have to:

• Build or customize an MCP server for that data source

• Use an LLM for Text-to-SQL, knowing it’ll get confused by complex schemas or internal naming

• Encode business logic manually and iterate on context engineering for weeks just to get to “acceptable” accuracy of fetched data

A lot of the iteration stems from LLMs themselves being notoriously unreliable with structured data [1, 2, 3, 4]. They hallucinate and misrepresent schemas, fail to grasp internal business semantics, and produce inconsistent results. Achieving acceptable accuracy and performance of agents often takes weeks or even months.

And that’s for one data source! Multiply that by every data source you need, and every new agent you need to build — complexity explodes.

We are building Snow Leopard to solve these challenges, and with this playground you can see its early capabilities in action!

What If You Could Just—Connect and Go?

Imagine skipping all those iterations. Now you can!

Snowy shows you firsthand how quickly and easily Snow Leopard works behind the scenes with your own operational data to get accurate, real-time answers with no complex manual setup.

That means with Snow Leopard APIs (coming soon!), you can spend your time building agents that are actually useful instead of spending months iterating just so the agents can get the right data to be ready for production workflows.

How Snow Leopard Does It

At the core of Snow Leopard is its semantic business intelligence engine. This automatically constructs a semantic understanding of each data source, which can also be customized to capture unique business logic and internal “tribal knowledge” about the data.

At query time, Snow Leopard applies this semantic understanding to accurately retrieve data directly from systems of record. The result is high-fidelity, contextually grounded answers, without weeks of manual iteration or fine-tuning.

Whether deployed in the cloud or on-premises, Snow Leopard enables you to integrate AI Agents with your existing data infrastructure seamlessly.

Let’s See Snowy in Action

Let’s look at a common scenario to illustrate how Snowy can help you get ad hoc data insights quickly.

Suppose you have a dashboard showing aggregate quarterly revenue for all products. But now, you want to dig deeper and know revenue per region for a specific product — perhaps to adjust next month’s targets or allocate marketing resources.

Traditionally, this requires submitting a data request ticket and waiting days or weeks for a report. By the time it arrives, the data may already be outdated.

With Snowy, you can upload a SQLite file of your dataset, ask Snowy directly about that information, and get immediate answers. So you have the power to make quick decisions based on live information — no waiting, no tickets, no manual reporting.

By simplifying operational data workflows with Snow Leopard (which powers Snowy), teams can focus on building reliable AI agents that deliver measurable business impact, with a faster path to production from POCs.

Try Snowy for Free with Your Data Today!

Experience Snow Leopard firsthand through our self-service playground and see how easily Snowy helps you uncover insights with unmatched accuracy.

See our FAQ for details, and start for free today!

AI agent builders, stay tuned! A self-service API version that allows you to try Snow Leopard directly with your AI agents and workflows is coming soon! Sign up for the waitlist!

Contact us: hello@snowleopard.ai

Subscribe to our blog to follow our journey as we share our learnings.

So many AI demos out there stop short of the real challenge: using structured operational data reliably, securely, and in real time in agentic applications and workflows. With our Discord server, you’ll see firsthand how Snowy (Snow Leopard’s Discord Agent) addresses these issues.

LLMs and Structured Data Don’t Mix (Well)

LLMs are great for unstructured text — summarizing documents, answering questions, chatting with PDFs, etc. But, as I shared in an earlier post, they are notoriously bad at working with structured data [eg: 1, 2].

And yet, the crown jewels of a business — customer data, product insights, inventory, financials — live in these structured data systems like SQL databases, data warehouses, and APIs (Salesforce, HubSpot, Stripe, etc).

Today, developers building AI agents that need this data have to deal with:

• Accuracy – Decision-making workflows need precise, specific, accurate information. LLM hallucinations and probabilistic responses just don’t cut it, so most AI agents don’t make it to production.

• Reliability – Business-critical workflows need deterministic, consistent outputs. This includes saying no, when the information doesn’t exist or isn’t available. It is horribly complex for developers to deal with LLM-induced non-determinism when building agents that are meant to run business workflows reliably.

• Freshness – Making real-time decisions requires real-time information. Stale data (from data dumps or RAG pipelines) can lead to bad calls, missed opportunities, or compliance issues.

In addition, none of the current state-of-the-art solutions (MCP, RAG, etc.) solve the problem fully.

If you’ve ever tried to use production databases in an AI application, you know that MCP + Text2SQL just doesn’t cut it for critical workflows. Building an MCP server and hooking it up to an LLM’s tool-calling workflow is easy. The hard part is getting that setup to actually give you correct, consistent and timely answers. It requires weeks or even months of iteration just to get to 60-70% accuracy.

RAG-based solutions can’t help with accuracy and real-time data needs either. After all, they’re similar to ETL systems – stale snapshots of data that has been transformed to fit in a vectorized format, losing context and accuracy in the process.

A fundamentally different approach is required.

Why Snow Leopard Is Different

At Snow Leopard, we go beyond plumbing together connectors and MCP, and focus on building intelligence about the data itself — the relationships within and across data sources, the business context, and the rules that make the data meaningful. We call this semantic business logic.

This means Snow Leopard doesn’t just know how to query a database. It knows what data to fetch, from which database, and when.

We do this by combining:

• Decades of experience building large-scale enterprise infrastructure.

• Deep expertise in structured data and Applied AI.

• Relentless focus on simplicity and usability.

As infrastructure engineers ourselves, we believe strongly that solving hard problems isn’t enough. The solution has to reduce developer burden and be easy to use.

What This Means for Agent Builders

Snow Leopard is designed for agent builders who need to integrate structured data into decision-making workflows without drowning in complexity.

Here’s what Snow Leopard provides:

• Simple APIs – Use databases directly with your decision-making agents without worrying about brittle pipelines or complex, continuous ETL.

• Live queries – Queries are built in real-time and data is retrieved directly from the source system, meaning it's never stale.

• Governance and security – Only fetches data it has access to, and never stores / caches data. Data access is managed directly from source systems, on demand.

• Deterministic behavior – Explicitly denies requests when the data being asked for doesn’t exist or isn’t accessible. Agents can be built in a simple, reliable way instead of dealing with the complexity of non-deterministic LLM behavior.
  

Most AI agents stall at the POC stage primarily because they’re built on inconsistent and inaccurate foundations. Snow Leopard makes it feasible to build production-grade agentic software.

See It in Action on Discord

To try Snow Leopard for yourself, join our Discord server!

You’ll notice that Snowy focuses on three things:

• Consistency — deterministic, repeatable responses.

• Accuracy — says no when the data isn’t there or the question doesn’t fit.

• Freshness — data is always fetched at query time.

We believe these are key attributes for anyone building enterprise AI agents.

Note that Discord is just the interface we’re using to showcase Snow Leopard’s capabilities. Snow Leopard itself is a conversational API that specifically does the heavy lifting of on-demand structured data retrieval.

Snow Leopard gives builders the confidence to ship AI agents that make real-time, data-driven decisions.

If you’re ready to bring Snow Leopard into your business, we’d love to help you get the most out of your operational data for your AI agents!

Contact us: hello@snowleopard.ai

Subscribe to our blog to follow our journey as we share our learnings.

Subscribe now

That’s not the reality though.

While the platform shift is clearly there, LLM-powered agents still don’t get the right information at the right time from the crown jewels of your business i.e. your operational, structured data systems—warehouse, lake, ocean, whatever.

Bolting AI onto the side of your existing technology stack isn’t a long-term success strategy.

Also, RAG doesn’t cut it for these types of real-time decision-making agents. When data is transformed and offloaded into a vector store, it breaks the logic those systems were built to preserve. Structure disappears. Context dissolves. Precision is lost.

Snow Leopard solves this with real-time, deterministic access to live data, queried directly from source systems at the moment an agent needs it to make progress. That’s what makes the reasoning system accurate and reliable.

Snow Leopard founder and CEO Deepti Srivastava explains more in episode 325 of the MLOps podcast.

Here’s what Deepti and host Demetrios Brinkmann discussed:

[02:40] Connecting LLMs to operational data
To deliver on their platform-shift promise, LLMs need access to live, operational business data—structured data from SQL, NoSQL, and APIs.

[04:50] The AI/data disconnect
There’s still a massive chasm between operational data and LLM-based apps. Most agents are being built to chat with your PDF or your notion docs etc. not your databases in real-time.

[08:43] Context is key
Your tech stack operates in an ecosystem. Any new technology has to exist within that ecosystem. Bolting it on as a side-car isn’t going to get you the fundamental platform shift that everyone is talking about.

[11:00] Spicy take #1
Putting all your data in a data warehouse, lakehouse, ocean etc. doesn’t actually solve the problem. That data is stale, transformed thereby losing original context, and doesn’t help AI Agents make real-time and accurate decisions.

[11:46] Spicy take #2
Even the most intelligent machines today—human beings—don’t make the right decisions without the right information. Intelligence and enhanced reasoning on their own aren’t enough. Why would we expect AI to be different in that regard?

No AI system will make the right decisions without the right data, at the right time. Better reasoning won’t fix stale and broken inputs.

[12:30] Model hallucinations 201
Hallucinations happen when LLMs have the wrong data or too much data where they can’t figure out what to focus on. When the system can’t distinguish what matters, it guesses.

[16:00] LLM strengths and limitations
LLMs are useful for fuzzy interpretation, summarization, and classification. But they fail at precision tasks like point lookups or definitive yes/no answers.

[17:00] Data needs context
Your business’s crown jewels – data in systems like Postgres, Snowflake, Google BigQuery Salesforce, HubSpot, and other APIs–lose meaning when extracted. Stripped from context, the story gets lost.

[24:00] Shifting engineering time from clean-up to value creation
Today, data engineers spend 70–80% of their time maintaining brittle pipelines. What if you could drop a box between your operational systems and your LLMs and just draw straight lines? That’s the shift: from complexity to creative innovation.

[28:00] What if you didn’t move the data?
What if you could skip the pipelines entirely and just query data directly from the source, in real time? No movement. No duplication. Just a live connection that fetches the data when the question is asked.

[32:00] No pipeline required
Snow Leopard will pull from multiple systems and return an answer without having to build a new pipeline or engineering a custom solution to accommodate every new use case or workflow. Ad hoc retrieval for ad hoc use cases.

[36:44] Spicy take #3: MCP doesn’t solve it
MCP is amazing. It’s a great open-source start to the connector problem. But MCP isn't a magical solution. It’s not tackling the hardest part of the problem, which is intelligent routing and, more importantly, understanding the semantic context around the data.

[39:00] SQL ≠ SQL
Not all SQL is the same. Mixing queries across dialects, like MySQL and Snowflake, breaks systems and confuses LLMs. That’s one reason text-to-SQL doesn’t work in practice. Generating a SQL query in the correct dialect requires additional effort and an inherent understanding of the underlying data systems.

[46:00] Ad hoc questions need ad hoc retrieval
In a world of ad hoc questions and on-demand information needs, why shouldn’t data retrieval be ad hoc too? Using pre-defined pipelines to solve every use case just doesn’t work and won’t scale.

[54:00] The real challenge with AI: POC to production
The hard part is still getting from proof of concept to production. Teams build cool demos, but can’t deploy them because of reliability and accuracy issues. Performance isn’t even the blocker yet. It’s just about making it work consistently and correctly.

That’s what we’re focussed on at Snow Leopard–accurate consistent data for alI!

Subscribe to our blog to follow our journey as we share our learnings.

Anyone who’s tried to get reliable answers from operational data in AI systems knows the pain—data is often stale or inaccurate, and building and maintaining data pipelines is a constant uphill battle.

In a previous post, I laid out what's missing today: a reliable way to get AI systems to query structured data accurately and consistently. We’ve found that the biggest gap is the semantic layer—the business logic required to understand which data to query, when, and how. Without that, even the most advanced models struggle to answer even moderately complex questions.

This semantic understanding is usually locked in the minds of the people who originally built the pipelines and structured the databases. Extracting that knowledge is tough. Using it in real time for AI-driven data access is even tougher.

That’s why at Snow Leopard, we’re building a system to extract, encode, and use this semantic knowledge for real-time, intelligent data retrieval.

We know our solution is promising. Given the rapid evolution of reasoning models, we wanted to benchmark our system vs. today’s state-of-the-art data retrieval tooling to get a current baseline.

Evaluation setup

We ran two core experiments: one with a synthetic Postgres database and one with a real-world dataset in BigQuery.

Our goal for these experiments was to establish a baseline of how Snow Leopard measures up with respect to accuracy and consistency, without compromising data privacy. The latter isn’t as straightforward with LLM-based retrieval agents as you might imagine. More on that later.

This post walks through our benchmarking process, our learnings, and what we think the findings mean for the future of enterprise data + AI.

Current state of the art: Intelligent LLMs +MCP

We used the Model Context Protocol (MCP) in combination with reasoning LLMs as our “state of the art” baseline. This has become a common setup in the developer community, especially for querying relational databases with natural language.

Setup 1: Synthetic Postgres database

We created a simple Shopify-style Postgres database with a manually-built schema. Data was initially generated using an AI-based data-generation tool, then refined manually to better reflect a realistic dataset. The aim here was to have a basic dataset as a baseline for our experiments.

• Tables: 4

• Dataset size: 128KB

We compared three configurations:

1. Snow Leopard (schema-only, single-shot, privacy-preserving)

   1. Snow Leopard uses schema-only with a single-shot query to an LLM to generate queries in real-time for retrieval.

   2. It doesn’t explore the data ever, making it a data-privacy-preserving solution.

2. MCP + Claude (full tool calling enabled)

   1. We used the Claude API with Sonnet 3.7 (Anthropic’s latest reasoning model at the time) with an open-source Postgres MCP Server we found here.

   2. For this experiment setup, full tool calling was enabled, which means Claude could explore the data as it saw fit to generate each SQL query.

3. MCP + Claude (schema-only, single-shot)

   1. Same setup as above–Sonnet 3.7 with open-source Postgres MCP Server

   2. For this variation, full tool calling was disabled, so Claude had to generate the SQL query in a single shot based on the schema it had access to through the MCP server.

Setup 2: Real-world BigQuery dataset

For the second set of experiments, we worked with a real dataset from one of our design partners (in the Fintech-SaaS space). This was a production BigQuery dataset, with rich, messy real-world semantics and a more complex schema.

• Tables: 50K+

• Dataset size: 80GB+

Again, we compared three configurations:

1. Snow Leopard (schema-only, single-shot, privacy-preserving)

   1. Same as above.

2. MCP + OpenAI 4o (tool-calling enabled)

   1. NOTE: For this experiment variation with full tool calling was enabled, we used OpenAI’s 4o-mini model because our partner required an OpenAI-based solution for data privacy reasons.

3. MCP + Claude (schema-only, single-shot)

   1. Same as above.

Evaluation methodology

• Primary metric: Accuracy, measured as correct answers to a fixed set of questions.

• Scoring: All questions were manually graded to create a "golden dataset" for each case.

• Modes tested:

  • Tool-calling enabled (multi-shot, with data exploration)

  • Tool-calling disabled (single-shot SQL generation using only schema)

This last distinction was especially important to us.

At Snow Leopard, we care deeply about data privacy.

With decades of experience building enterprise-grade databases and data storage solutions, our team understands the critical importance of handling operational enterprise data with care, and respecting data governance and privacy requirements.

Snow Leopard is built from the ground up to generate queries in a single shot without ever exposing the data directly to an LLM. Snow Leopard is simply a pass-through for an AI agent or AI application, generating SQL queries based on schema-alone for real-time data retrieval.

So if we were going to compare Snow Leopard with existing setups fairly, we had to test both tool-calling (multi-shot) and schema-only (single-shot) approaches.

Aside: Building our own BigQuery MCP server

When we started this experimentation cycle, after much searching we found, to our surprise, that there was no official BigQuery MCP server from Google.

The community implementations we found seemed experimental and buggy (we contributed patches upstream to one of them). Schema calls were made via tool endpoint calls, not resource endpoint calls. In addition, there was no way to restrict query calling in a way that respected our privacy model.

So we built our own BigQuery MCP server. You can find the repo here.

Results

Postgres dataset – 29 questions

BigQuery dataset – 39 questions

What we learned

Setting up MCP with Claude or OpenAI was relatively easy. Building a clean MCP server that implements the spec well was also very doable.

It is notable that while there are a lot of discussions around MCP and using MCP servers to explore data sources, MCP servers are not yet ubiquitous for all data sources, especially structured ones. That means you should expect to build your own if you want to do any realistic MCP-based experimentation with your data sources.

Overall, we are enthusiastic about MCP and believe MCP’s evolution will help accelerate Snow Leopard's adoption because it will allow us to manage data retrieval and orchestrate queries without writing and maintaining separate connectors for each data source.

Considerations

Performance and token utilization

Tool-calling setups typically use a multi-shot approach, where the LLM agent explores the dataset before generating a final SQL query. This back-and-forth interaction with the data introduces two key trade-offs:

• Performance Overhead – Multi-shot workflows incur additional latency compared to single-shot query generation.

• Higher Token Consumption – Each exploratory step uses more tokens, potentially increasing cost.

These aren't necessarily deal breakers, but they’re worth keeping in mind if you're building similar systems. Multi-shot interactions may not scale efficiently.

Data privacy

The default behavior for tool-calling agents is to query the database and explore your data on every request, as mentioned above. This implies that LLM agents use MCP servers to retrieve live data from your database multiple times during a single request. So if you’re using a vendor-hosted LLM (like Claude or o3), you may be unknowingly sending your internal data to that vendor, query by query. This includes tools like Claude desktop.

While this behavior is implicit, it can become a serious concern if data privacy is critical to your organization.

For many environments this is a deal-breaker and one of the main reasons we built our own MCP Server for BigQuery; we specifically wanted to restrict tool-calling behaviors and protect our design partner’s data.

Snow Leopard was explicitly designed to never explore the data. It uses only the schema to generate queries, and you can BYO LLM for the final response—ensuring full control over what goes in and out.

Semantic understanding is the missing piece

LLMs are powerful but they don't have any inherent semantic information about a given dataset.

Most real-world operational data are filled with implicit logic, domain-specific naming conventions, and contextual rules. Out of the box, even the most intelligent models won’t know, for example, that a column named purch_dt actually refers to a purchase date in an ecommerce database.

When running the LLM+MCP setup on our design partner’s use case, we saw this clearly. We had to explicitly give the LLM the exact table names for it to generate SQL queries that worked, since the business logic is embedded in the table names. Otherwise, the models got lost. When we let the LLM fetch all available tables in the dataset, it blew out the context window.

Even in this relatively small relational schema, without semantic guidance, the system simply didn’t know how to navigate the data effectively.

Our takeaways

Our experiments confirmed that:

• Semantic information makes a measurable difference in the accuracy, consistency, and quality of results. Snow Leopard’s focus on semantics leads to significantly better performance on real-world datasets.

• Even with constraints (smaller cheaper models, single-shot, schema-only), Snow Leopard is:

  • Significantly better than state-of-the-art tools for real, production-grade, complex datasets.

  • On par with state-of-the-art tools when dealing with simple databases.

This gives us confidence that we’re building in the right direction. Our bet on building a semantic layer, and designing towards intelligent understanding of the data, is the right one. And while there's more to grow, optimize, and scale—these early signals validate our core approach.

We’re focused on solving a real, hard problem that’s blocking structured data from being useful for AI, and doing it in a way that respects privacy and reliability.

If you’re building similar systems or struggling to use structured data in your AI agents and applications, we’d love to hear from you.

Subscribe to our blog to follow our journey as we share our learnings!

Simply put, for AI agents to be part of critical / user-facing workflows, they need real-time access to the “crown jewels” of a business – structured operational business data. In most enterprises, this data is locked away in data silos, and often stuck behind brittle pipelines, stale snapshots, or vector stores that strip away business logic.

On Episode 099 of The Great Things with Great Tech podcast, Snow Leopard founder and CEO Deepti Srivastava sits down with Anthony Spiteri to unpack what AI agents really need in order to move beyond POCs—and how Snow Leopard enables them to do just that through live data retrieval, natively from any source.

Here’s a tactical summary of the discussion:

[15:30] The spark behind Snow Leopard
Even as companies race to prototype AI tools, few can deploy them in production. One of the big challenges is access to the right information at the right time to make the right decisions. Snow Leopard was built to solve this, making it possible for AI agents to have real-time access to structured, operational data.

[20:59] Why AI agents must live in the critical path
To drive business outcomes, AI agents need to be incorporated into critical business workflows, not sitting to the side or bolted on after-the-fact. This integration requires trustworthy infrastructure that connects them to systems of record.

[22:32] The hard part isn’t access…it’s relevance
Pulling data from a pre-defined lake or warehouse that aggregates information is hard but achievable. However, pulling the right data, that reflects current reality and isn’t stale, is a huge challenge. Snow Leopard dynamically fetches live data natively, by constructing native queries to get exactly what’s needed when it’s needed.

[27:11] Three truths Snow Leopard is built on

1. Data silos are a fact of life.

2. AI agents need access to live operational business data to be able to handle critical workflows.

3. Data consolidation in data-lakes with pre-defined pipelines isn’t the right solution.

[31:50] The limits of vector search
Vector databases are useful for semantic search, but are notoriously inaccurate for structured data and precise lookups. Snow Leopard is building intelligence around the data itself. It preserves precision by querying data sources directly and natively.

[34:34] How Snow Leopard works
Snow Leopard performs real-time, federated queries across operational systems—no ETL, no duplication. It builds native SQL or API calls at query time, tailored to each data source.

[36:20] The platform
Snow Leopard uses deterministic programming to generate native queries on the fly. Snow Leopard handles the logic, securely and at scale.

[37:50] Built for enterprise reality
Snow Leopard adapts to every customer’s real-world stack without requiring centralized warehouses or re-platforming.

[39:00] What’s ahead
Our team at Snow Leopard is only getting started. The goal: to power the next generation of AI-native enterprise apps by making business data instantly accessible, accurate, and actionable for LLM-powered agents.

Subscribe to our blog to follow our journey as we share our learnings.

To be fair, it’s a great way to give LLMs the context they need to generate more tailored responses, especially when the data is unstructured, such as text, images, videos, etc. Organizations today have RAG pipelines in place to make their mostly-static data work with LLMs. However, practically speaking, when it comes to correctness, accuracy and freshness of data, RAG just doesn’t cut it for most operational business use cases.

The limitations of RAG

RAG uses a vector store to aggregate, summarize and tokenize the data used to provide the context for LLM prompts. Vector stores use fuzzy matching (i.e. nearest neighbor searches) to retrieve the needed data, which works well for unstructured data. However, vector stores were never designed to do point lookups or exact data retrieval, which means data accuracy will always be questionable.

Even when the combination of RAG and LLM meets the bare minimum for production, the configuration won’t be useful for business-critical workflows. For example, if you need to check for criminal records on “Joanna Smith” during your hiring process, the system might confuse “Joanna Smith” with “Joan Smith” yielding a false result.

Also, because data is extracted from its original source, transformed and aggregated through data pipeline(s) into the vector store, it is, by definition, stale. This lack of freshness makes using RAG for real-time decision making use cases a challenge. As a result, the RAG approach becomes useless for many business-critical workflows.

A simple customer support example

Let’s talk through these challenges through a simple example. A customer makes an online purchase, but the system glitches and doesn’t provide an order number, leaving the customer wondering whether the order was received and what its status is. A customer support chatbot (which is almost always the first line of support offered by ecommerce sites) using RAG for data retrieval won’t have immediate information about the order status — the event just happened, and the order number wasn’t ETL’d into the vector store yet. So from the chatbot’s perspective, the order number is unknown. In this case, AI fails to help, and the client is transferred to a human support agent. The human checks the order management system and provides the order status. In this case, the data existed but could not be effectively accessed by the automation. So a human needed to be involved, wasting their precious time and delaying the customer’s resolution.

If the AI agent was directly connected to operational data sources, it could fetch the right data from the right sources — whether a database, data warehouse, or API — and use to help the customer in real-time. Current data pipelines and consolidation-based systems are just not suited for these types of ad hoc use cases.

Its time for a new data infrastructure, tailored to GenAI

For AI to move forward, it must integrate seamlessly with business-critical systems. That means:

• Directly and natively querying databases, data warehouses, and API-based systems in real time.

• Eliminating reliance on pre-defined, brittle and rigid ETL workflows for AI-driven decision-making.

This is how data infrastructure for AI should be. This is what we are building at Snow Leopard.

I’ve seen the limitations of data consolidation approaches first hand from building cloud and data infrastructure for decades. Hence, at Snow Leopard, we believe in an intelligent, federated approach to data instead.

We are making it simpler and easier for AI developers to use their operational business data for AI applications in production and on-demand, without the need for complex data workflows and pipelines.

Subscribe to our blog to follow our journey as we share our learnings!

GenAI, LLM-based AI agents and AI assistants, are starting to have a real and huge impact on how people live and work. Companies of all sizes and in all verticals are frantically trying to build and leverage AI into their user and business workflows.

RAG-based workflows have now become de-facto for AI applications. Chatting with your PDFs and unstructured data is great, and to be fair, has unlocked huge swaths of previously impenetrable knowledge bases. However, I believe strongly that without incorporating the crown jewels of the business i.e. structured operational data (databases, data warehouses, and API-based systems), the true potential of AI can’t be unlocked.

So why is it so hard to build real-world AI agents and applications incorporating structured data? After all, there is Text2SQL, MCP is quickly becoming the way to connect to various data sources, and LLMs are getting smarter with more reasoning almost every day!

Here’s the issue: some of the above techniques work well in demos and POCs. But as soon as you try to convert that POC into a production app, things fall apart fairly quickly. None of these methods work with the complexities of real operational data – often spread across multiple systems, evolving schemas, and inconsistent naming – accurately and repeatedly, and definitely not at scale.

Data Lakes won’t fix the problem

Data silos are a fact of life.

Every business, whether it’s an SMB or a large enterprise, has a unique tech stack that exists within the context of the business. Some parts of the company may use Postgres, others may use MySQL or Oracle or Snowflake, and yet others may use Salesforce, Stripe, and Hubspot, to meet the needs of that particular team or business unit.

The “ideal world” consolidation approach – that all data can always be in one place and queried easily from there – is appealing but just isn’t practical or feasible in a lot of cases. I know firsthand from my experience working directly with countless Google Spanner and GCP customers that no matter how well designed and carefully architected your data-lake or data-warehousing solution is, there’s always a data source that exists somewhere in the organization that isn’t included in the lake or warehouse.

In addition, even if the data is orchestrated through complex pipelines to be in the lake eventually, that data is stale. So it can’t be used for real-time decision-making use cases. It has to be fetched on-demand. This means you have to maintain multiple different workflows and pipelines to ETL data and also retrieve data from the same source for different use cases … what a waste of precious time, engineering resources and energy!

Smarter LLMs aren’t the holy grail either

Will the accuracy and complexity issues of structured data retrieval be solved by better reasoning models and smarter LLMs? My answer is no!

Even the best reasoning machines today — humans — don't always make the right decisions, especially when they don't have the right information. In fact, we tend to make up stories to fill in gaps in our own knowledge. We’ve built many systems-of-record over time to help us with precise look of exact data as and when needed, including databases, spreadsheets, other structured and tabular formats etc.

Switching back to machines designed to think like humans, research conducted by Transluce found that as reasoning models become "cleverer", they also tend to be less reliable because they fabricate information, sometimes quite elaborately, to fill in their own knowledge gaps. This means, reasoning models are more likely to lead to inaccurate and misleading information. That’s not something we want to rely on for specific data to make critical decisions.

What’s considered state of the art today?

Let’s shift gears and talk about solutions that are currently available to AI builders and AI developers. They work… until they don’t!

There’s Text2SQL. But it doesn’t work without spoon-fed context. And when given the usually large schemas in the context, LLMs tend to get overwhelmed or confused, and are prone to hallucination when they don't know the exact SQL dialect or the exact data object name, etc. Instead, they make guesses. They make up table names and column names. Maybe Text2SQL works in a demo. But it breaks in production for even moderately complex data or queries [1, 2, 3].

So what about using RAG to retrieve schema details? It’s somewhat more scalable but still widely unreliable… and again, it leads to more hallucinations. RAG is notoriously bad at exact matches and precise lookups, which is exactly what structured data retrieval needs.

LLM fine-tuning can work, especially when used with good prompting techniques to increase the consistency of outputs. But how much is your dataset likely to evolve? In the real world, schemas continuously change, and so do data sets. It’s not practical to re-train every time a schema change happens. And you definitely can’t train on every internal data system your business uses. It's never-ending upkeep and maintenance, which just isn’t possible.

Then there’s MCP. It’s a great open source start to the “connector” problem, providing a consistent and standard way to do tool calling for LLMs. But MCP is just the plumbing. To actually use it well, you still need a smart agent that understands the business context inside and out: how the data is structured, where it lives, and what queries actually make sense. The hard stuff still isn’t easily repeatable or automated. A *lot* of the heavy lifting is left to the “agent(s)” i.e. ultimately to the AI app developer to figure it out.

Why Snow Leopard is different

At Snow Leopard, we’re building an intelligent data retrieval solution that uses a combination of techniques mentioned above along with a focus on semantic intelligence about the data itself. This allows us to deal with the data consistency and accuracy issues that are rampant in LLM-based agents and problematic for multiple enterprise AI use-cases.

Text2SQL agents and similar agentic workflows for structured data retrieval fail today because LLMs and AI agents are missing the business context around the data.

This means the relationships within the data source (eg: between different columns and tables) and across data sources (where objects that mean the same thing have different names and ways to address them, such as: customer_id column in Postgres is the same as client_id column in Snowflake) are completely unknown to the agent. Often, these relationships exist only in the heads of the analysts or data engineers that manage and maintain the data infrastructure of the business. But when this business logic can be extracted and fed to the agent, the results are far better and more grounded in reality.

That is the mission we’re on at Snow Leopard! We are making it simpler and easier for AI developers to use their operational business data for AI applications in production and on-demand, without having to pre-define the complex data workflows and build all the pipelines. This process, called "live retrieval," means Snow Leopard has a federation (vs. consolidation) approach, and evaluates each query in real-time, deciding on the fly where to pull data from—without pre-storing or pre-processing it.

We’re excited to be on this journey to make structured, operational data work for AI!

Here’s a breakdown of top takeaways from her builder-first perspective (originally published by EntreConnect).

5 core insights

1. The real crown jewels of any business are hidden in structured data — SQL databases, warehouses, internal APIs.

2. Building a GenAI workflow without connecting to real production data is just a toy project. Demos are easy; integrating live, messy enterprise data is the real challenge.

3. Multi-agent orchestration isn’t new — it's intelligent routing, retrieval, and transformation done at runtime. We've built these patterns long before “agents” became a buzzword.

4. Enterprise-grade AI demands reliability: consistent outputs, accuracy, and live data. Hallucinations kill trust and break critical workflows.

5. Most GenAI prototypes fail because they ignore structured data pipelines. Without getting deep into the tech stack (not just chatting with PDFs), GenAI stays stuck in POC land.

Operator real-talk

• Data access is the hardest bottleneck. It's not about model quality — it’s about whether your system can securely and intelligently access the right row, column, and table, to get the right data for real-time decision making.

• Prompting tricks won’t save you. If your structured queries aren’t reliable, no LLM magic will fix bad retrieval or broken joins.

• Adoption isn’t blocked by excitement — it’s blocked by system integration risks. Enterprises aren’t scared of GenAI; they’re scared of breaking the workflows that actually pay the bills.

• Retention matters more than initial, first-use adoption. Quick demos impress, but lasting value only comes when users trust the AI layer as much as they trust Salesforce or ServiceNow.

Key quotes

“Last year, everyone adopted something. But what’s the churn curve?”

"Productivity gains are table stakes. True enterprise AI unlocks new value — and that starts by wiring into your real structured systems."

"If you can't wire into the heartbeat of the business — the structured systems — GenAI will stay a sideshow."

“After every platform shift, it’s the new ideas—not the old winners—that dominate.”

Read more via the EntreConnect newsletter.

Subscribe to the Snow Leopard blog to follow our journey as we share our learnings.

On Episode 031 of Generationship, Snow Leopard founder and CEO Deepti Srivastava sits down with host Rachel Chalmers to discuss what’s missing—and how to bridge the gap.

Here’s what Deepti and Rachel discussed:

[02:20] Enterprise data realities
Every enterprise has a unique stack shaped by time, org structure, and tooling—making centralized, one-size-fits-all data solutions unworkable in practice.

[08:30] What Snow Leopard enables
Snow Leopard connects LLMs to live operational systems (e.g. Postgres, Salesforce, Stripe) via native queries, enabling accurate, real-time answers without data duplication or delay.

[10:23] The catalyst for Snow Leopard’s creation
Deepti shares an experience interacting with a customer support chatbot that couldn’t access her order status, forcing a 45-minute support call for a simple confirmation. This broken support workflow underscored the cost of disconnected systems and the need for on-demand data retrieval.

[14:19] The transition from PM to founder
Deepti shares how being a solo founder demands unwavering conviction, especially in early-stage ambiguity, and why product focus depends on saying no to distractions. She speaks to the importance of staying grounded in customers’ pain points.

[21:10] What’s next for enterprise AI
The three vectors that Deepti is watching closely: Language models for non-English languages, unstructured-to-structured transformation, and agentic reasoning over graph data.

[26:06] Critical thinking is the missing interface
From misinformation to youth mental health risks, Deepti argues that AI’s greatest societal threats require not just technical guardrails, but renewed emphasis on critical thinking.

[34:00] Making AI useful means making data usable
Deepti lays out a vision for generative AI as ambient, decision-support infrastructure—and why getting there requires systems like Snow Leopard that deliver timely, trustworthy data on demand.

Follow our journey by signing up for early access and connecting with Deepti on LinkedIn.

Instead of unlocking data, most AI initiatives recreate old problems: brittle pipelines, static snapshots, and expensive ETL jobs that are difficult to scale and harder to govern.

Snow Leopard founder and CEO Deepti Srivastava discusses this challenge—and her view for how to solve the problem definitively—on Episode 20 (Season 1) of Straight Data Talk:

• Respect system diversity

• Eliminate unnecessary complexity

• Fetch live operational data, on-demand and in real-time

Drawing on two decades building distributed data systems, Deepti unpacks how Snow Leopard bridges the gap between AI and live, trustworthy business data without forcing enterprises to rewire their entire stacks. Discussion summary:

[01:50] Enterprise AI is an infrastructure problem, not just a model problem
AI systems are failing to deliver business value. It’s not because the models aren't good enough—it’s because the underlying architecture wasn’t designed for dynamic, real-time access to operational systems.

[07:30] Data silos are a fact of life—not a bug to eliminate
Centralized warehouses are important, but not sufficient. Operational data will always live across fragmented systems, and expecting complete centralization creates more friction than flexibility.

[15:25] Pipelines recreate the same complexity AI was supposed to fix
Most RAG pipelines simply replicate traditional ETL problems—introducing latency, brittleness, and missing context into AI systems that need up-to-date and semantic information to move forward.

[22:40] Snow Leopard’s query-first architecture for GenAI
Snow Leopard eliminates unnecessary data movement by building real-time queries natively using intelligent routing and query generation at runtime.

[29:18] Usability and governance must be solved together
Rather than centralizing everything and losing data lineage and fine-grained controls, Snow Leopard’s architecture is built to enforce access, permissions, and auditability directly at the data source—preserving security and governance without stifling AI agility.

[38:02] Reducing unnecessary complexity unlocks developer focus
Simplifying the AI-data integration layer frees teams to focus on building high-value, differentiated products—not endlessly maintaining brittle glue code.

Be sure to sign up for early access to Snow Leopard.

On Episode 261 of The Data Exchange and in a recent edition of the Gradient Flow newsletter, Snow Leopard founder and CEO Deepti Srivastava joins Ben Lorica to unpack this growing problem and share why live, structured data is essential for next-gen AI—and the approach that Snow Leopard is taking to solve the problem.

Here’s what the discussion covered:

[01:07] Connecting AI to business value
Without real-time access to sources like CRM, finance, and product systems, LLMs are disconnected from the workflows they’re meant to support.

[04:29] From Spanner to Snow Leopard
Centralized architectures and batch-based pipelines create brittle systems. Drawing on her experience building Spanner at Google, Deepti explains why live access—rather than ETL—is the only scalable way to support production-grade AI systems.

[08:07] The limits of RAG
RAG systems degrade under real-world use. Once data is embedded, it’s already stale. Structured data gets flattened, freshness is lost, and fuzzy matching introduces critical inaccuracies, particularly in high-trust domains like finance and operations.

[15:02] What Snow Leopard does differently
Snow Leopard eliminates pipelines entirely. It sits between your agents and data systems, performs intelligent query parsing and routing, and retrieves only the precise rows and fields needed—on demand, from the original source.

[25:07] Why building it yourself doesn’t scale
Deepti explains why teams quickly hit a wall trying to DIY what Snow Leopard handles by design.

Check out what we’re building and sign up for early access @ snowleopard.ai.

In this talk at The 2024 AI Conference, Snow Leopard founder and CEO Deepti Srivastava shares why enterprise data complexity, not model reasoning, is the real barrier to effective AI. Drawing on her experience as the lead PM for Google Spanner, she introduces Snow Leopard’s approach: retrieving the right business data at query time, directly from source systems, without preloading or transformation. The result is a simpler, more scalable foundation for building agents and assistants that can actually deliver answers that matter.

[02:17] Root cause: missing joins across systems at runtime
A customer support workflow fails not because data is missing, but because existing systems aren’t set up to do ad-hoc, multi-source data fetches and joins in real time. Siloed data and fixed APIs force human-in-the-loop workflows unnecessarily where automation could improve efficiency, productivity, and customer experience.

[05:27] AI agents fail when business logic is baked into ETL
Most current systems encode logic into pipelines—meaning any shift in schema, source, or decision flow requires reengineering. This tightly couples business logic to data movement.

[07:13] RAG turns structured data into lossy approximations
Deepti critiques RAG-based retrieval for structured data: embeddings flatten semantics, introduce fuzzy matching, and discard schema integrity, making it unusable for high-trust or transactional use cases.

[09:02] Why agentic frameworks don’t generalize
Even sophisticated function-calling agents depend on predefined APIs and context windows. They don't handle ad hoc retrieval across changing schemas or evolving enterprise systems without heavy orchestration.

[14:00] Snow Leopard’s design: building intelligence about the data rather than into the data pipelines
Snow Leopard queries each data source —OLTP databases, data warehouses, API based systems, vector stores —natively at runtime, without the need for ETL, pre-defined pipelines, data pre-loading or transformations. The system routes intelligently at runtime and builds the exact query needed to fetch data from a specific data source.

[16:09] Benefits: increased query precision, reduced system coupling
Querying in place preserves data fidelity, reduces latency, and eliminates the need to model or pre-define every possible user query path. It also reduces maintenance cost.

[17:02] Unlocking applications that require dynamic joins
From support and inventory to account intelligence, Snow Leopard enables AI agents to execute cross-system queries without brittle connectors or upfront orchestration—bringing new categories of enterprise questions into scope.

Sign up for early access to Snow Leopard: www.snowleopard.ai

It’s about productization, usability, and adoption.

At the 2024 Systems Distributed Conference, Snow Leopard founder and CEO Deepti Srivastava shared her best lessons from working on Oracle RAC and leading product for Google Spanner.

Here’s what she shared:

[4:16] Ease of use is what drives adoption
Systems don’t succeed based on technical merit alone. No matter their elegance or power, if software is too hard to use, people won’t adopt it. Case in point: the biggest technology shifts (GUI, cloud, chat, interfaces) were all usability breakthroughs.

[13:12] Migration, not competition, is the real blocker
Better data systems often lose not because of missing features but because data migration is too hard. Even within Google, it took dedicated teams to support the switch to Spanner. Outside of Google, the friction was even higher—early customers walked away simply because switching costs were too high. Paths that minimize switching effort, supporting side-by-side adoption, are key.

[20:49] Building for customers is different than building internally
An internal tool with 100% uptime, tight dependencies, and shared assumptions doesn’t survive with external customers. Defaults break. Error modes compound. And support burdens increase exponentially.

[31:35] Pricing is downstream of system design
Efficient architecture is necessary for competitive pricing. At Spanner, internal architecture needed an overhaul for competitive pricing. That takes years of engineering work focused on utilization and cost reduction.

[36:24] The systems that matter are the ones people can build on
Impact comes from enablement. The best systems are ones that empower others to solve problems. That principle underpins Snow Leopard’s current trajectory: designing platforms that remove friction, reduce glue code, and let developers focus on what matters.

Check out what we’re building at Snow Leopard, and sign up for early access.