Is Business Intelligence Truly Dead?

Francois Ajenstat on rebuilding analytics tools from first principles for AI

Host Satyen Sangani, CEO of Alation, opens the episode by framing what Francois Ajenstat, founder and CEO of Golden Analytics, is arguing: that the dashboard was never the point, and that large language models change the path from raw data to insight.

[00:00] Satyen Sangani: Welcome back to AI Radicals. We're sitting down with a legendary product leader who has quite literally helped shape every major wave of modern analytics. Francois Ajenstat began his career at Cognos, helped lead product initiatives at Microsoft, and then spent nearly a decade as chief product officer at Tableau, where he played a pivotal role in creating the self-service analytics movement that transformed how businesses use data.

[00:27] Sangani: Today, he's the founder and CEO of Golden Analytics, built on a bold idea: AI isn't just changing analytics software, it's changing how organizations make decisions, period. His take? The dashboard was never the destination. Rather, it was the journey from raw data to insight, and whether that requires a room full of analysts or is something anyone in the business can do themselves.

[00:49] Sangani: So today we ask, what does it look like if every single person in your organization could operate like a 10x analyst? We deep dive into how LLMs are rewriting the question and answer loop, why context is the ultimate bottleneck for AI, and why modern token pricing models are effectively rewarding waste instead of efficiency. If you want to move past the AI hype and build something your team actually trusts, this is the episode for you.

[01:14] Producer: This episode is brought to you by Alation. If your data teams are still spending weeks packaging data for AI and analytics, there's a better way. Alation's Data Products Marketplace lets you build certified, governed, AI-ready data products, no code required. Get the guide at alation.com/data-products.

[01:37] Sangani: Today, our guest has helped shape nearly every chapter in the history of analytics. So you might be expecting to hear a historical figure, but what we really have here is somebody who's even greater than that: Francois Ajenstat. He began his career at Cognos, helped lead products at Microsoft, and then spent nearly a decade where I got to know him as chief product officer at Tableau. He played a completely pivotal role in building what a lot of us know as the seminal company in self-service analytics.

[02:01] Sangani: Today, he's the founder and CEO of Golden Analytics, which was built on a bold idea, which is that AI isn't just changing analytics software, it's changing how organizations make decisions, period. And so after thirty years of watching the space evolve, it's a real privilege, Francois, to have you on. Welcome to AI Radicals.

[02:25] Francois Ajenstat: Hey, Satyen, good to see you. And I think you just called me ancient. That's what I took from that intro.

[02:31] Sangani: I did. Well, the good news for you is that I'm even older than you. So if you're ancient, then I'm sort of...

[02:38] Ajenstat: We're data dinosaurs.

[02:39] Sangani: Yeah. I'm into a planetary scale. It's rough.

[02:45] Ajenstat: Well, thanks for having me on here.

[02:47] Sangani: I start all my episodes by insulting my guests, so it's a good start.

[02:51] Ajenstat: I love it. We're starting on a great position.

From Cognos to Microsoft to Tableau: How the BI industry got built

Ajenstat traces three decades in data, from writing SGML parsing code in Ottawa to the first wave of BI vendors to putting analytics inside SQL Server and Office. The through-line is the same one that later produced data democratization: getting data out of IT's hands and into the business.

[02:54] Sangani: So you are now a founder, and I really want to get to that, but let's start with history. Tell me a little bit about, I mentioned you started at Cognos, but tell us a little bit about your history. How did you start in analytics? How has it evolved from your perspective? If you can give us a two- to five-minute stylized history of your interaction with the world of analytics and what you've seen, I think it would help the audience get context that we're going to build up to where you are.

[03:22] Ajenstat: Absolutely. So I have been in the data space for almost thirty years. I actually started my career at a little startup in Ottawa, Canada, being a programmer. And I wrote a lot of prototype code at that time, of which one of them was a micro document system. So I'm going to go way back in time, but before there was HTML, there was SGML, the grandfather of HTML. And so we built a system and a database that would parse that SGML and move it into different forms so you could translate it to websites and documents and all of these things.

[03:59] Ajenstat: All that to say that I love databases. I loved it in school, I loved building this application, and I got to join this company called Cognos, which at the time was actually a large Canadian company, one of the largest software companies in Canada. And I got introduced to the word business intelligence at that point. Cognos, Business Objects, MicroStrategy, and Hyperion were part of that first set of vendors creating the BI industry, because before that it was actually punch cards, and now we actually had software that would allow you to produce reports and data. And I just loved data, and I loved finding ways to get it out to the users.

[04:38] Ajenstat: So from Cognos, I got to go to Microsoft, and Microsoft was starting to put BI tools in the database with reporting services and OLAP services back in the day and data transformation services, and we got to really do analytics at scale. Now, back then it was...

[04:55] Sangani: And this is prior to Power BI.

[04:57] Ajenstat: Way before Power BI. Correct.

[04:59] Ajenstat: And the beginning of Microsoft was this acquisition from Panorama Software of the OLAP technology, which became the core of the BI strategy at Microsoft. And that strategy was both on the database side with SQL Server and on the front-end side with Office. So I actually played a role in both sides. I was in SQL Server, and I was in the Office team building experiences. But we really saw what it meant to deploy analytics at scale, and build reports at scale, and drive consumption at scale. And that was great when IT was the one building the reports for the business.

[05:15] Ajenstat: But we had always tried to find ways for the business users to do that, which was what we were trying to do in Office with pivot tables and Office web components. It was all about putting data into the hands of the users. But the interface wasn't quite right.

Why did Tableau break through when charting tools were everywhere?

Ajenstat explains what he saw in Tableau that the market had dismissed, and why the tool's real advance was the act of exploring data rather than the chart it produced.

[05:36] Ajenstat: And I found this little company in Seattle called Tableau, which back then we kind of joked around was Tab Who. Nobody had heard of it. Like, ugh, another charting tool company. There's a lot of those out there. But I thought, "Wow, this is an opportunity to go and transform how data can be used." And I remember playing with the tool for the first time, and I got some data. I played with the tool, and I forgot my list of requirements, and I just started having fun with data.

[06:15] Ajenstat: And that led to 13 years at Tableau, really transforming how data could be used by people. That was so rewarding. But today, we're in the world of AI, and a lot of the tools that exist for analytics are born before AI. Tableau's 25 years old. Power BI really is 15, 20 years old. Looker is 16 years old. All of these tools were born before there was a Snowflake, before ChatGPT was created. And I thought, "Wait, this new technology provides new ways to work with data." It's not just another chatbot for data. You can reimagine it from first principles. What could it be?

Is business intelligence dead in the age of LLMs?

Sangani puts his own contrarian claim to Ajenstat: that LLMs commoditize visualization and let a person ask questions in their own language rather than an analyst's, which he had argued publicly makes BI obsolete.

[06:57] Sangani: Yeah. So it's funny because we talked a little about spicy takes. I put out a LinkedIn post that said BI was dead. This was seven or eight months ago. And my basic argument was that first the models would commoditize visualization. So with a prompt, you could ask a question, and you would get the optimal viz given what the model knows about the question and the context it has about you and what you understand and what the best ways are to answer questions of that form and substance.

[07:29] Sangani: I have thought that the other thing that's really interesting about these models is that BI always had this construction, which was that you would build this semantic layer, this language that effectively would describe the data in a way that would allow you, the builder of the report, to explain it to the rest of the world. But really, those semantics were only known by you as the report creator. The thing about LLMs that's really powerful is it allows me, as a person asking the questions, to express my questions in language that I know, not having to give a care about what some arbitrary programmer or some arbitrary report developer knew about.

[08:12] Sangani: So for me, those were the fundamental problems that BI solved. One was this issue of, how do I see the thing that represents the data that I'm trying to understand? And two, how do I ask questions in a way that I can understand? I'm sure with Golden, which is obviously a company that is doing analytics and visualization, you probably don't believe that. So tell me what's wrong with my thinking. Tell me what's wrong with how I think about the world, and what is dead about BI or what problems have yet to be solved that are important.

Why was visualization never the hard part of BI?

Ajenstat agrees that charting was commoditized long ago, and argues the misread is about dashboards: self-service replaced the IT report factory with a dashboard factory, where each artifact answers one question and stops.

[08:41] Ajenstat: Well, I don't think you're wrong. And visualizations have been commoditized for a long time. Creating a chart, creating a visualization is not the hard part. That actually is commoditized. And I think that's one of the things that people forget: tools like Tableau weren't about creating the charts. It was allowing you to ask questions easily, because that's actually the part that I think is really, really hard. People don't know how to ask questions of their data. They struggle with that.

[09:07] Ajenstat: And with Tableau, the mission was helping people see and understand data. Seeing data, this is the spirit of visualization, helps you comprehend the data more easily. And so the whole paradigm of drag and drop, a visualization was an interface for data as opposed to the chart. The chart was never the result.

[09:32] Ajenstat: Where I think people also get confused or misrepresent... When people say dashboards are dead or BI is dead, or whatever that "is dead" thing is, it's that the dashboards have become like single reports. Self-service emerged from the old report factory where IT built all the reports, and now the dashboards became the new dashboard factory. It's a new report factory. They're all bespoke for one question, but they don't allow you to ask the next question, and the next question, and the next question, whether you want to type it in or click on it or express it whatever way you want.

[09:56] Ajenstat: So what we're thinking about, or trying to do, is actually not creating another dashboarding tool. We're building experiences for data, some of which may be dashboards, because we still have dashboards. I have an operational dashboard to see how my app is going. I have my weekly sales dashboard to look at the status of my business. That's normal, because there are things you do on a repeated basis.

[10:30] Ajenstat: But what is important is not just to be able to see the number, but to be able to say, "Well, what happened here? Why is that number down?" And most of the dashboards don't allow you to take that next step. They just report on the information. They don't allow you to take an additional step to ask the following question. And that's really the problem we're trying to solve: making the question and answering problem so much easier, where you don't require the skill level of the past, and you don't require the ability to know how the interface works, but the data should speak for itself, if that makes sense.

Why Golden Analytics builds opinionated data experiences on top of the LLM

Sangani asks whether AI-assisted exploration is simply the new BI. Ajenstat's answer separates the model from the product: the LLM is the raw capability, and the value is in a purpose-built experience above it rather than another chat window.

[11:03] Sangani: It does. I mean, in some ways, with Tableau, at the end of it you got a really beautiful artifact, report, dashboard, whatever you want to call it. But what made it come alive for me was the creation process. It was the act of thinking through how do I represent this information that was super powerful.

[11:30] Sangani: And on some level you're saying, tell me if I'm wrong, but LLMs almost allow that to be true for not somebody who's a technical analyst. Theoretically it should lower the barriers to entry for anybody, which I generally believe. Is that still BI in your mind? Is that the same class of thing? Is that ultimately the promise of what BI is supposed to be? And so is that the new BI tool?

[11:55] Ajenstat: I think it's still the new BI tool, but the LLM doesn't have to be another chatbot. You can actually build experiences above the LLM that are purpose-built, opinionated for the task of data analysis, and I think that's where there's some really exciting things you can go build. The LLM is just the model. How you express that model can be done in different ways. So I'll give you an example.

Building Golden: two-click dashboards and a constellation of LLMs

Ajenstat, founder and CEO of Golden Analytics, uses dashboard creation to make the point concrete: the company compressed a forty- to fifty-click workflow into two, and it runs many models rather than one, with a specific prompt tuned to each part of the analytical journey.

[12:21] Ajenstat: Creating a dashboard's not the hard thing. We build a dashboard in two clicks with Golden. Two clicks. That's it. Used to take forty, fifty clicks. Now we do it in two. And it's not about the number of clicks. It just expresses a measure of time and effort, but also knowledge. If it only takes two clicks, you don't need to know as much. It's also dramatically faster.

[12:41] Ajenstat: And we use the LLM for very specific things. "I want to clean up this field." Boom, I have this very opinionated prompt with a very specific model behind the scenes. So we don't use one LLM, we actually use them all. We have a constellation of models behind the scenes and lots of prompts to trigger and optimize for every part of the analytical journey.

[13:15] Ajenstat: So the new BI isn't necessarily about the dashboarding. It's not about the artifact. It is that question and answering process. It is the journey that you have from raw data to insights, and how do we compress that so that it requires less effort, great, but more people can participate in it. But I don't think there's one way that people will consume it.

Why are semantic layers making a comeback?

Ajenstat reaches back to Business Objects' Universe to explain why translation layers between the business and the database are being rediscovered, and why trust in the data is the part that no model removes. Alation has written about how a semantic layer, an ontology, and a context layer differ.

[13:43] Ajenstat: There's another element, and I'll lead the witness a little bit, which is that at the very beginning of BI, Business Objects famously had this technology called the Universe, and the Universe was a semantic model. It was a really powerful way of separating out the business user from the complexities of the database and creating that translation layer. And I think that today's semantic layers are getting a resurgence because data is still too hard for people and it has different meanings.

[14:08] Ajenstat: I remember when you and I started working together, the big thing was, well, when you have all this data, how do I know what is curated? What does the data mean? How should I use it? What data is trusted versus not trusted? That is still a really, really important factor: whether you have AI or not AI, can you trust the data? Can you trust the question or the answers that it's given if you don't understand what that data means? And I think that ability to have a glossary, a knowledge base, context, whatever you want to call it, is much more important today than it was maybe twenty years ago.

What would a Cursor for data actually look like?

Asked to define Golden Analytics, Ajenstat starts with the experience of coding with Cursor and Claude and the absence of an equivalent for analysts. The company's founding question was what it would take to make an analyst, or a non-analyst, feel like a 10x analyst.

[14:38] Sangani: Yeah. No, I would certainly agree with that. Before we move forward, I would love to level set on what is Golden. Is Golden solving both of those problems? Is Golden solving both the problem of understanding and determining context, as well as helping the user express and understand information in whatever mental model they have?

[15:00] Ajenstat: Short answer is yes, but I'll tell you a little bit about even why Golden. Golden started because I was spending a lot of time with Cursor and Claude, and I felt empowered. I felt unleashed. I felt like, oh my God, there's this technology that makes developers feel like 10x, 100x developers. It makes non-developers feel like they could build anything in the world. I mean, that is incredible. There's a lot of AI that's out there that's about replacing people. Customer service is a good category for that. But there's an AI that empowers people. "Oh my God, this is it. This is the power of AI."

[15:33] Ajenstat: And I looked at that and I thought, "Okay, let me look at the data tools. Is there a Cursor for data?" And I felt depressed. I was demoralized. I was like, "Wow, why do data people have to have these tools? Why can't they have a Cursor or a Claude for data?" And that was the beginning of the idea of Golden: what would it look like if you made analysts feel like 10x, 100x analysts? What would it look like if you had a tool that made non-analysts feel like they have the same capabilities as the analyst themselves? And the analyst is the proxy for the coder with Cursor or Claude Code.

What is a slider of autonomy in an AI analytics tool?

This is the design principle Sangani singles out at the end of the episode. Ajenstat describes it as a stance rather than a control: the AI is present at every step, and the user decides how much of the work to hand over.

[16:17] Ajenstat: And that started the journey. So what we built, and part of the thesis of it, is really around this idea of a slider of autonomy. And what that really means, it's not a physical slider, to be clear. It's more of a design principle that the AI is there with you every step of the way. You can do everything manually if you wanted to, but it's faster than before. You can ask the AI, "Hey, can you do this analysis for me?" Might get it 90% of the way there. I'll finish off the last 10%. I'm in control. Or just do all of the work.

[16:40] Ajenstat: And I bring all of that together because it means that a non-analyst could just connect to Golden with their data and say, "Okay, well, give me some insights." It does that automatically. "Tell me what I should ask." It does that automatically. Or if I'm an expert, I can do my workflow the way I've always done it, but it's just really removed a lot of the burrs of the old technology.

[16:59] Ajenstat: So we're really coming at it from those two ways, but we're building on the LLMs as our silicon chip. That's kind of the way to express it, which is that we're exploiting what the LLMs can do for the task of data analysis. And so as a result, that process is just so much faster than before and so much smarter than before. And that's why we built it. And yes, there's an old tech, new tech kind of approach, but fundamentally, it's faster answers than you could ever do.

Why isn't data the same as software?

Sangani raises the distinction between coding assistance and data work: software fails loudly and can be tested, while a wrong number arrives looking exactly like a right one. Alation has covered what rigorous AI agent evaluations require for exactly this reason.

[17:43] Sangani: Yeah. The idea of a Cursor for, or even Claude Code for, analytics is a compelling frame. And then one of the design principles of, hey, I want to be both fed insights but... Anthropic, in that paper that just came out, maybe it was about a month ago now, said something pretty relevant to what I believe, which is that data isn't software. And there are a whole bunch of differences between data and software. With data you can get an answer. It can be completely wrong. You'll never know why. Software obviously has clear error conditions and failures, and you know exactly what's going wrong, and you can theoretically debug it. You can put tests out for software. Evals for data are interesting, but not fully inclusive. There's always the tail which may not give you the right answer.

[18:36] Producer: Quick break, brought to you by Alation. Here's a stat that should stop you cold. MIT research found only 5% of enterprise AI pilots delivered ROI in production. The problem isn't your models, it's knowing where to aim them. We've put together a free guide for enterprise leaders. It's a framework for identifying which processes are ripe for AI agents, what green flags and red flags to look for, and how to build a knowledge foundation that makes AI trustworthy at scale. It's not theory. It's drawn from how Global 2000 companies are actually doing this. Download it free at alation.com/ai-guide.

How do you use LLMs on billions of rows without sending them the data?

Ajenstat lists the first hard constraint Golden Analytics had to engineer around: enterprise tables are too large to pass to a model, and users still expect interactive speed. The company's answer is to reason over metadata and keep the deterministic work in SQL.

[19:19] Sangani: You mentioned autonomy, but what are the different problems you have to solve in building this interactive LLM-fueled tool for software? Where does the metaphor hold, and where does it fall apart?

[19:32] Ajenstat: Well, data isn't software, and data is unique to every customer and is constantly changing. So it's not a static thing that you can say, "All right, the number today was twelve," and tomorrow, is it still twelve? I don't know. It's changed because we have new rows, or deleted some rows.

[19:39] Ajenstat: So we struggled with a number of big problems. The first one is how do you make the LLMs work when you have potentially billions or trillions of records? You can't send that data to the LLMs. And you need interactive speed. So we actually came up with some really novel approaches where we can use a lot of the metadata about the data to infer where things are at. But for the things that are deterministic, where I ask a question, the LLMs actually don't formulate that at all. It's SQL that does that behind the scenes. So we're actually grounded on SQL, but everything around it, of how you operate with it, is the LLMs. So that's thing one.

How do you choose which model to use at each step of an analysis?

The second constraint Ajenstat names is model selection. No single model is best across the whole analytical flow, so cost, latency, and accuracy have to be traded off step by step, and the tool has to add value on data it has never seen before.

[20:22] Ajenstat: Thing two is the fact that as you go through the journey, not every model is great at every part of the analytical flow. Do you use Sonnet for everything, or Opus or Fable? When is it appropriate to use different things? And there's a factor of cost, there's a factor of latency, accuracy. So all those things have to be really considered as you come through it.

[20:46] Ajenstat: And how do you make this work also when you've never seen the data in the first hand? It's one thing if you can spend six months curating the data and figuring out everything that's out there. Great. We want to be able to just connect and go and add value on the first minute you use it. That's really, really hard.

Four hard problems: autonomy, model routing, context, and cold starts

Sangani plays back the constraints in his own words to make sure the list is clear, and the two land on the follow-up question as the real frontier, including whether the next step is typed, clicked, or driven by the dashboard itself.

[21:16] Sangani: So I want to make sure that I've heard and understood the problem. So the first is this notion of, sometimes I want to be fed the insights and sometimes I want to dive deep and go down my own rabbit hole. A second one is effectively this LLM gateway and routing problem, which is, when do I go use which LLM? Because I don't always want to pay Opus 4.8 high for every simple operation.

[21:47] Sangani: And then also, obviously, there are some jobs that are optimized given the model. Third problem is this question of, hey, look, data can't all get shipped to the LLM in the same way that all text that you would be crawling over might get shipped to an LLM, and therefore it requires us to be selective and be thoughtful about what context we feed to the LLM.

[22:06] Ajenstat: Correct.

[22:06] Sangani: And even what we feed allows the LLM to suggest the right follow-up questions, the right ideas, so that I, as the analyst, can interrogate it appropriately. And then this fourth construct is... Sorry, I'm forgetting the last thing that you said. The fourth construct was what?

[22:30] Ajenstat: No, you got it right. And the next big aspect is which models you choose, how you get the answer, and then what do you do as a follow-up. A lot of people today will go to Claude or ChatGPT, get an answer, and that's what it is, and you're always prompting for the next thing and the next thing. Here, actually the follow-up may actually be clicking. It may actually be the dashboard that drives the LLM. Not always a text.

[22:58] Sangani: Yeah, which gets back to this idea. I assume you guys have played around, and maybe the audience hasn't, with this idea of MCP apps, where on some level chat's driving the UI, but the UI is correspondingly also being generated and driving the chat. And so there's this very interactive modal between those two things. By the way, I think I remembered your fourth thing, which is ironic because it's literally the thing that we do, which is the building of the context around the dataset that you have no a priori knowledge of.

Why use an analytics tool instead of Claude or ChatGPT directly?

Sangani asks the build-versus-buy question buyers are actually weighing. Ajenstat splits the comparison in two: against legacy BI the argument is speed and cost, and against a vibe-coded dashboard the argument is what happens in production. Alation's own take on conversational access to governed data is chat with your data.

[23:17] Sangani: Those do seem like the salient problems. I guess there are so many directions we can take this in, but if I'm trying to put myself in the buyer's shoes, I think everybody's like, "Why do I use this thing, Alation, Golden, Tableau, Power BI," whatever it is in the galaxy, or the model itself, or Claude or ChatGPT itself, because gosh, those things seem so much more powerful, or they seem like they're so multipurpose and capable. What are the problems that you think are going to be most defensible, or which are the ones that you're diving deepest on as you build a company? And what have you found to be the hardest things to figure out as you've solved some of these issues?

[24:11] Ajenstat: If I look at the competitive dynamics, if you will, of who we're going after or who our customers are comparing us to, obviously there's the legacy set: Tableau, Power BI, Looker, Domo, et cetera. And you can see a similar approach, but time is compressed. So the dynamics are speed, power, and cost. Dramatically cheaper, faster, all of that good stuff.

[24:33] Ajenstat: On the other side, if you compare it to Claude or ChatGPT or Replit, you have the vibe-coded dashboards. There it's much more of a build versus buy argument. If you only have one dashboard to build, then you can go do it that way. But the problem that exists there is those are great for prototyping, but to make it go in production, this is where customers get really, really frustrated. Because two different users may have two different answers, even if they have a semantic layer. You then have to deploy the thing. Every update burns some tokens.

[25:07] Ajenstat: And remember that the motivation for the frontier companies is getting you to consume as many tokens as possible, spend as much money as possible. We changed our business. Our pricing model includes tokens. There's no price for tokens.

Why does Golden charge per user instead of per token?

Ajenstat explains the pricing decision and the incentive logic behind it, including his bet that token prices fall over time and his Slack analogy for what per-message billing would do to a collaboration tool.

[25:21] Sangani: So you're moving... Does that mean that you're moving away from a consumption-based model, or that you're moving away from a token-based consumption model? Or are you moving the model altogether?

[25:28] Ajenstat: We're charging per user.

[25:31] Sangani: You're charging per user. Wow.

[25:32] Ajenstat: Which is completely radical in today's world.

[25:34] Sangani: Like the 2000s, what their pricing model was like. It's amazing. But that's great. Why did you do that, and do you feel like that's a counterbalance now to the Alex Karp, every Fortune 500 CEO? I don't know if you saw the interview, but he got up and he's like, "Every Fortune 500 CEO is pissed about these tokens." That by itself might be its own thing, but as you said, there's an incentivizing base set of behaviors that the models and the clients are effectively taking me down, which is both token heavy but also inconsistent. Those are some of the things that you think could be solved?

[26:11] Ajenstat: Correct. And if we just tackle the pricing model for a second. Today, people are charging for tokens because tokens are really expensive. So my bet is, first, the price of tokens is going to go down over time, just like storage has gone down over time with the cloud providers. So I think it's going to go down, the capabilities will go up.

[26:26] Ajenstat: The second is the incentive alignment. My incentive alignment is to enable you to ask more questions of the data, to allow you to get insights. That's all I need to do. Whether that consumes ten tokens or ten thousand tokens, as long as it can get you to that answer faster than anybody else, that's how I differentiate. Which means if I own the price of the tokens, I need to optimize my system to be as smart and efficient on the token consumption as we can. That's a really good thing.

[26:47] Ajenstat: I mean, consider if you had Slack and you had to charge every time you sent a Slack message. That would be ludicrous. You'd say, "Ooh, is that message to Satyen worth sending? I don't know if it's worth that."

[27:12] Sangani: Probably not in that case.

[27:12] Ajenstat: Probably not. Exactly. Maybe we should send fewer messages. But what you want as a collaboration tool is collaborate more. What you want as an analytics tool is get more insights, ask more questions. And I think the pricing models are a little bit upside down today where you're saying, "Well, every question has a price." Well, that doesn't allow exploration. So we're coming at it differently.

Why is token spend harder to control than cloud compute?

Sangani presses on why the same critique doesn't apply to consumption-priced cloud compute. Ajenstat's answer is about control: instance sizing and materialized views are well-understood levers, while token spend stays abstract until the bill arrives.

[27:35] Sangani: Yeah. I guess one question for you, which is a little bit orthogonal, but why does that logic hold true for the LLMs but maybe less true, or seemingly less true, for the compute providers who also charge on a pay-per-byte basis? Or do you see any differences between the two, or do you think they're exactly the same thing?

[27:56] Ajenstat: I think there's some similarities, but the compute providers maybe have a little bit more flexibility, and I think this is where today versus tomorrow there'll be differences. Today with the compute providers, I could say, "Oh, I want a micro instance," or, "I want a double XL." You have a lot more control over the performance, over different factors of that compute, where the tokens feel a little bit more abstract. Yes, I could change the model and get a cheaper model, blah, blah, blah, but when do I do that? How often do people actually do that? Who controls that? There's less control there where it feels like there's more on the compute side.

[28:36] Sangani: The levers of optimization are far better understood, and if you want to do a materialized view or size up or down your instance or have hot or cold, all of those things are levers that are well understood. And going low, medium, high on thinking doesn't really tell me very much, because I don't even know if that degrades the quality of my response.

[28:55] Ajenstat: That's right.

[28:58] Ajenstat: And when you ask a question, you pay a price. Oh, it got it wrong. Well, now you've got to go fix its thing. You pay another price. Oh, you want to keep optimizing? Another price. We had a customer who ended up paying $100 to build one dashboard in token prices. I mean, that's ridiculous.

[29:16] Sangani: Yeah.

[29:16] Ajenstat: But they didn't know. They kept vibing, and all of a sudden a month later the bill shows up.

[29:23] Sangani: Fascinating.

Will chat replace every other interface for data?

Ajenstat draws a parallel to the arrival of mobile, when the PC was declared dead, and argues that data work will stay multimodal: chat where chat fits, point and click where it is faster, and speech where that wins.

[29:23] Ajenstat: So I think there's that disconnect there overall. But the other thing I want to add in is something I said before, which is I do think interfaces matter. I think that people don't just want to chat, and yes, chat is a really important interface, but I think we'll be in a multimodal world.

[29:33] Ajenstat: And I think we saw a parallel of that when mobile came out. People were like, "Oh my God, I never need a PC. PCs are dead. I'm just going to use my phone or my tablet. That's the device." And what happened? I have the three devices right in front of me right now. I actually probably have a lot more devices than that.

[29:51] Ajenstat: But I think people will want the right interface for the right job, and sometimes a chat interface is the right way. Sometimes point and click is so much faster. Sometimes it's not even point and click. Sometimes it's speech. And so having that ability to adapt to the interfaces I think is actually a really important piece. Again, just another chatbot isn't necessarily the right thing, because then they're actually undifferentiated. I don't know that one is better than the other.

What does MCP actually change for data tools?

Ajenstat's view is that the Model Context Protocol changes the programming interface rather than the user interface, and that its real effect is removing custom integration work between products. He says he now uses HubSpot more through MCP than by logging in.

[30:27] Sangani: Do you think that MCP apps, or that idea, helps the models get to this interface question sooner, faster, not at all? What have you seen there, and is that something that you've looked at?

[30:39] Ajenstat: I don't know if they change the interface. What they do is they change the programming interface, because MCP, at the end of the day, is just a more standardized API that everybody can talk. I think it's great to add context. I think it's great to take action, because now you have tools you can call out to. So I think it democratizes the integration of the apps in a way that maybe was really, really hard before, where you needed lots of complicated software to bring these things together.

[31:10] Ajenstat: That's the part that actually excites me the most: the step between product A and product B is no longer a custom development effort. It's literally just a call to MCP, and that opens up things and actually adds more value. I probably use HubSpot more via MCP than I ever do logging into it.

[31:30] Sangani: Yeah, totally.

[31:31] Ajenstat: It's huge. I actually get more value out of it, but I didn't have to write one line of code. I just used open standards with MCP.

Are metadata, governance, and BI collapsing into one category?

Sangani observes that the traditional product boxes of master data, metadata, governance, and BI have stopped holding their shape. Ajenstat agrees that context is worth more than ever, which is the premise behind active metadata management, while cautioning that knowing which context to retrieve is still unsolved.

[31:41] Sangani: Tell me a little bit about this context problem. Obviously we know a little bit about it, or we think we might know a little bit about it, but how do you view it? One thing that I think we've felt and observed, and maybe this is a little bit leading the witness, is that the traditional boxes of master data, metadata, governance, BI, all these boxes are very shifty and it's not clear to me what the boundaries are anymore. It wasn't clear in our world. I think in our world, what we termed as data intelligence, where it's metadata and governance and catalogs, they're all kind of the same thing. But it feels like now it's even becoming less clear. How do you feel about that? Because it feels like you're building an integrated system. How do you think about this box question? Because you've seen these categories evolve over time as much as anybody.

[32:33] Ajenstat: Well, the first thing I'll say, which is I believe companies like Alation should be 10x larger, because everybody needs it. And this is not pandering. I'm a huge believer in the more context you provide, the more value there is in the end. But whether or not it's a centralized context graph or whatever you want to call it, what I think is really important is that knowing which context to call out and not hallucinating is still a challenge.

Does more context always produce a better AI answer?

Ajenstat describes a test at Golden Analytics where the tool was connected to everything a customer had. The system found coincidences and invented correlations instead of answering the question, which is the counterintuitive result behind his position that context has to be prepared, not merely available.

[32:49] Ajenstat: We did a test where, with Golden, we just connected to everything and said, "Great, now enrich the answer." It couldn't conclusively connect the dots. It tried. It invented possible correlations. But it wasn't quite there because there wasn't the work done ahead of time. The fact that it could read my Notion doc and Slack, it found things that happened at the same time, but not necessarily the real answer to the question.

[33:30] Ajenstat: Our view of it is if you have no context, you should be able to get value. And if you have a lot of it, you should be able to leverage it. But just giving more context actually doesn't give you a better answer.

What is a context graph, and how is one built?

Ajenstat explains what Golden Analytics generates for itself: a record of how each table is actually used, for churn analysis or upsell or territory planning, captured from what he calls the exhaust of every step a user takes. It is a narrower artifact than an enterprise context layer, scoped to the task of data analysis.

[33:44] Sangani: So do you help generate context as you do the work, or help the analyst or the user generate context as they do the work? How do you think about your role in that?

[33:54] Ajenstat: So we're generating a unique context graph, if you will. What we generate is we know how data is being used for different use cases and how people traversed our tool to get to that answer. So if you want to say, "I've got the accounts table," I can tell you everything, how those fields are defined, awesome. But is it being used for churn analysis, for upsell analysis, cross-sell? Is it used for territory planning? It's all the same table, but used in different ways.

[34:17] Ajenstat: And what we see is, what I call it the exhaust, but every step that somebody does in Golden is essentially recorded in a time machine. And so that context can be used for user two, or the next time you come in saying, "Hey, Satyen, I know you're doing territory planning. You've already taught me how to do that. Would you like me to do it again? Oh, by the way, somebody else did some territory planning as well, and they're looking at different fields than you are. Do you have a different assumption than they do?"

[34:49] Ajenstat: So we're able to do it from the context of the job that we're solving for, which is the task of data analysis. And then for all of the external context, there we're just plugging in. We're not solving that. We're just solving it by saying, "Just point me to your context." It could be in a catalog, it could be a semantic model, it could be a Notion doc, could be a wiki, whatever that is. As long as you tell me where I should look, I'll use that as my authoritative source versus just searching everywhere and not necessarily finding the right place.

Pointing AI at an authoritative source beats connecting every app

Ajenstat sharpens the earlier finding. Context helps when it is directive, and an open-ended connection to every application produces the failure mode of linking a marketing campaign to an unrelated performance drop.

[35:31] Sangani: And you said that when you've done that, which was interesting, and I think counter trend, when people have done that, it hasn't materially improved the output of what you're doing, or did I mishear you?

[35:46] Ajenstat: It does when you are more directive. So if you say, "Look, the context for this lives in this wiki or in these pages," great. Awesome. If you keep it too open-ended... So at one point, what we said in Golden was, "Hey, just connect to all of your apps, and we'll use that at query time to figure out the context." Well, the fact that a marketing campaign happened here doesn't answer why there was a performance degradation there. But it was connecting dots that shouldn't have been connected just because you weren't as directive about these things.

How do you tell a repeatable analysis pattern from a one-off exploration?

Sangani reframes what Golden Analytics captures as undeclared skills, reusable templates learned from watching real work. Both agree the hard part is separating a genuine pattern from someone testing a hunch that was never meant to be repeated.

[36:24] Sangani: Yeah. There was so much that you said there that I thought was really interesting and instructive. One, it was almost like, look, we're going to watch what people do, and as we watch what people do, we're effectively developing these skills, these kind of undeclared skills, and these skills are effectively going to be templates.

[36:42] Ajenstat: Basically, yes.

[36:43] Sangani: These undeclared skills are essentially going to be templates for other work that other people can do. But, and I think this is very important, it's not always the case that every task is going to be replicable across functions, so you have to be clear on when it's a learned pattern versus an anti-pattern, or just an anomaly within that work.

[37:03] Ajenstat: Or if you're just goofing around, you're playing. I'm trying out a thing. Hey, what if we doubled our investment in financial services? What would that do? It's not a decision. You're just trying out some stuff. You're exploring a hunch, testing out a hypothesis.

[37:19] Sangani: Could be a throwaway. And eventually you're going to have awareness over time of what the patterns are and what are just these throwaway noise chats that effectively occur.

Why do general-purpose AI agents underperform operational ones?

Ajenstat's read on agents is that narrow, operational scope is what makes them work, and that general-purpose agents produce poor output until they are tightly specified. Alation covers this distinction in its glossary entry on agentic workflows.

[37:28] Ajenstat: Yeah, and that becomes our context that we can apply to the task of data analysis. And of course, the other interesting thing, which we haven't talked about, is agents. There's agents that the human can invoke to do some work, but eventually there'll be a Golden for agents.

[37:47] Ajenstat: And what I find is a lot of these agents actually don't really work in the real world unless they're very operational in nature. They know exactly the task that they're supposed to do. The more general purpose agents give you a little bit of, I'll just say crap, a lot of times, until you very much directly...

[38:05] Sangani: Until you very narrowly describe the eval and what it's supposed to do.

Why do cataloging projects stall without a job to be done?

Sangani tells the story of a customer who wanted to catalog faster without being able to say why, and connects it to Ajenstat's point that context has to be built in service of a task rather than as an end in itself.

[38:08] Sangani: So it's funny, you and I haven't caught up on Alation for a really long time, but it's funny because you said, "Look, metadata's valuable and everybody should have a catalog," and I think that's right. But on the other hand, I think this discussion around cataloging context layers, to me, what you said, and I completely agree with it, was effectively that you can't really describe context or build context without knowing what you're trying to do.

[38:40] Sangani: So I had this one customer who came up to me and they were just like, "Well, I want to catalog faster." And I'm like, "Well, that's great. Obviously you're a customer, I would love to help you do that. Why do you want to do that?" And she's like, "Well, don't you want me to catalog faster?" And I'm like, "Well, cataloging's not a verb. It's not something that you just do for the sake of doing it. You have to actually have an end in mind. You have to have a purpose. You have to try to do something."

[39:12] Sangani: And I think the point that you're making, which is really important, is, look, all this stuff is great, but you have to do it in the context of trying to get something done. There's a job to be done at the end of this, which I think is a really important insight and one that I deeply share. And it actually has very much changed how we view what we build and how we think about what we build.

How should AI agents learn how the work is actually done?

Ajenstat argues that agents trained on how people really work outperform agents built on assumptions, and Sangani adds the refinement that matters organizationally: the pattern worth learning is how the best people work. Both then treat catalog, context, semantics, and definitions as one interconnected business context layer.

[39:22] Ajenstat: That's great. This is where, look, we all get excited about technology, especially as technologists. We want the latest toys, we want to be able to play with it all, but we still have a job to do. And we need to go solve real problems. And it's not just about the tech, it's about what are you trying to solve, and then working backwards from there. And if this is the better way of doing it, great. But this is where, to the agent's comment from earlier, if the agent is trained on how humans actually do the work, guess what? They'll do better work. But if you're just making it up, then they're just bespoke things.

[39:59] Sangani: And really, I think the other insight that we found, and you can tell me if you believe this is true, it seems almost obvious, but it's trained on how the best people do their work.

[40:09] Ajenstat: Correct. Yes.

[40:11] Sangani: There are some people who just really, really know how to do the work, and then there's others who are like, "Ah, I just am trying to figure this thing out." And really recognizing the pattern from the experts is a lot of where the hard lives organizationally.

[40:27] Ajenstat: Yeah, I totally agree. And you also said the catalog, the context, the semantics, the definitions, all these things are kind of all part... To me, they're all part of the same world. Whether you're describing the data or describing the business, they're all interconnected. And it is more than a translation layer. It is the business context layer, that some of it is defined in the data because you've transformed the data in a certain way to be used a certain way. Some of it's just the business and you're trying to work down to the data. It's not always obvious.

How do you keep AI context current as data and models change?

Sangani names the maintenance problem: a context layer can be set up once, but data, models, logic, and people all change underneath it. This is the currency question that any data catalog or context layer has to answer to survive contact with production.

[41:05] Sangani: Yeah, for sure. So Sanjiv Mohan, who's this analyst who I'm sure you know, is really thoughtful. I think we all talk about context, and I think it's a great abstraction because it takes all of these things that all of us in the world of data management have been talking about, which get super inside baseball-y. What's the difference between metadata and master data and glossaries and semantics? My head's going to explode if I'm not in the space. And I think it's not really important for the average person to know these things.

[41:37] Sangani: But at least living in this space for a really long time, as I watch all this happen, two things seem obvious to me. One is this directed, end-oriented idea of, look, I'm going to build this context, whatever it is, by doing a job. It's the job that builds the context. The context is not an end to itself. It's not something that I need to spend time managing. If anything, I want to spend less time managing it because nobody ever did want to do it in the first place.

[41:56] Sangani: The other thing, though, that I think is really interesting is that what I found, and I'd love your perspective on it, is that you can set it up once, but the entire problem then comes down to, how do I maintain this stuff to be right over time? And you talked a little bit about this pilot-to-production idea, which is a little bit about how we describe it. But then there's this question of, what was true yesterday may not be true today. The models may have changed. The data may have changed. The underlying logic may have changed. The person may have changed. And all these changes cause all these things to go sideways. And so now the biggest problems are how do I keep this stuff current? How do I keep it alive? Is this something that you've been encountering at scale, or how do you think about this currency problem?

[42:46] Ajenstat: Well, we're still a new company, so we're still in the early days of Golden.

What changes when 99% of your code is AI-generated?

Ajenstat turns the question onto how Golden Analytics builds rather than what it sells: nearly all of the company's code, documentation, and internal knowledge is AI-generated, which forces explicit decisions about what counts as the source of truth and leaves supervision as the human's job.

[43:02] Ajenstat: I'm going to actually flip it in a slightly different lens, which is not the tool that we're building, but rather the way in which we're building the tool. Which I think is actually kind of interesting, because we're building an AI solution using AI tools, and so everything we build, ninety-nine percent of the code we build is AI-generated. All the knowledge about the code is AI-generated. Our documentation is AI-generated. That is a hundred percent an AI-generated company, which is absolutely phenomenal. What becomes the source of truth for a lot of this stuff becomes a challenge. How do you know what is true at that point?

[43:32] Ajenstat: Again, on our customer side, yes, there's a lot of things that change. What we've just defined is, it's both the technological approach where, okay, we've decided the source of truth of our tickets is Linear, our content is in Notion, and we collaborate in Slack. Those are our sources of truth. The human plays a role still in the overall governance, in managing the agents, ensuring that they're not just there to please you, but they're there to do the job that they're hired to do.

[44:02] Ajenstat: I think the same thing will happen: the AI is only as good as the supervision you give it. If you just let it go do its thing without ever tweaking it, changing things, adapting things, I don't think it'll ever be good. So the fact that it's AI-generated is good today, but it requires care and feeding for it to be amazing. This magical thing is like you get the sugar pill on day one. Look at what it did so quickly. But what about day two, day three, day four? That's actually even more important, because there is drift. There are challenges that happen, inconsistencies that you have to maintain.

[44:38] Sangani: Yeah. We're big believers in this idea of needing to build this systemically, that in some sense the system is more important than the output, because the output is now ephemeral. Super cheap to create. Token price aside, generally speaking, way cheaper to create than it otherwise would have been. If you take that hundred dollar example, yes, it's a hundred dollars today, but think back ten years ago or twelve years ago, it was fifteen hours of manual work.

[45:03] Ajenstat: Exactly.

[45:04] Sangani: So it's so different.

How does the role of data people change when AI does the work?

Ajenstat's answer is that tasks do not disappear, they change, and that the new work is often more nuanced than the work it replaced. He puts it in the arc from Teradata and Business Objects, through the modern data stack, to whatever the AI stack becomes.

[45:07] Ajenstat: But in all of this, the role of people changes. I think that's just an important thing to acknowledge: the tasks you used to do, it's not that they're going away, they're just different now. And some work has changed where it's easier. New work has been added that is more complex and more nuanced, and that is actually something that's really important to think about in the system that you're building.

[45:31] Ajenstat: And if we go to the history of data where twenty years ago was Teradata, on-prem, with a Business Objects tool, what you built there changed with the modern data stack, how you built, what you delivered. Well, now there's an AI modern data stack, or whatever AI stack that's being built, where a lot of things are collapsing and changing, and so we have to adapt to it as well.

How are dashboards, apps, and agents converging?

Sangani asks about the merger of AI and applications, and Ajenstat answers in terms of experiences: the core can be shared, while what humans need and what agents and developers need get expressed differently.

[45:55] Sangani: Yeah, it's super interesting. There's also this merger in some sense between AI and apps. You kind of alluded to it. You were like, "Look, there's going to be a Golden for agents, and on some level, this process of building agents is itself very messy and not very easy and not very good." Talk a little bit about that, because I'd love to hear how you think about that evolution there and what might happen.

[46:18] Ajenstat: I just think of it as there's different experiences that are needed, and I use the word experiences deliberately, because there are experiences for humans, there are experiences for agents and developers, which will look slightly differently. The core may be the same. How it's expressed will be different.

[46:35] Ajenstat: So if you think about a dashboard, for a while we had dashboards as apps, because you were using the dashboard metaphor to build an app. Now we have apps that consume dashboards, or data input dashboards, or apps that have dashboards. All of these things kind of get intertwined.

Why does adoption matter more than how fast you can build?

Ajenstat closes on the measure he would hold every one of these tools to: whether the work gets used. Faster building that nobody consumes is wasted effort, which is the same standard Alation applies to an AI operating system for the enterprise.

[47:03] Ajenstat: The experience for data is really what matters, because all this work we're doing, all that hard work, the incredible work that this community is doing is for naught. It's throwaway if people aren't using it, if it's not delivering real value. That's the part that we often forget with these tools. "Look at these new shiny things we did. Look how much faster it is," yet nobody consumes it, and you just wasted time. And I just encourage everybody to think about how do we get it to good use by as many people as possible for as many use cases as possible? And whatever helps you move that ball forward, that's a worthwhile investment. Just push that forward.

[47:31] Sangani: Yeah. What an awesome sentiment to conclude this episode on. I love catching up with you because I always learn something, and you're just one of these people who I think is so naturally a natural teacher but also very generous in spirit. So I hope everyone's enjoyed this episode. There's probably at least another two episodes that we could have had in the rest of this conversation, but Francois, thank you so much for taking the time, and look forward to catching up live soon.

[47:56] Ajenstat: Thank you, Satyen. Really great to be here with you, and I'm excited to be building and learning together.

Satyen's takeaways: The slider of autonomy and token pricing 

Sangani closes with the two ideas from Ajenstat he keeps returning to: autonomy as something the user dials rather than surrenders, and the incentive problem baked into consumption-based AI pricing.

[48:05] Sangani: Francois left us with two massive takeaways that I can't stop thinking about. First, that slider of autonomy. AI shouldn't just blindfold the human and take the wheel. It needs to sit right beside us, letting us dial the automation up or down based upon the job and the work to be done. That is a completely different, much healthier posture than most AI tools take today.

[48:20] Sangani: Second, his reframe on pricing. Challenging the current fashion around consumption pricing models, he critiques that if an AI vendor profits when you use more tokens, they are incentivized to keep you searching, not give you the answer. I'm Satyen Sangani, CEO of Alation. Thanks for tuning into AI Radicals, and if you liked what you heard, leave us a review and share this episode with a fellow radical. See you next time.

[48:47] Producer: Thanks for listening. This episode was brought to you by Alation. AI can quietly break, and it's not always obvious why: the data, the context, or the agent itself. Join hundreds of data and AI executives, governance leaders, and practitioners to learn how to catch it before it costs you at revAlation this fall. It's Alation's global event series. Chicago on September 17th, London on September 30th, and Sydney on October 8th, bringing together data and AI business leaders to talk about what's actually working in production, not just in the demo. If you're trying to move from "We bought some AI tools" to measurable business results, this is where that conversation is happening. Find your city and register at alation.com/revAlation.