The Gap in the AI-Native Data Stack
When people talk about applying LLMs to the modern data stack, they usually focus on the analytics layer.
That makes sense. The analytics layer is the part most people are familiar with, where tools like Power BI, Tableau, and Looker live. These tools sit on top of data that’s been cleaned and modeled by a data team, so nontechnical users like customer success managers, product teams, sales, and marketing analysts can find insights from their data.
Given advancements in foundational models, the analytics layer is the lowest-hanging fruit of AI transformation. It’s relatively trivial to get a foundational model to take clean table headers from a CSV or a warehouse and generate SQL, Python, or R that answers a simple business question. This does however, assume your data is well-structured, correct, and aligned with your organization’s definitions of things like “active users” or “revenue,”. Provided that’s the case, natural language interfaces can go a long way in helping people find answers.
Several highly competent products have been built around this idea. They let users upload data and ask questions in plain English. A model generates a SQL query or Python code and spits out an answer. These tools are fairly popular for good reason. They’ve captured the lowest-hanging fruit of AI data transformation, but I fear their position is fragile. It’s easy to imagine OpenAI or another major provider adding upload-and-analyze features directly, just as they added search to regular prompting. This raises questions on the longevity of specialized tools like Perplexity, built around search.
Meanwhile, the analytics has been a crowded space for years. Legacy vendors like Tableau and Power BI have deep roots in the enterprise and have already locked in most large customers. With the rapid proliferation of text-to-SQL tools, one can make the argument that there isn’t much left to innovate on in this layer.
The Opportunity Under the Analytics Layer
That’s where the real problem lives: how do you create clean, trustworthy, and well-defined data in the first place? This is the hard part every data team deals with. It’s not just technical. The data has to be structured in a way that makes sense to people across the company who don’t live in the data. Most business users don’t have the time or context to interpret things like schema design, column logic, or how data was joined.
To make things manageable, data teams usually lock down the surface area. They present just a handful of metrics in a very controlled way. You’ve seen this before. It’s the dashboard with one chart and one number that everyone agrees matters. Green is good. Up and to the right means growth.
But as soon as someone wants to go beyond that, things get slower. They send an ad hoc request to the data team. The data team has to figure out what’s being asked, how to model it, and how to answer it. Even the “one chart” that goes on the dashboard can take weeks to get right. Since time is limited, there’s usually a prioritization process. Most questions never get asked, and many that are asked don’t get answered. Adding an LLM on top of your existing data doesn’t really change this. The limit isn’t the interface. It’s the number of reliable, well-defined datasets the business has access to. That’s the bottleneck.
That’s what we’re working on at Astrobee.
We’re not building an incremental improvement in a BI interface. We’re focused on helping data teams automatically build new sources of truth: datasets that are clear, consistent, and usable by everyone in the organization. This involves everything from figuring out what a business user actually means (disambiguation of business terms), to resolving entity mismatches across systems (deduplication and entity resolution), to mapping raw data into forms that reflect how the business actually thinks (contextual semantic layer).
Solving this problem calls for a foundational different kind of tool. One that collects nuance from both technical and non-technical users. One that checks if a model’s output matches not just a query, but the intent behind it. One that might use different models for different tasks throughout the process.
All of these factors make this a very hard, but very fascinating problem to solve. If you’re interested in following along as we tackle this problem, please follow our socials on LinkedIn and X and check out our product as we progress at astrobee.ai.