The Death of Data Gatekeeping: AI Makes Everyone An Analyst | Hex Cofounder

Summary

Podcast Summary:

AI + a16z Podcast: The Death of Data Gatekeeping – AI Makes Everyone An Analyst
Guest: Barry McCardle (Cofounder and CEO, Hex)
Host: Sarah Wang (General Partner, a16z)
Date: December 5, 2025

---

Episode Overview

This episode dives deep into how artificial intelligence is democratizing access to data within organizations, turning everyone into a potential analyst. Barry McCardle shares how Hex is leading the way by embedding AI as a core analytical partner rather than a mere add-on to traditional business intelligence (BI) tools. The conversation focuses on the end of data gatekeeping, evolution of the modern data stack to the "postmodern" era, agentive workflows, the importance of semantic context, building with new AI paradigms, and even lighter insights on technology, company culture, and branding.

---

Key Discussion Points & Insights

1. The False Promise of Data Democratization

[02:21 – 04:01]

• Data democratization has been a buzzword for decades, but little real progress has been made. Most decisions are still not truly data-informed because the process remains friction-laden.
• Dashboards have enabled KPI tracking but mostly prompt more questions than they answer.
• With AI, the vision is now becoming reality: "A world where everyone in an organization can ask and answer questions with data. And it's just enormously exciting."
  — Barry McCardle, [03:52]

2. Traditional vs. AI-Driven Analytical Workflows

[04:15 – 08:17]

• Before AI, workflows were complex: multiple fragmented tools, manual SQL writing, CSV sharing, and lack of collaboration.
• With AI: Massive friction reduction. Now, natural language interfaces and tools like Hex’s Slackbot let users easily query data and get instant answers.
• Three major shifts:

  • Breadth: More people have access to analytics.

  • Depth: AI helps go beyond trivia—layers and layers of follow-up questions are possible.

  • Speed: "Time to insight" shrinks, possibly even going "negative" as AI surfaces issues proactively.

    "I'm interested in a world where that time to insight actually goes negative."
    — Barry McCardle, [07:35]

3. New UI Paradigms: Threads and Agentive Workflows

[09:26 – 13:17]

• Hex Threads: A conversational interface for querying data; brings AI’s power to non-technical users while governing access and trust.
• Notebook Agent: Earlier agent targeting technical users; underlying framework is now being generalized across the product.
• Threads constrains AI actions for less technical users but leverages the same agentive reasoning and context frameworks as Notebook Agent.
• Embedding AI within workflows (e.g., via Slackbots and integrations) is helping overcome traditional tool silos.

4. Evolving Agent Capabilities & The Role of the Semantic Layer

[16:12 – 29:31]

• Step change: Multi-turn, agentic reasoning. Modern LLMs can now reason iteratively, calling tools and subagents, handling increasingly complex problems—even as context sizes balloon.

• Differences between model providers (Claude, Gemini, OpenAI) influence the quality and approach to data analysis.

• Correct, semantic SQL generation is far harder than raw, syntactic SQL. True value comes from encoding the proper business logic and context—i.e., the semantic model.

• Hex is investing heavily in context management, governance, and observability:

  "The fastest way to really annoy a lot of people is to have a system that's giving them consistently wrong answers."
  — Barry McCardle, [26:05]

• Real-time feedback loops (e.g., agents evaluating agent answers, "confusometer") enable continuous improvement.

• Data teams’ roles are evolving into context engineers, perpetually refining the guidance AI has when answering data questions.

5. Trust, Accuracy, and the Limits of AI

[31:34 – 36:28]

• Trustworthiness trumps abstract "accuracy." Because analytics encompasses subjectivity, context, and randomness, organizations should prioritize systems that produce trustworthy and transparent answers, not just statistically "accurate" ones.

• Providing context, exposing lineage, and enabling human double-checking is crucial:

  "The word we use is trustworthy. We want you to trust that. And that's more than just accuracy."
  — Barry McCardle, [34:41]

• AI’s power increases when it’s built into the system of record for analysis, not merely integrated superficially.

6. Building Natively with AI: Internal Team Structure and Product Strategy

[38:46 – 45:21]

• Hex was early in experimenting with AI, but an initial "Magic" team (dedicated to AI features) was disbanded.

• Why? AI now is so central it can’t be isolated; every team builds with AI features as a first-class citizen.

• The analogy: Sketch (old design tool) had a “cloud team.” Figma was just cloud-native. Similarly, Hex is now fundamentally AI-native.

• AI is now interwoven into the whole product, migrating from "bolted-on" features to core infrastructure:

  "Magic is dead. Long live Magic. Everything's magic now."
  — Barry McCardle, [44:07]

7. Pricing, Value, and Product Positioning

[47:56 – 55:42]

• Hex purposely does not charge extra for AI features—such an "add-on" implies AI isn’t fundamental.

• Analogy: Charging for "Cloud" in 2014.

• Consumption-based pricing or seat-based pricing will likely evolve as usage and cost patterns shift, especially as token/inference costs change and application/infrastructure lines blur.

  "It's very important to me that the AI capabilities come baked in with the core thing you're buying." — Barry McCardle, [50:58]

8. The (Post)Modern Data Stack and Industry Consolidation

[56:15 – 63:41]

• The "modern data stack" (cloud warehouses, ETL, transformations) has become standard.

• Consolidation is natural: With 5tran and dbt merging, Barry envisions the "postmodern data stack"—more modular, open file formats (like Iceberg), and sovereignty over raw storage.

• Massive query volume by AI agents will make cost optimization and architecture choices critical for organizations.

  "It's not the modern data stack anymore. It's just the data stack, like it just won."
  — Barry McCardle, [58:20]

9. M&A and Integrations (Hashboard Acquisition)

[63:41 – 65:28]

• Acquiring Hashboard (a BI tool) was motivated by a desire to own and accelerate the complete data insight layer—from exploration to analysis to sharing.
• Successful M&A is driven by cultural fit, aligned vision, and providing teams with bigger problems/resources.

10. Company Building Culture: Lessons from Palantir, Social Media, and Brand

[65:54 – 81:48]

• Barry’s “sparkling sales, not forward deployed” Palantir tweet [66:31] underscores the misuse of terminology and the cultural lessons of deploying engineers truly close to customer problems.

  • True “forward deployed engineering” revolves around radical “problem proximity” and cycles of innovation that feed back to central teams.
  • Lesson for founders: Adopt "commitment engineering"—seeking incremental customer buy-in before and during product development, not just aiming for one-off sales.

• On brand and marketing:

  • Hex launch videos reflect intentional, offbeat, and human brand-building.

  • Embracing fun and creativity is both memorable and impactful, even in an enterprise setting:

    "I think we've always just tried to have fun. That's kind of underrated… Enterprise people are still people. They find this shit boring."
    — Barry McCardle, [78:39]

---

Notable Quotes & Memorable Moments

• On the end of data gatekeeping:

  "Dashboards raise more questions than they answer for sure."
  — Barry McCardle, [02:43]

• On the evolution of the data team:

  "We're going to see data teams understand their jobs more and more as this sort of context engineering. I think that's really exciting."
  — Barry McCardle, [31:34]

• On accuracy vs. trustworthiness:

  "Maybe that sounds a little obtuse, but just to give you an example, like if I'm like, how many widgets did we sell last month? … But why did we sell that many widgets? Well that starts to get harder… The word we use is trustworthy."
  — Barry McCardle, [34:41]

• On building natively with AI:

  "As much as anything, it was signaling internally that this is really the future of the company... Every PM, every designer, every engineer is expected to have full awareness and fluency with these things."
  — Barry McCardle, [42:17]

• On product evolution:

  "It's just hard to imagine Hex without it now. Like, I don't want to use my own product if I can't use the AI features because they become so good."
  — Barry McCardle, [45:10]

• On SaaS marketing and having fun:

  "I think that's kind of underrated. SaaS marketing for a long time, it was just goddamn boring… I think the fact that we have passion for what we're building and that we have a creative and weird team… makes us stand out."
  — Barry McCardle, [78:39]

---

Timestamps for Important Segments

| Timestamp | Topic / Segment | |-------------|-----------------------------------------------------------------------------------------------| | 02:21–04:01 | Why data democratization hasn't materialized and how AI makes a difference | | 07:20–08:17 | Time to insight, negative latency, and ambient analytics | | 10:11–13:17 | Hex Threads, Notebook Agent, AI-powered UX evolution | | 16:12–20:14 | Model advances, agentic reasoning, context scale challenges | | 22:53–29:31 | Semantic modeling, context layers, and evolving data team roles | | 31:34–36:28 | Redefining accuracy, trust, and what makes an answer trustworthy | | 38:46–45:21 | Killing the AI team: Organizational implications of making AI native and intrinsic | | 47:56–55:42 | Pricing, value capture, and strategic decisions in having AI as "core" vs. "add-on" | | 56:15–63:41 | Modern → postmodern data stack, industry consolidation, post-warehouse architectures | | 65:54–72:51 | Palantir, "sparkling sales" joke, commitment engineering, culture lessons for founders | | 78:25–81:48 | Brand, launch videos, embracing the weird, brand as a differentiating factor |

---

Final Thoughts

Barry McCardle paints a vision of a near future where AI is not just boosting productivity but fundamentally changing who can work with data and how. The end of data gatekeeping means not merely access to dashboards, but true organization-wide analysis and insight. This requires far more than clever UIs or upgraded LLMs—it demands robust context engineering, thoughtful governance, and a commitment to trust over abstract measures of accuracy. Hex, as described here, is chasing that vision holistically—from product to team structure to brand culture.

---

For further exploration:

• Barry McCardle’s blog: barry.ooo
• Hex official site
• More AI + a16z episodes on YouTube, Apple Podcasts, and Spotify

(All quotes and attributions by timestamp are from Barry McCardle unless otherwise noted.)

Transcript

[A]

The fastest way to really annoy a lot of people is to have a system that's giving them consistently wrong answers. I think that the percentage of actual decisions that are made every day that are informed by data is really, really low. As sexy and cool as the things like the notebook agent and threads are, the thing I wind up gravitating to is actually the things we're doing around context management and observability and governance, because that's the stuff that are going to make those answers trustworthy. Hollinger has generated a lot of successful founders because it is selected for and then cultivated people who are really interested in. I'm just going to go out, find a problem and run like hell and figure out how to solve it. Whenever you have these technical shifts that sort of settle in, you're just going to have a consolidation. There's going to be a few sets of people who really are able to win and accrue a lot of value, and then other people who will get acquired or pivot or figure other things out.

[B]

Dashboards became the center of data work, but they rarely delivered real answers. For two decades, companies have relied on the same basic workflow to understand their data open a dashboard, drill into metrics, export information, and share it across teams. AI introduces a different approach. It interprets context, applies reasoning steps, and generates insights without depending on manual navigation or predefined dashboards. Barry McCardle is working at the center of this shift. He's the co founder and CEO of Hex, a platform designed to make AI an analytical partner rather than an add on to existing BI tools. In this conversation with a16Z general partner Sarah Wang, Barry explains how data teams are evolving into context engineers, how agentive workflows are reshaping analysis, and why time to insight may soon move faster than the questions themselves. They explore why dashboards are becoming less central, how semantic context improves trust in AI systems, and why the structure around the model matters more than the model alone. Hope you enjoy.

[C]

Barry, thanks for being here today.

[A]

Yeah, thanks for having me.

[C]

Awesome to have you here. So I wanted to kick off on a meaty topic. You talk to a lot of different data teams at different enterprises, and Hex is obviously a leader in the data space. The application of AI to data feels like the Holy Grail.

[A]

Yes.

[C]

Can you say a little bit more just to kick off on how you think AI is going to change the data space?

[A]

Totally. So it's interesting when you talk to people at enterprises, organizations, companies of any size. The last 20 years has really Been chasing this promise of like data democratization that's been. I was in the analytics software space like 10 years ago, and data democratization was like the buzzword everyone was saying.

[C]

Totally.

[A]

But it's not really happened. The last 10 years, the big change has been it's been easier than ever to bring all your data together. You have the cloud data warehouse, you had technologies like 5chan and DBT. So now we can like get all of this data and then it's. What are we doing with that? We're still just putting dashboards on top. Like, dashboards are really good for what happened and sort of like KPI trends. I love a good dashboard, but dashboards raise more questions than they answer for sure. And so there's always this dream of like, well, wouldn't it be great if everyone in the organization could use data to ask and answer questions? I think that the percentage of actual decisions that are made every day that are actually informed by data is really, really low. Like if you think about all of the different things that you could better inform with data and then the number of people that go through the whole workflow of, well, let me open my BI tool and find the dashboard and then find the right data and drill down and do all the different things, it's very hard. And so obviously with AI, it's like the appeal of just being able to ask a question in natural language and get answer. It's so obviously exciting. And in fact there's been like demos and concepts and like promises of this, well, predating LLMs. And so now with these AI technologies that are really working, we do have this potential. And now a reality that we're starting to bring to bear of a world where everyone in an organization can ask and answer questions with data. And it's just enormously exciting.

[C]

Yeah, absolutely. Although to the point that we kicked off with that, this is the holy grail and it feels like it's becoming achievable. What historically have been the blockers, what are they today? And how is Hex helping your users overcome them?

[A]

Yeah, well, I mean, historically the blocker, pre AI, the blocker, and going back in time a little bit, we built Hex to solve a lot of the data problems we had felt as builders and users of data tools. Like, I've spent my entire career building and using data tooling and was painfully, personally aware of all the problems and gaps and issues and all the things that maybe more traditional BI tools and dashboards weren't solving. And one of the big things that we had Focused on early on was this ability to go much deeper into questions. So like a traditional dashboard, you know, they show you a KPI, it'll show you sort of a one dimensional thing. But if you want to start going and asking like, well why? Why did that happen and what else was happening and what does that suggest about what's happening next? You'd wind up in this toolkit that was super fragmented, very messy. You're writing a SQL query here, you're downloading the results to a CSV, you're putting it in a jupyter notebook. None of these things are built to be collaborative. So you're trying to send these files around and you're like sharing with a screenshot of a chart, put in a PDF of a deck, sent in an email. This is like super painful, insane workflow. And so we started Hex to really solve that. And then if you think about all of the work that goes into doing that, even in something like Hex, which we made much better, there's still just a lot of steps to go and find the right data and get the right view on it and build a chart and get all the settings just the way you want and explore different paths and pathways. And with AI now you can have a partner that basically makes that whole process much, much faster. And the interesting transition that's happened in the last couple years was going from this conception of, well, hey, we could just do text to SQL to a much richer and deeper sense of what these systems are going to be able to do for us. And I think we're already seeing this now, but it'll just become more and more apparent. There's kind of three dimensions to this. There's going to be breadth, which is you're just going to have way more people in the organization be able to ask and answer data questions because that friction and that activation energy goes down so much. Like the ease of opening up Hex or opening up, we have a Slack button. I can just go into Slack and ask a question. It's just like a hundred, a thousand times easier than going and navigating virtual and doing all the clicking. So you're just going to have way more people that are able to ask these questions and then they're going to be able to go much deeper. I think the cartoon version of it is like these one off trivia things like how many widgets did we sell last quarter? That's good information to have. Often you want to know how many widgets you sold last quarter, but once you have that Information humans typically, we're very curious animals. We want to know the next things. Yeah, we want to know, well, in which different categories and which salesperson was driving that, what channel were they getting that from and what were the factors driving that and what have been other quarters that we've seen a similar pattern. And there's all these follow up questions you have about that widget number and so depth is a huge deal and I think maybe underappreciated way in which AI is going to really change the way people are using data. And then speed, which I think time to insight is a thing you talk a lot about in the analytics world. How long it takes for people to actually get something. We always thought prehex it was just this insane process as I outlined, trying to get answers. We collapse that down and collapse that down even further with AI where we can have an AI agent partner with you to go find those answers really quickly. But I'm interested in a world where that time to insight actually goes negative. Where yeah, we start to learn more, as we learn, start to learn more about organizations and teams and individuals and what they're interested in and what they're curious about and what matters to them. We can go and actually surface things to you before you know, you're thinking to ask about them. And not only surface something like, hey, this metric is deviating. We can attach an analysis as to why that might be and suggest some follow up questions and bring that to you in a notification that you can have a whole interaction with without having to go through a really complex workflow. And that future, you know, we think of it as sort of ambient analytics future that is extremely compelling and just very, very different from the way people, I think, had conceived of what data tools or dashboarding products could or should be not that long ago.

[C]

Yeah, ambient analytics, I like that. Coined here by Barry McArdle. Side note, I'm very excited for a 16Z to roll out the Hex Slack bot. That's what we need.

[A]

Yeah, you guys are actually great hex users.

[C]

Yes, we are.

[A]

Very, very. Ironically, it took a little while for you guys to get all the AI security and data access stuff.

[C]

It's ironic.

[A]

Which I guess, I guess makes sense. You are. In some ways you guys are a very good example of a complex financial services firm. You have a lot of sensitive data and you really care about it. And I do think that actually is, jokes aside, really exemplary of what we're seeing in the market, which is like every enterprise in the world, especially those with a Lot of data like A16Z and many, many other enterprises. The appeal of being able to use AI to analyze data is so obvious and so compelling and it's finally working. And I think there's an activation and sort of a deployment cycle we're going through, but that's happening so quickly now. I'm very pleasantly surprised. We walk into these really large organizations, really large enterprises, and the cycle of us having an initial conversation to them, wanting to do a pilot to them buying the product is extremely quick. Wow. Compared to what it was before because I think the value is just so obvious to people.

[C]

Yeah, well I actually maybe related to that, but I wanted to pull on the thread and this is pun intended of the, the changing UI around how we explore data. Right. And the reason the pun is intended is you guys obviously released a product called Threads. And you know, I loved your point that the first iteration of a lot of AI is applied to data analysis was really text to SQL. Right. There were a bajillion of these startups that popped up. But you know, as you think about time to value shortening and like you know, even going negative, to borrow from you, I think Threads is a pretty big product along this journey for the user. So maybe share a little bit more about first of all, what Threads is for everyone who hasn't used it, but how you think about that evolution of getting the user closer to bringing in data, to actually making decisions.

[A]

Totally. So Threads is a conversational self serve product surface area in our platform where you can come in, it's sort of very legibly chat, something very approachable, users can ask and answer questions and they're tapping into all of the power of Hex now behind the scenes it is leveraging the whole platform we built and you know, going back a little bit. I think in the first leg of the journey for hacs, we were mostly thought of as a super powerful, very capable data tool for more sophisticated, more technical users. A lot of people think of HACS as like a notebook built for data scientists and data analysts. And over time we've done a lot of other things. But actually those routes are extremely helpful for us because agents.

The way our product is architected, sort of like just being in the right place at the right time kind of thing. Works really well for agents. If you imagine those of you who haven't seen it, anyone listening hasn't seen it. Like the Hex core product.

It has this sort of notebook paradigm where it's very iterative. You know, you have like a SQL query and the results of that can go into a chart and you can visually filter that chart, and the results of that can go into a Python cell, which can go back into SQL and it's, it can sort of chain together. And this is a pattern that works really well for AI agents, where it can do a step, it can look at the results, it can reason about what to do next. And we've been able to bring. It's why part of one of the reasons, we've been able to bring AI into the product in a way that's really compelling. And we first did that with the Notebook Agent over the summer, where we did that targeting maybe those more technical users that are maybe comfortable with SQL or Python, but that we built it in a way that was very purposeful, where it's a framework that now we're able to expose to lots more people. And so Threads is that Threads takes the same underlying framework, using all of the tools and all of the power of the platform and bringing it to a much wider audience in a way that is governed and built for trust. And so as an example, like if you have a data scientist using Hex, Hex is going to be able to use sort of any of the data in your data warehouse and it'll be able to write arbitrary Python and do a lot of really complex things. If there's a user using Threads, it's going to be much more constrained where it's only going to use like endorsed or model data or, you know, it's not going to go and write a bunch of arbitrary Python code that you're not going to understand. And that.

Experience is very approachable but also very powerful. And.

We can expose that both through our ui, but also we're bringing that to other places now. So we have a Slackbot, as you mentioned, which is really cool. Like, I can. That's the way it's almost become. The primary way I'm using Hex day to day is like, I'll do a lot on my phone, which is like, ask Hex, ask a question. And I can have a whole conversation with the product that way. And then we, we have an MCP server and we're going to announce integrations with other tools over time, where, you know, we want anywhere where you have a data question to be able to tap into all the power of our platform and all the context, we have to be able to answer it really well.

[C]

Yeah, interesting. I love that you brought up the Notebook Agent from over the summer. What did you learn from building the Notebook Agent that You applied to threads. And why do you think now is the right time for a conversational interface?

[A]

You learned a lot building on Notebook Agent and going even further back. We had actually first tried to build, I think what now you describe is an agentic analysis system two years earlier. So it was the summer of 2023. I wrote a feature spec that was called chained analysis and the whole idea was.

It was sort of agents before agents and it was way too early. The models were not ready for this. But we spent the better part of a year kind of banging our head against the wall trying to get it to work, trying to get it where you could have a user prompt and the system could go and sort of step wise do an analysis path for you.

And again, the models just weren't ready for that. Our ability to wield them wasn't there. There was a lot of infrastructural stuff we had to get right and two years later it was finally possible. And so the, the Notebook Agent was the result of a lot of lessons we learned over that whole time, but also just.

The new model capabilities, whether it's tool calling, reasoning.

The way you end up structuring your context now getting into things like sub agents for doing data discovery. There's just a lot of these pieces that we had to really iterate on to get the notebook agent feeling really good. And the experience is legibly, people call it cursor for data where it's like you already have this really powerful environment hex to do data work and now there's this agent assistant that is aware of the whole project. It's aware of the relationship between all the different analytical steps. It can view the outputs of charts, it can view the outputs of queries, it can reason about the relationships between these things. We are exposing even more information like how long queries taking to execute and past queries that look like this.

And now we can, you know, again it's, it's basically, it was very easy in a way for us to build threads because it's just the same underlying agent with a, with a simpler, more focused and constrained ui. And, and what's really cool about this is we make one, one of those surfaces better, the other one gets better as well. Yeah, like we think of it as one core agent layer we're building with these different consumption surfaces on top, not completely discrete products.

[C]

Yeah, I, I love that you brought up the. Just sort of being ahead of the pack, but then waiting for the model capabilities to evolve. And I was going to ask you what evolved to enable this. But just maybe on that topic, I guess of the list that you mentioned, what was the biggest thing that you think led to a step change improvement. And in terms of what still needs to improve, what would you like to see come out of the models that would, I think fit your hex's roadmap?

[A]

Well.

The biggest thing that happened, and it happened sort of late last year and then with successive steps got better and better, were the generation of models that we're able to do these sort of agentic reasoning steps. So there was the O series of models from OpenAI and then you had the Claude 3.537445 now series of models that have come from Anthropic that have sort of embedded that thinking capability. There's open source models of course that have, yeah, have done this. And that revolution over the last year has really, it's almost, you know, building products with these tools. It's almost feels like this discrete.

Generation of like people, people think about LLMs. It almost feels slightly discontinuous just in terms of like how capable and the types of things you can build with these. There was like a generation of products you could build that were very one shot.

[C]

Yeah, totally.

[A]

Hey, write me some Python to do this. And it would just write you that Python. But now having models that can reason and iterate and loop and you can give them dozens of turns to go and think about what they're doing. I mean it's a whole new thing. And so that's what's unlocked, you know, AI coding with products like Cursor, it's what's unlocked a lot of the AI customer success, things like Decagon and Sierra. And now that's coming to data. And so applying that to data is actually, there's a lot of specific challenges.

To that, including like one example, we, we actually have a bunch of blog posts about this from research we've done. We're just sharing this openly. Like as one example, the context volume in data is very, very large. Like you think in coding, you know, there's, there's a really large code base. But any, any given step in, in sort of coding you can, you should sort of have the text of the file you're working on and then you know, the agent could go and grep other text files. In analytics you have things that you might want to put in context that are hundreds of thousands of tokens because they're a result set of a query.

[C]

Right? Yeah.

[A]

Or you know, how you represent charts is actually really interesting like if you, how do you encode that image in a way that the agent is going to understand and you're not going to blow up your context window. So there's just a lot of very specific challenges. And so we spend a lot of time with our partners, Anthropic and OpenAI, which are both model as we use in our product.

Trying to help them understand these challenges and influence maybe some of the things that they're doing where we, you know, we, we want to be able to see both. And it's a little bit contradictory. Maybe we want to see higher speed because there is a time sensitivity when you're watching a thing reason that we, we just want to be able to have lower and lower wall clock time for users to be able to go from the question and curiosity to get the answer.

[C]

Yeah.

[A]

But also to be able to have larger context windows and more tools and capabilities for us to do context management because of the unique challenges in analytics when it comes to the volume of information you might be trying to expose to a model. Yeah.

[C]

On that note, I mean, you might be uniquely positioned to answer this honestly. So Gemini 3.0 just dropped today. They all have their leaderboards, evals that they put out there, but do you have, I guess, do you think that they're truly differentiated on any important vectors when it comes to data analysis?

[A]

We, we see them being quite differentiated. You know, we, we run all, every model that comes out. We run our evals. We have very rigorous internal evals. As it turns out, the, the open source evals are not good. Yeah. And that's no disrespect to the people building those. Actually there's a lot of smart folks who have worked on these benchmark sites, but we have a unique purview where we work with 1700 customers.

[C]

Yeah, exactly.

[A]

And growing, including some of the leading companies involving anthropic uses. Us cursory uses.

[C]

Right, right.

[A]

You know, there's these really large and very leading edge companies who use this. And so we get to see the real world examples of how people are trying to apply AI to data. So our ability to build evals and understand what is actually useful in these contexts is pretty unparalleled.

And so we are able to benchmark all of these against pretty rigorous understanding of how people really do data analysis in the real world. And there are real differences in how these models work, how they operate.

When and how they will take a new turn on something, when they'll come back to a user for extra thing, for extra context, when they'll do tool calling. How they do tool calling, the ability to factor out things like subagents. There are certain models that are way ahead on these. And one of the things Juicy you mentioned, Gemini, one of the really interesting things I thought was they're, you know, they released the nice model card. It's always the same, right? The new model that they release on the far left, the numbers in bold and all their competitors. And one of the interesting things though was that Claude was still out ahead on coding.

[C]

Yep, saw that. Sweet bench.

[A]

Sweetbench. That's right. So why is that? Well, first, is that interesting for us? Yes, Hex does, in, in the course of doing these, our agent doing these analysis paths, it will write SQL and write Python. So the ability to write code well and reason about it is really important. But I think it's a very interesting question, why is Anthropic still out ahead on that? And I think it's very interesting to observe the data flywheel they built. You know, they made a bet, made a bet on getting out ahead on coding. And their Claude very quickly became known as the model that was the most capable at these software development tasks. And that meant people started using Cursor with Claude. Yep. And it started, I mean, they were able to go build a great product in Claude code. And now they have a data flywheel where they have a lot of people passing a lot of tokens through and a lot of people building coding use cases on top of their platform that they're able to just get better and better and better. And if you look at Google, you know, they've got their internal developer community, but no shade to Google, they're still, I think they would admit, much more nascent in terms of having a lot of external developers relying on Gemini to do their software development work. And so I think it's a really interesting example of where these data flywheels and token farming flywheels can emerge. And it'll be interesting to see can other people catch up. Once you've sort of created a flywheel like that.

[C]

It will be very interesting to see that, I guess maybe bringing it back to capabilities that models have unlocked. For Hex, we've talked about Notebook Agent, you've also added semantic modeling agents. And I wanted to understand a little bit better, how do you think the semantic layer changes in the world of AI and the role of the semantic layer, et cetera.

[A]

So zooming out for a moment, AI has been able to generate SQL for a little while.

And in fact, it was funny when people first saw ChatGPT, it was like on everyone's top 10 list of potential use cases, it was like writing blogs, it was medical advice. It was like these obvious use cases, one of them writing code, one of them. Everyone was like, oh, this can write SQL. Oh great, this will do all our analytics for us, right? And lo, there was like 100 startups doing AI for data chat and unfortunately a lot of them already gone through a full life cycle, let's say, because they found is it's very hard to do this accurately. Writing syntactically correct SQL was simple enough.

And it was pretty quickly the models got pretty good at that. Writing semantically correct SQL I. E. SQL that is going to queries that are going to represent the correct way to understand and think about the world is much harder.

And so obviously, as in many domains with AI, the context you give the model is really, really important.

And ultimately, actually I think the thing that makes great AI products is not just the ui which is important, or using a bleeding edge model, which is important, but it's how you are doing the context engineering for that. And so in analytics in particular, there's a few different ways to think about giving context to models. One of them is what you mentioned is called a semantic model. Semantic model is kind of a maybe fancy term, people haven't heard it. We think of it really just as like instructions for use for a database. So you have a database, you have tables and columns, you have the names of the tables and columns, but you don't really know what they mean or their relationships to each other. And if you have a really simple database, maybe you're able to reason about it. And we do have customers that have simple enough database structures where our agent can actually now do a really good job reasoning about how to use it. And that works fine. But for most complex organizations with real world databases, they've got, it's messy, they've got a lot going on and a lot of sort of encoded business logic that needs to live somewhere on how to reason about the relationship between all these different entities. So that's where a semantic model comes in. And you know, there's a lot of different people that have tried to do and are trying to do a lot of different things around semantic models. We're actually pretty agnostic where someone wants to manage that information. Like if you're building your semantic model in dbt, that's great, we can import that and adjust that. And we want people to be able to use that context in hex. But we did build another agent in the product to be able to help create semantic models.

Which is great, but we see that as just one step in a sort of a bigger.

Job to be done. And context feedback loop. I actually think that as sexy and cool as the things like the notebook agent and threads are, where, you know, you can type a natural language question and get this data answer back and it's really cool and everyone's like, that's the holy grail. That's really great. I love showing it off. When I'm demoing to real data people, the thing I wind up gravitating to and showing them is actually the things we're doing around context management and observability and governance, because that's the stuff that are going to make those answers trustworthy.

[C]

Right?

[A]

The fastest way to.

Really annoy a lot of people is to have a system that's giving them consistently wrong answers. And so we're really interested in, and we're spending a lot of time focused on toolkits and workflows and capabilities to allow people to see what are the questions people are asking, are they getting good answers and how could those answers be improved? And there's a lot of really nice UI things and cool things we're doing, but there's also some really cool applications of agents to this. So, like, we now have this online eval system where every time someone asks a question in threads, we have another agent that reviews the thread, love it, and says, was this a good answer? Right? And we can look at a lot of different things. So we can look at, did the user appear to be satisfied with the answer? Did they give negative feedback? Did they appear to be annoyed? We can inspect the actual thinking tokens from the model and we have what we call the confusometer, which is very technical term.

Our AI research team came up with that. So they're very smart. But it's like the confusion meter versus like, how confused did the agent appear to be as it was conducting this? Because you can literally see on the thinking tokens, if you've ever looked at the thinking traces of one of these models, it'll sometimes be like, wait, no, that's not the right way to look at this. Okay, let me look at this. Well, that still doesn't make sense. And even if at the end to give you some answer.

That the sort of verbose confusion we found to be very correlated with maybe something that's not going to be a great answer to that question. And so anyway, we take all of these different factors and can look at that. We want to provide all of that as information back to someone on a data team for them to be able to say.

Where are people getting good or bad answers? What topics do we do? Topic classification. You know, I see a lot of people are asking questions about revenue attainment, but they're getting generally bad or confusing answers. And then, oh, that's because we don't have the right context there.

[C]

Yeah, interesting.

[A]

Or people are getting two different types of answers in this domain. We should probably go and build the context to be able to steer the agent toward one of those answers or the other. That workflow I think is incredibly super important. And there's this really great compounding effect that we're seeing our customers develop. I just saw a quote from a customer earlier today who was like, I'm in the Context studio, which is what we call this UI every day because they've now deployed threads out to everyone in their organization and their job is now like, great, I need to help understand how I can make all the answers. They're getting better and better. Which bringing a full circle was really the thing that a lot of data people always thought they were doing or like always wanted to do. Right.

[C]

Right.

[A]

People use DBT pre AI. Right. People use things like DBT to try to structure tables in a way so that people could go and find them using the BI tool and click around them and get good answers.

[C]

Yep.

[A]

Well, now the way that people get those answers is way better. And we think that the way that people are going to be able to engineer that context and help guide and improve and partner with people to get those great answers is going to be way better too. And so that all comes together and semantic models are one tool. But we're really interested in can we be surfacing those things to data teams and saying, here's a suggestion of something you could add to a semantic model based on what we're seeing and different questions people are answering or asking and the answers are getting and accelerate that flywheel. We think that's a huge opportunity.

[C]

Are data teams the ones who are doing a lot of the AI governing from that perspective now is interesting.

[A]

Yes. And I think that there's interesting. I think that is a big part of the future of a role of a data team.

We have an amazing data team at Hex. I love them.

[C]

Including On Brand. On brand.

[A]

Well, it is, it is. And one of our, our head of data actually was a used to be a customer and she came over because she was like, I want to work somewhere that I'm going to help define the future of Minecraft. And so our data team, I like to joke, is a little over provisioned. They would disagree. I think they were like you need more people. But I, I, we part, we, we, we, we have a great team and, and part of the reason we've invested so much in that team and we, we love them so much is because they, you know, they're their gates of dog food and um, they, they're, they're, it's a great role because you're great, great place to be on the data team because you get early access to all these great new features. It's also sometimes annoying place to be on a data team because you're dogfooding all these very early things. But watching the way that their job has evolved has been very interesting. We rolled out the notebook agent and threads obviously before we rolled out to anyone else internally and now they're busier than ever which is great. They're spending a lot of their time doing deep dive analyses that they didn't have time to get to before because they were getting bombarded by one off questions that now could be answered by threads which is great but they also, a big part of their role is sort of this compounding virtuous cycle of what are all the questions people are asking? How can we make sure that they're getting good answers and canonize that context in a way that can happen at scale. One of one of the people on Idea team she's like I want to feel like I'm like a spider on a web and like when there's like a question or like a new topic that's popping up in the org, I want to be able to get an early detection of that and make sure we're there to make sure we're bringing the right data to that new thing. And so that's I think an evolving part of the role and we're going to see data teams understand their jobs more and more as this sort of context engineering. I think that's really exciting.

[C]

Yeah, I, I actually love hearing you walk through all of these measures or guardrails, whatever term you want to use on ensuring you're actually getting the correct answer. If you were to put data analysis on a scale of Waymo being here, right. You make a mistake, someone dies. Just how important correctness is to mid journey maybe over here like you have a funny colored hat that's, that's kind of a feature, not a bug. Like where would data go on depends.

[A]

What Data you're analyzing. I've worked in domain. I've seen domains where hitting the wrong answer to a data question, someone could die. Right.

[C]

Fire the missile.

[A]

Yeah, well, I joke.

[C]

I know you still work on Palantir, so.

[A]

Right. But, but even, even outside of like spooky nat sex stuff right there, there, there are places like I also worked when I was a pounder, I worked in oil and gas and like, yeah, there are like real life and death decisions around or decisions that have really big impacts if you get something wrong when working in these domains. So jokes aside, there are places where data analysis really is mission critical. There are also places you could say, hey, it's a little more trivial or whatever.

[C]

Yeah, maybe the average take.

[A]

Right. But I think in any domain.

One thing we see a lot is people get fixated on an abstract concept of accuracy. I talked to a customer recently who was like, well what, what accuracy score is your guys think at? Because we've tried to do this internally and we were able to get it to 71% accurate. And there's another vendor who's telling me they're at 92% accurate. What's your number? And I'm like.

It'S kind of a, it's, I was like, you know, no, no offense, but it's kind of a nonsense question.

Why do I say that? Well, one is what are you evaluating that against? And going back, we have a very unique and very rigorous set of evals there.

[C]

Right.

[A]

That are different. The other thing with an agentix system is what, what do you even call accuracy? Maybe that sounds a little obtuse, but just to give you an example, like if I'm like, how many widgets did we sell last month? Okay. That's something we can really easily eval.

[C]

And be like, there's a right answer.

[A]

Yeah, there's a right answer. Okay, why did we sell that many widgets last month? Yeah, well that starts to get harder. And these are stochastic systems. They have a degree of randomness and now they're multi turn for sure. So each step has randomness. And so evaluating that is really tough. And I don't say that to dodge this question of accuracy. We, we think we have a very accurate system. We're very proud of it. We spend an enormous amount of time on how we can have our system be better and better at providing great answers. But the word we use is trustworthy. We want you to trust that. And that's more than just accuracy. Yeah. And if you even think about your relationship with like a Human analyst.

You have some prior on their accuracy. Like if you knew, like Susie, the analyst tended to not be very accurate in their work, you would feel like when you got a thing from Susie, you'd be like, well okay, double check that. Yeah, double check this. Right. But it's more than that, right? Because when you sit down with a really great analyst or data scientist partner, you know, they're, they're able to explain how they got to that, they're able to contextualize it for you. Right. There's a lot of other things that go into that and that, you know, that they're well managed by someone who's overlooking or maybe double checking their work and making sure their technology, their, their techniques are methodologically sound. So the point is there's a lot that goes into that. And.

So we think it's really important that people get good and accurate trustworthy answers whether they're working in something that's truly life or death or not. But the way to get there comes from both the context, but also building a system where people are able, the end user is able to understand how did it reach that answer?

The system is able to properly contextualize that answer for them. But then the data team behind it are able to observe and see and iterate and improve and evolve. Because I guess the point is there's no system in the world that's going to be like one shot, 100% accurate out of the box. And we think that this is over time, a very iterative process and a constantly evolving process of how you're going to have trust in data. And we're trying to build a system for that.

[C]

Yeah, no, completely. And I, you know, I think you brought this up earlier, but the fact that context matters too, right? Like what, what additional context can you bring and what is, how does that change the trustworthiness? Right. It's not a, you can't just rely on the model to get you an answer in your world. Right. And that's part of your moat of course as well, versus the labs doing data analysis and chat, gbt, etc.

[A]

But, well, which, which can work great for certain things. But we, you know, one of the big advantages we also have, and I know our customers really appreciate is like Hex is where they're, you know, we, we had, we had 1700 customers that are using the product and they're using it to do a lot of different things. But in all these places, Hex is where data analysis lives. It's where the results of these analyses live. And if you're asking a data question.

You know, maybe the best answer is one that already exists. Maybe it's an app or a dashboard that was already published that can give you the answer, or maybe you want to chat with that app or dashboard to go deeper on it. And that is really valuable context as well. And there's even a sort of meta context. There's the collaboration graph around that. Who published that app or dashboard? When was it last refreshed? Who else has been viewing it? What apps or dashboards have you been viewing? What questions have you been asking that we can then build some memory from and better understand the things that you're interested in or the way you want information presented to you? There's a lot there. And fundamentally we see our job as not just building great and beautiful UIs, which we're proud of, and not just building these cool agent features into them, but thinking about this whole thing as a system where we can help the data teams and all the people that are trying to support to help create this trust in data. Yeah. And I think, you know, obviously the whole company is just obsessed with this and we think there's a lot there. So.

[C]

Yeah, totally, I will. I actually, I want to switch gears a little bit, but it ties to this last point that you just made, which is, you know, this is a full system and you said something earlier in this session about being in the right place at the right time. So, you know, you were not founded in 2023 or Hex was not founded in 2023. 2024. Right, 2019. And so you'd done a lot of building pre the advent of LLMs. But, you know, I think one of the things that I admire most about you as a leader and Hex as a company is just how you have navigated and embraced this new wave of technology into the product and made it very native to Hex itself. But, you know, in a way that feels like a full loop, closed loop system. And so I wanted to talk maybe about the building piece of this because it is something that I think is in general hard to navigate for, for a lot of companies that maybe weren't born in 2023 or 2024. And you sort of famously, or, you know, maybe somewhat controversially put out this piece on how you guys got rid of your AI team earlier this year. But can you just say what you meant by that and how you've approached a pretty generational shift in how we think about technology?

[A]

Yeah, so we, you know, we, we did exist pre LLMs or at least pre. Pre ChatGPT. But we, we started playing with alarms. I remember I had Access to the beta.OpenAI.com I think whole interface where they had a little playground and you could play with. GPT3, I think was the DaVinci model. It was really great. And I was kind of showing it to people as almost like a party trick. Like. Like the interface kind of sucked. It was like free chat, but. But look, you can like type this and do completions. And it was like I was just kind of got obsessed with it.

[C]

I remember this, by the way, because I was at the Hex office. You were your old office and you were showing it like a party trick.

[A]

Yeah, right, I see that. I clearly showed it to a lot of people and I was just kind of obsessed with it and really interested in it. And we actually had a hack week in 22. I think it was our first hack week actually.

At that point we were really only in market selling the product or really a real. We really had PMF for a very short period of time. I remember I made one of our engineers, I totally forced him to do this integration with the OpenAI API to do SQL Gen. Everyone was like, oh, neat. And then we kind of moved on.

All this to say we were really early. And basically right after ChatGPT came out, I was like, okay, we gotta actually really make this much more of a priority. And we launched a first generation of our AI features just a couple months later. We called them Magic. It was a cool branding hexmagic. Our magic AI features, Magic Generate, Magic Edit, Magic charts. Really cool. And you know, this stuff was great. We hired like a magic team. We had like Magic Engine Lead and Magic PM and Magic engineers and like it had its own identity and almost like sub brand within the product. And I, to be fair, I think that made sense at the time because the technology was new, it was evolving quickly. I also think it was candidly, like too early to really have fully working in data. And so even it, you know, it made sense to almost have this be like a learning and research thing. Yeah. But earlier this year, I think it just became really clear that that was completely the wrong way to organize this. It became really clear that the agentic models were really working. It became really clear that this was going to be the future of the way.

It had been clear to us it was the future of the way these workflows should work for a while. But it was really clear that the future was now. And we had speculated in the past about A world where we get rid of the Magic team. But it always felt kind of far away because it was like, well, that'll be when models are really ready and we're really ready. And earlier this year, I was like, well, we're ready now. And so we. We dissolved our standalone AI team. And one of the analogies I used was like.

Sketch had a cloud team. And for those of you who remember Sketch, you'll appreciate this because. But maybe for those of you who have never heard of Sketch, it actually proves my point, which is Sketch was. Sketch was the de facto product design thing pre Figma. Like, if you were building products in the mid-2010s, you knew sketch. It was this beautiful, exquisite Mac app. Really lovely, very full featured. Everyone loved it. But it wasn't cloud native, it was local. And they had a cloud, but they had a cloud team. And it was always like.

Who'S doing cloud? Well, those folks over there, I think they sit up on three or something. I was like.

Figma never had a cloud team. Sigma was just cloud. It was just, there's the water they swam in. They had an infrastructure team that thought a lot about cloud infrastructure, but everyone else built on that as primitives. And I thought, you know, as a young company, we have a decision to make on which side of that line we want to be on. And.

As much, as much as anything, it was signaling internally that this is really the future of the company. So earlier this year, we dissolved the Magic team. We still have an AI platform team that works on sort of shared infrastructure around certain things. But from a feature and product perspective, every product team now is fully empowered to go work on these AI features. Every pm, every designer, every engineer is expected to have full awareness and fluency with these things. And this has just worked extremely well. Yeah, you know, and the thing we say internally is like, magic is dead. Long live Magic. Everything's magic now. And when I published the blog post about this, I think it was like a couple months ago now. I was a little apprehensive to publish it because even just in the six months since we had made that change, it had kind of just felt obvious that this was the thing to do. I was almost embarrassed that we had held on to a standalone AI team that long, but I was shocked at the number of people that came out of the woodwork, other founders texting me. I was at the A6 and Z event a few weeks ago and people were coming up to me and asking me about it. And so.

You know, if other people are Listening to this, I would really encourage you to think about that analogy. The different analogies to different things in the past. And where does it make sense to have a dedicated AI team versus where does it make sense to have every team be an AI team? And that doesn't mean that all they work on are AI features. That was one of the fears when we did this, was like, well, you know, we'll just never work on deterministic features again. Like, there's all these things that our users want today. Our teams actually do a really good job. But the point is that you manage it out of one.

Backlog and one queue. You want to work on some non AI thing because you think that's the next most important thing to build for our product. Great, go do it. But even the way we build those is different now because we have people thinking in terms of context and tools, because people have been exposed to this. When we build new features, people are actually thinking about, okay, well, how is the AI, how is it going to interact with this? How are we going to expose this to the agent? How is this going to show up in different surfaces? And it's a subtle thing, but I actually think that it's, it, it's like a compounding value to having the whole company sort of oriented around this.

[C]

No, I think that's why Hex feels like, I mean, you called it a system or a platform versus, you know, an existing product with AI bolted onto it. I think that's the key difference what you're talking about.

[A]

Yeah, which, which I think the first version of our magic features and even some things today still feel a little bolted on. Like if, you know, the, the example is, you know, the analogy to like cursor. The first time you use cursor, you're like, okay, well, this is just VS code with AI bolted on. But became more evident over time that what they had built was this sort of agent layer under and around the coding experience.

[C]

Right.

[A]

I think we've done something very similar with our own product with Data, where we now have this agent layer that is becoming more and more intrinsic to the way the whole product works. And.

I'll speak for myself and my team, and I know we hear this from a lot of our customers. Like, it's just hard to imagine hacks without it now. Like, I don't want to use my own product if I can't use the AI features because they become so good.

[C]

Yeah. And so much of the story and roadmap is still unwritten. I've heard you Say before that. Building with LLMs feels almost like research, not just product execution. Right. You're actually pushing the frontier on what can be done, how you do it, how your users will, you know, use your product, use AI, how do you plan around that now? And you know, maybe related to that, how do you guys think about what to, you know, build around versus optimize, versus wait for the model just to improve if there is something that you need it for the product, but it's not quite ready from a model capability.

[A]

It's a really tricky question and we've got, we've gotten this wrong plenty in the past. I think the first and most important thing for anyone building software today, which I say software in general because every software now has AI integrated in it well, is to really have a lot of intimacy and understanding with the model capabilities and deeply understand it. And the labs are moving very fast, pushing out new things. Every new release of Claude, every new release of GPT models, they've rled it to death with new things. And you can kind of see and extrapolate clearly they are trying to like they're really hammering. I feel bad for these poor models just getting like eaten to death with rl, like on certain tasks. And you can kind of look at that and almost extrapolate and say, okay, clearly this is a line that the labs are excited about. They think there's alpha, you know, that they're going to be able to descend some gradient here of new capability really well and you can kind of ride that horse a little bit. And so as we've really made this more central, like the thing we start to think a lot about is like, well, what are, what can we sort of infer both implicitly from what they're doing or explicitly through having great conversations with them and close partners of ours on where these things are going and where we should be investing. And that means things we want to build right now because it's going to be useful today. But hey, when this new capability drops, it's going to be even better or things we're like, hey.

It'D be a lot of engineering to build this today, but it'll be sort of more trivial once the model capability evolves. Yeah, like one example is like a sub agents pattern. It's like a thing that was like very hard to do before recently. Now the models are getting better at it, easier to build basic versions of it. There's still some things that don't work, but that's clearly a horse that people are riding and it's like, okay, we can go and mount that. And you know, we adopt an architecture. We know that it will just get better over time, almost for free. It's like just be on the tail end.

[C]

Yeah, yeah, totally. I guess on this topic, I think one of the other maybe initially contrarian things that you guys did and that you know, you've talked about in the past was you actually decided not to charge for your AI features. And you know, you're people, I remember.

[A]

Some investors and board members who questioned me quite a bit about that.

[C]

People on your board are like, are you an AI company if you don't have AI revenue?

[B]

Revenue.

[A]

Who would have done that though?

[C]

But, but of course, you know, your response I think was very prescient. We were like, are you an AI company if you don't have AI in your core product? And why would you charge extra for your core product? Right. But just say more about that thinking and you know, I think over time, right. That was over a year ago, maybe two years now.

[A]

It goes back exactly what I was saying about the, the way we structure the team and not having a discrete magic. It was like this is the pro. Having an AI add on suggests that there's a version of the product that you want to sell that doesn't have AI in it. And maybe that seems obvious today that that would be a thing but we just believe that as the capabilities get better you're just going to want synced and it's just going to be really obvious that this is the best way to accomplish these use cases. And again it connects back really directly to what I was saying earlier where it's like having it as an add on implies that that is some other thing that you offer and sell other than like being very intrinsic. And I always said like charging for AI in 2024 felt like charging for Cloud in 2014. It was like sure, you could have like there was probably a revenue grab to be had and I'm probably, there's probably a lot of SaaS companies that did. They're like, okay, we're going to have a cloud add on and we're going to go charge people extra for this cloud add on. Yeah. But to the extent there was revenue to be captured there, it was very short lived and my, my suspicion it was quite pyrrhic where like great cause congratulations, you went and got another 10% lift in revenue. But by doing that you kind of warped like there's a lot of like warped incentives around that. There's like you're kind of conditioning your customers that it's like a separate thing. You're telling your internal team that it's a separate thing. And so we were like, and, and this has gone. To be fair, I, I think I've been vindicated because I think this has gone out of vogue quite a bit. Like, like when I, when I wrote this blog and when we talked about it a couple Years ago, every SaaS company in the world was launching plank AI. Right. Slack had an AI add on notion had an AI add on. Loom had a good add on. These are really good companies and they saw the need to go and charge extra for this thing. Well, all of that has kind of been wound back and people are realizing, no, this is just the value of the product. Now the interesting thing is in the time sense.

Tokens have gotten way cheaper.

But we're using a lot more of them with these agent features. And so a thing that we're very open to and we actually have customers even asking us for in a very funny way is moving to like consumption where people are using a lot of these agent features. We're very open to that, I think, like, but it's very important to me that.

The AI capabilities come baked in with the core thing you're buying.

[C]

Yeah, right.

[A]

If you're using a ton of our agent things and it's costing us a bajillion dollars in inference, sure, we're, we think that's a very fair thing to go and charge you overages for that. And we'll probably do that eventually. Like most people are moving toward that.

[C]

Yeah.

[A]

But there's no separate AI add on. And I'm even kind of put down a mandate and an edict, like we just won't sell the product anymore to people who don't want the AI features turned on. And that's probably seven figures of revenue we'll walk away from in the short term. But I'm like, I just don't want new customers coming on board that aren't aligned, that aren't adopting these features and aren't aligned with where we're going. At very least I'd feel bad for them because they're have a bad experience, they're going to get a worse product. And a lot of the new things we're building are very AI centric. They're going to watch the feature releases and changelog come along and be missing out. And I'm like, I almost want to force people. If you want Hex, you have to fully adopt these things. It creates all the right Alignment and incentives. Even if we leave some short term cash on the table, it's fine.

[C]

Yeah, for sure. And I was going to ask how do you think companies should capture value in the case? Let's say AI becomes ambient, to borrow your phrase. It sounds like though you sort of answered that where you know, down the road usage based pricing. I mean we are seeing a lot of companies who started subscription add that obviously.

[A]

And so yeah, there's a lot of different things. I'm, I'm not the world expert on pricing. I do think like a very simpleton because I'm a simpleton so I need simple things. Framework that I've adopted in the past is like I think there's a distinction between apps and infrastructure and pricing generally. Like forget set AI side for a moment. Like you know you can kind of sort most enterprise software into apps or infra. If I you look at a database, it's very discernibly infra. If you look at something like Figma, it's very discernibly an app. Like what are these things sort of what discriminates them? Well in an app you have usually a rich ux. You have a concept of my stuff. Yeah, you.

It'S very sort of a personal thing that you're using and interacting with as an individual. And typically those are charged for by seats you look at infra. Infra is typically headless or like a very minimal ui. There's not a strong concept of my stuff. Like if you buy a database product it is unlikely to have like you know, a user. A strong sense of a user account. Yeah. Or artifacts you're generating. And that is typically, you know, they don't care if you're just using like a service account. Right. That typically charges on consumption. And my, my kind of mental model for this is like there's certain things that used to be apps or app type workflows that were very, the, the unit of value is like how many humans are using it that you almost can look at as a little bit more like infra now. So like a good example is like the customer service products that are. A lot of them are doing like outcome based pricing. My mental model for that is like that the, the customer service software space, you know, used to be per seat, per customer support agent and it was like seat based app software you sold well. Now you can kind of take that and turn it almost into infra. It's like now it's almost like more headless. It's like great, I'm going to buy this agent and it's going to go do support for me. And that kind of moves it from something that's strongly seat based to something that's more consumption in our world. I think there's still a lot of things that are strongly seat based where you have a concept of your stuff. In fact, I think the tam of the number of seats we can and should sell to our customers is larger than ever. If I can tell you, hey, I can make it so anyone in your organization can ask and answer a data question with very low activation energy, you're going to want to give that to a lot of people. I think what's interesting is you're going to see more variability in the intensity of use where you're going to see, yeah, not just the power users, you're going to see a long tail of maybe less frequent, intense users. Hopefully our features are so good that it makes them more frequent data users. But the question is like how you map price to value along that line. And I think there's a world where, even still as an app, even still as a company where we may keep seat based pricing as core, maybe you play with those levers a little bit and you have more of a consumption element for the people that are real power users to make it easier for more elastic for people to give more seats to lots more people. So I think it's a super interesting time on every dimension of software, including pricing. And I could go on about this for a long time, but right now our focus, I think we're like other companies and I mentioned Figma a couple times. I think they're taking basically the same approach. The focus is just build, let's just go build the world's best AI features in the space. We're going to keep running our core business the way we've been running our core business. And the cost of these things is moving around so much that we want to, we want to turn some more cards before we go into a lot of extra optimization on how we're charging or like how we're optimizing for margins and stuff like that.

[C]

Yeah, makes sense. That is one of my favorite delineations of usage based pricing and seat based pricing that I've heard though. So I think the simpletons approach works very effective. I want to turn over to some topics that are not gasp AI, but I think our, you know, we would be remiss not to talk about and get your views on. So if we think about the modern data stack and we rewind time, four years ago there was A chart, actually, that some of my partners, Matt, Jennifer, Martine did at the firm Flooded.

[A]

I remember this. I think there's a couple generations of different market. Generations.

[C]

Yeah, that's right. That's right. And of course, over the last four years or so, that's slimmed down pretty significantly. You know, you remain one of the leaders in that stack.

[A]

If you publish it again, there's just a few of those and they're all really big.

[C]

Exactly. Yeah, yeah, we did a V of that. But, you know, I think the big news from a few weeks ago is that two of the leaders on the modern data stack, 5tran and DVT, have since come together. Would love to get your view on that, what you think that means for the modern data stack and maybe the role that you see hex playing in it today versus, you know, four years ago.

[A]

Totally. I mean, the modern data stack was a term of our. There's a contested who first coined it. I think dbt. Tristan and DBT really popularized it among other people. But it was the way I thought about it was it was this new sort of architecture for data within organizations where the idea was just bring everything to the warehouse. And the core insight was you have cloud data warehouses now that storage is cheap and compute is really scalable. And in the old world, you had to be very judicious with how much data you were sending to the warehouse. You're doing etl, where you're trying to, like, only bring the data you really need because space was at a premium. Like, literally, people forget about this. But, like, you had physical servers you're running and like, you only had so much space now then you have things like Snowflake and Redshift and databricks and Athena and, you know, all these new architectures where it's effectively infinite storage and just you're only limited by how much you want to pay for it. And I unlock this new assumption, which is just bring all your data to the warehouse and make the warehouse really the center. This cloud data warehouse is the center of your analytic workflows. And that new sort of abstraction or focused abstraction, really unlocked a lot of new opportunities. So 5chan and DBT were both really built around that assumption of you're going to want a lot of people moving their data there and a lot of people transforming their data there. And by doing that in the cloud, there are sort of these new ways you could deliver that.

There was a lot of excitement around it. There's a lot of companies that got funded and started and grew and I think what wound up happening is like it won like people. I don't think it was the modern data stack anymore. It's just the data stack, like it just won. It's not some future thing. It's very rare. I go into an organization and they don't have some architecture like that. The largest enterprises we talk to, like really big international banks will still be like, oh well, we've still got some stuff on prem, but they're all trying to migrate it to the cloud or they're all moving in that direction. So I think whenever you have these technical shifts that sort of settle in, you're just going to have a consolidation. There's going to be a few sets of people who really are able to win and accrue a lot of value and then other people who will get acquired or pivot or figure other things out. And so it's pretty natural. And I think the 5 chain DBT thing to me is actually you can understand it in that context and you can be like, hey, this is just what happens when these markets mature. I think the other way to look at it is it's the first glimpse of what I now call the postmodern data stack.

[C]

Postmodern stack. Heard it here first.

[A]

Well, no other people have joked about it, but actually.

We'Re doing an event next month where the CEO of fivetran is actually going to give a talk about the postmodern data stack. So talk to him about this. But the postmoderner data stack, which I don't know if that name will really stick, but it's kind of saying, hey.

The way we were talking about this in the modern data stack era was that you're going to move all your data into a database. Like if I ask you where your data is, you might say it's in databricks, it's in Snowflake, it's in bigquery. Like, I've got my data, I'm going to give it to someone and they're going to have custody of it.

There's a new kind of way to think about this though, that's like, well, I'm going to have my data and I'm going to store it in a commodity storage like S3 that I have sovereignty over. And I'm going to store it in an open file format like Iceberg.

And what that allows you to do from architecture perspective is instead of being like, I'm going to give my data to a database, that company is effectively going to have custody over it. You say, no, I have custody of my data on my cloud account and I make query engines. I think of those data warehouses as query engines that then will compete or that I can use modularly to query that data in different places because I'm storing it in an open file format and I can just tell all those databases to point to that file. And this is where the revolution around iceberg is really starting. And I think it's just still very early. And if you back up, you have the data platforms, they all want to own and lock everything in themselves. They want to sell you everything around this. I think what's interesting with DBT and 5chan is their bet is by coming together, they're going to be able to make it so it's easier for companies to adopt this new architecture where if you can use 5chan to bring your data into S3 in iceberg format and then point your query engines at that, you're going to be able to use DBT to look at all the different places your data is going, how it's being transformed, be able to do cost optimization, be able to understand, hey, where could I move this to another query engine. And that package is an architecture customers are going to be able to adopt to effectively get leverage on the cloud platforms. The data platforms, which wind up with a very large. I mean, they have really good product margins. Like, you know, some of these are public companies. I won't name names, but one, you know, one of them, I think, last I looked, have like a 76% product margin because, right. For every dollar I give to this data warehouse company, $0.24 goes to, like, storage and compute and NETWORKING and like $0.76 goes to, like, I don't know, they're like sales team, private jets. I don't know, what do you spend that money on? And.

I think there's a big surplus there. And the reason I'm kind of amped about this touch of bring it back to AI is because I think that one thing we're going to see with agents and analytics is just a lot of queries. We see this already. We see this with our own warehouse bill. Internally, our agents will fire off a lot of queries, and it's not because they're doing wasteful or inefficient things. It's just like we can issue queries and do analyses faster than a human. We can do multiple things in parallel on that human's behalf. Naturally, you're just going to fire off a lot of queries and this is going to raise people's costs in query. Querying their data. And I think it's going to create a cost pressure that will need to be resolved because people, I think at the limit, you want to effectively be able to run infinite queries over your data, to constantly be looking at it on a user's behalf. Yeah. And so I am very interested in anything, any pattern that will wind up reducing that cost because it'll make our product better. Like, we want that to be cheap and easy and, and ubiquitous, you know, very easy for our customers to fire to, to feel very comfortable firing off a ton of queries because that'll allow us to deliver a really great experience. And I think the 5 train DBT combination, I don't know what they're going to call it. My proposal was Fishtran because DBT was originally founded as Fishtown analytics. And I was like, well, technically, you know, it's. It's Fishtown and fivetran coming together, so we'll see if that sticks. But hashtag Fishtran. I'm really excited about that idea because I think that's a bet on this new architecture that could really help people ultimately bring their costs of query down quite a bit, which is, I think, good for everyone, except maybe the cloud data warehouse monopolies.

[C]

Well, speaking of consolidation, Hex has also made some acquisitions and so I wanted to just bring up Hashboard quickly, maybe share a little bit more about the Hashboard acquisition. And was that a bet on owning the whole data insight layer? So if you think about all the way from exploration to analysis and sharing.

[A]

Yeah, yeah, you're right. We've been part of this. We're fortunate to have a business that's doing well and.

Hashboard, you know, I've known this, the CEO Carlos, who's great, who. He and I got to know each other in the early days of our companies and they did a really good job building a great BI tool that their customers really loved and in the course of doing that, had built a great team and learned a lot of things. And we started talking.

Just under a year ago about potentially working together. I think, I think one of the big theses there on both of our parts was like, clearly the AI elements of this were going to be so important. We had a team that had a lot of experience and maturity on that, and it was something that they sort of recognized as the future. And so it was a cool opportunity to be able to come together and take everything we'd both learned.

And yeah, it's a great example of you bring in people who have spent a lot of time thinking about a problem and really set them loose and give them more resources than they had before. And if you set it up right, you can get a ton out of it. So it's worked extremely well. Their team feels like very well integrated now and I'm very grateful to them for taking a bet. Joining us. And.

A lot of the stuff I was talking about earlier with Semantic Modeling, Context Studio, bunch of things we've done with Viz, there's all sorts of stuff that that team has really helped accelerate. And yeah.

You hear like these horror stories about M and A. So I was like, kind of nervous about it going in, but I was. I've. I'm glad to have bucked the trend.

[C]

Yeah, no, no, absolutely. I think, I think the. The foresight to. To join forces with them has accelerated all of these really exciting efforts that we've been talking about. On this pod. I want to. This is sort of a non sequitur, but I wanted to switch gears to.

To just maybe two top two topics that are seemingly unrelated, but they have to do with your presence on social media. So the first one is actually a tweet that you wrote. This was a few months ago about, you know, obviously you mentioned that you'd spent time at Palantir and it's sort of all the rage now to talk about hiring FD for deployed engineers. And you have this great tweet. Maybe I. I'll let you repeat it so I don't butcher it, but I, you know, I'd love for you to talk more about. You're like, hey, don't copy this model, but please share.

[A]

The tweet I wrote was kind of pithy and a little.

It's only forward deployed if it's from the Palanterie region of France. Otherwise it's just sparkling sales.

[C]

There you go. Yep, that's the one.

[A]

Okay, what do I mean by that? And I actually wrote a whole blog post on my blog, Barry. Ooo, if you want to go check it out, my personal blog about this because I wanted to expand on why I wrote a sort of truth within the joke.

Which is, yeah, there's a lot of people doing forward deployed engineering or thinking they're doing forward deployed engineering. And my goal with this was not to gatekeep that term.

Really, but to just help explain to people, like, to the extent you want to replicate some form of what Palantir did, well, you should really understand what it was. And it wasn't just having like solution engineers or sales engineers that they just called for deployed because it sounds sexy, which does sound sexy. It's cool. I mean if you want to, if you want to, if you want to call your, if you want to call your sales engineering team for deployed and that's cool, like no problem, go do it. But I don't think you should, like there's a kind of cargo culting version of it where it's like, therefore I will then have Palantir's level of success or I'll get the things, same things, right? What Palantir did well, really well, was send people out into the field to go build software. It was this radical deference to the people that were going to go literally get on planes and literally go to where the users were. Whether that was.

You know, anywhere in the world, including famously like war zones, but also, but also just like factory floors building planes or oil and gas fields. Like there was just all these places we set people to go and actually get really close to the problem. And the way most software companies work is they have all of their PMs and engineers and designers like sit in a, well, air conditioned office in San Francisco or Palo Alto over New York or wherever and like going and visiting the customer is almost like a very special, it's almost like a, you know, occasion, right? It's like how many times does the average software engineer go and like actually get in a customer's office? It's quite rare. Yeah, Palantir was very, very common. And it wasn't that we just had like solution engineers which, which, you know, it's common in sales to go visit a customer, but it's very rare if you're the one actually building the product. And as it turns out, if you take the people building the product and you go and you send them to where the problem is, you get them on a first name basis and you like, they really understand the problem, they see what the user's workflow, they see the resolution of their monitor and see that, you know, it's like these little things actually really matter to building great software.

That is a way that you can build these things. And what Palantir did really well, they had a bad rap for a while, we had a bad rap for a while of building custom software. And it's true for a while we were building a lot of one offs. But as we developed the Foundry platform when I was there in the mid 2010s, what wound up happening was this pattern where we had a core platform and then you had these FDE teams fan out to go to all these different customers, find a new problem that wasn't solved by the core platform, build a solution for it, and then the ones that worked would get pulled back into the core platform platform. So there was things for like real time, time series analysis and streaming. There was an incredible team that went out to a obscure part of the world and sat with these engineers that were trying to solve a problem that required that and built a solution for it that did not exist anywhere else in the company. And then it turned out that that was also going to be useful for another customer. Yeah, and then it turned out that that was going to be useful for another customer. And then piece by piece that becomes part of the core platform and, and those FTE teams are fanning out to find the next generation of problems. And so it's, you know, it's not just like, hey, we're going to come in and do like a six week implementation with you customer where we're going to like slightly customize the product and help you configure it, which I think is what a lot of people are calling fte. It's like we're actually going to take the, the real engineers really writing production code.

[C]

Yeah.

[A]

And go and put them out in the field. And that's just a very different pattern. And I've seen very few companies adopt that. And we're not even, to be clear, we're not even adopting it. I'm not elitist about it. Like we're build a SaaS product that we want lots and lots of people to buy and we have solution engineers who go and help them customize and customer engineers that support them. And we don't call anything at Hex for Deployed Engineering because we just have a different conception of what that is and what that means.

And I think it's a great pattern. I think you can be really successful doing it, but you need to really understand all of the benefits and all of the trade offs. If you're going to have all these teams in the field building things, you're going to have a lot of chaos and you have to be ready as an organization to say bring it. I thought it was such a cool thing. In retrospect. There were frustrating moments out of it. In retrospect I'm like, whoa. It's actually amazing that the leadership of the company was.

Not just tolerant, but like reveled in all these teams sometimes doing duplicative stuff. It was like product development by like Darwinian jungle combat sometimes where he's like, oh, like we're building this thing at this customer, but I heard this other team is also doing it. It's like, almost competitive. And it sounds like it'd be super dysfunctional. And in a way, it was because you wound up wasting a bunch of time.

[C]

Right, Right. It's like the ByteDance model.

[A]

Yeah, but. But what it did was actually, like, it was this amazing function of, like, you know, the search function. Basically. You had people out, like, probing and trying a lot of new things, and you sent these super smart people out in the field, discover the problem, go build something great. And the things that worked, really wound up working, and the things that didn't got thrown away. And in a way, it was almost this venture model.

[C]

Yeah.

[A]

I think this is why Palantir has generated a lot of successful founders, is because it is selected for and then cultivated people who are really interested in. I'm just gonna go out, find a problem and run like hell and figure out how to solve it, really understanding something. So.

That culture, I think, has served, obviously, Palantir very well. It's been a very successful company, really successful since I left.

[C]

So it's an indicator you set them up for success.

[A]

I was always the dumbest person in the room. But it's also created this amazing diaspora that's off doing really cool things, I think because of that culture and training. Even if they're not doing the FDE model.

[C]

Right, Right. Well, actually, you anticipate my next question, which is, you know, obviously Hex isn't. You're not sending your engineers to Moscow to build custom hexa apps.

[A]

I don't think Palantir ever sent anyone to Moscow.

[C]

All right.

[A]

Yeah, that would be the last. Well, among the last places I would expect Palantir people don't.

[C]

Wrong. Wrong country or wrong city to pick. Juneau, Alaska or something like that.

[A]

It was actually Anchorage and Deadhorse, the two places in Alaska.

[C]

There you go. All right. But. But I was curious what you took from there that you do have at Hex today. And it sounds like some of this is like, hey, go. Go find a problem. Figure out how to run at it.

[A]

Yeah, there's a concept. Another blog post I have. My blog is something I stole from or borrowed, adopted, embraced from other really smart people that I learned a lot from a Palantir is this concept of commitment engineering.

And it's a thing you do that with customers where you're. You're almost building with them. I think it's really common for early founders to be like, okay, I'm gonna go build My thing, I'm gonna go talk to customers, I'm gonna try to sell it to them, and, you know, they're gonna try to charge the money right away. But then we might have these design partners and the relationship is always really uncertain. And one of the things that's hard is, like.

You wind up building for a while in the dark before you actually get the sort of like, RL reward of, like, revenue, you know, like just AI Yeah. It's like you have a search and. And commitment. Engineering is this idea that we would do a lot of where we. We did a lot of pilots, a lot of free pilots, Palantir. And we kind of had to get really good at this thing, which is like, I'm going to go to a customer and I'm going to try to get them to make incremental commitments to me.

Even before they're like, paying for a thing. So as an example, it'd be like, hey, fascinating. I want to talk to you about a problem that you have. Will you take 30 minutes and chat with me about this problem? You're making a commitment to me. If you're willing to do that, yeah. You've expended. Maybe it's not money, but you've expended your time. It's valuable, right? And then I do this call with you and learn about your problem. I go visit you and I talk about this problem and I say, hey, you know, I want to come back in a couple weeks with a first prototype of something that'll solve that. If I come back with that, will you spend 45 minutes with me now? If you say, yeah, absolutely, it sounds great. Cool. We're onto something. Another commitment, right. I feel like, oh, in a couple weeks. Busy, you know, I'm so busy. And yeah, you know, I don't know if we will have time for that, but maybe send me, like a little thing about it. Maybe I'll look at it. Not so committed. That signal to you that you can. You can say is like, is this really right? Am I on the right track here? And you can just create these loops forever, right? I come demo this thing to you, I said, great, well, hey, I'm going to. Thanks for all the feedback. I'm going to go work on that. I'm going to come back in another couple weeks with the first version. I'd love for you to actually use it for real. Will you do that? Oh, yeah. Will you bring this to your team meeting and demo it a bit? Will you introduce. Introduce me to your boss? Will you Advocate for this to your boss. Will you give me a quote? Will you. Whatever. There's all these commitments you can have. The last one can be like, will you give me money? But if you've done those loops all the way is actually that last thing is like quite easy.

[C]

Yeah.

[A]

And this pattern works really well. And this is what I did with a lot of our early customers that, you know, we, we had a pretty good network in the data space and I would just go to them and ask for these commitments. Like, hey, can I come to you with the first version of this? Can I tell this to you? Would you, would you mind showing this to your team?

And you just get a lot of signal along the way. And I think some founders are even like subconsciously scared of that because they're afraid they're going to hear no, you know, you don't want to hear no, you want happiers. And it's very easy to hear if someone say, yeah, this is neat. Yeah, this is really neat. And be like, guys, I just came back from this meeting with the. They said it was neat. Let's go full speed. I think that's a way of startup waste a lot of time. Most startups find themselves in some version of that. And if you force yourself to like work on these commitments with people, I think you, you, it's a way to seek truth and really understand are you on the right path. So we had to do that a lot there. And I think every company can learn from that. Even if you're not doing forward deployed engineering or whatever.

[C]

I love that commitment engineering. I'm gonna go back and read that blog on it. Okay, so last question. It's kind of a fun one, but at the same time, you know, of course it's in the zeitgeist today, which is around launch videos. So I love Hex launch videos. Like literally, I'll sometimes watch them late at night and I'm like laughing and my husband walks to my office like, what are you laughing about? I'm like, hex, product launch video, right? Like, you know, your threads. One, you're like joking about Dune in the beginning. And you know, I'm not trying to suggest that launch videos are a new concept or anything, but Hex, you've always been great at them. You're sort of the central, you're one of the central characters. It has your sense of humor written into it as well. And I'm curious, especially in this day and age where it does feel like, you know, there's sort of this messaging of for founders, go direct, right. Tell your story, and then, you know, with that, like, all of these mediums on new media to express your story and be more in front of the camera and part of the company brand becomes. Is the founder's brand to some extent. Of course, that's a choice that one makes. But how did you guys think about that? And what's your process for creating a launch video? And, like, if you were to tie it to the more serious question of, like, brand of the company, would love your thoughts on that. Just because, you know, I view you as a leader in that space.

[A]

Leader. I know people are doing some really cool videos these days. I don't know for. For, you know, so you got to keep up. Yeah. Well, I. I think we've always just tried to have fun. Like, I. I think that's kind of underrated. And.

I think that SaaS marketing for a long time, it was just goddamn boring. It's like, every logo is blue. Everyone said the same things, the same buzzwords, the same stuff. Even picking, like, a color palette, we, like, we have this, like, pink color that we use a lot, and it's like, it's different, weird, even a little bit. Like. And I think it. I just kind of have this feeling that it was, like, okay to have fun and that people actually wanted that. As you move a market and you move into enterprise, it's tempting to kind of, like, you want to button things up a little bit. You can't show up, like, completely unhinged. But I also sometimes think about the people at these enterprises. Right. Like, they're humans for sure. They find this shit boring. Like, you know, like. Like, who goes to a conference or is, like, doing a vendor evaluation and, you know, doesn't find everything they're being put in front of them. Goddamn boring.

[C]

Yeah.

[A]

So I. I used to have fun, and so videos are a good way to express it. I. I used to think I wanted to be in film. I was like. Did, like, concert and movie production in college and graphic design. Yeah. So there's a running joke. Yeah, there's a running joke at Hex that, like, it's all just a vehicle for me to, like, make swag.

[B]

It's.

[A]

The other joke is, it's really just a vehicle for me to build the product I always wish I had because, like, it is, you know, very selfish product, and that was just the thing we wanted to use. But I think actually those things come out. Like, I think the fact that we have passion for what we're building and that we Have a really. We have a creative and weird team and we have some freaking weirdos at hacks. And I think that comes out in this amazing way that I hope people feel and hope makes us stand out. And even if someone's not buying our software because of it, maybe just make them smile or inspire them or make them think differently. And I think that's a beautiful and great thing to do in its own way. So how we come up with them, I don't know. We do have this running thing that's almost like an office drama. Like kind of the office, you know, that, like, I guess I'm a character and we've got a smaller recurring character. We do these kind of skits and yeah, we. It takes a couple hours to do because we just lock ourselves in these rooms and just do a lot of lines. It's a lot of ad libbing. It's not really that scripted. And walking out every time we film one of these, I'm like, always so skeptical or pessimistic. I'm like, there's no way that we did. We didn't get it. And then we see the first cut, like, we're all laughing.

[C]

Nailed it. Yeah, it's like an SNL writer's room or something.

[A]

Well, we're not. We're not quite at that level, but maybe.

But I think I would encourage people just to have fun. It's okay to have fun and it's okay to be weird. I think people are looking for that. I think software is weird now. Technology is weird now. These, all these new fabulous computers can just talk to us and do things and think this is so strange and it's exciting. And I think people.

Have an opportunity to, like, embrace the weird and the fun. And we're gonna. As long as I'm CEO, we're gonna keep doing that. Even if you have to button things up here and there.

[C]

No, no, please don't. You guys are damn good at it. Please keep it up. Thank you so much, Barry, for joining us. This was an incredible conversation. Thank you.

[A]

It was fun. Thank you.

[B]

Thanks for listening to this episode of the A16Z podcast. If you like this episode, be sure to, like, comment, subscribe, leave us a rating or review and share it with your friends and family. For more episodes go to YouTube, Apple Podcasts and Spotify. Follow us on X16Z and subscribe to our substack@A16Z substack.com thanks again for listening and I'll see you in the next episode. As a reminder, the content here is for informational purposes only, should not be taken as legal, business, tax or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see a 16 zone forward slash disclosures.