This episode is a little different. Fivetran + dbt Labs CEO George Fraser leads a conversation with Tristan and Andreessen Horowitz general partner Martin Casado.
Martin Casado is one of the leading investors in software and AI infrastructure. He and his team have invested in dbt Labs, Fivetran, Tabular, Cursor, OpenRouter, and many other companies, and he has sat on the boards of both dbt Labs and Fivetran for years. That gives this conversation an unusual shape: three people who know each other well, talking about why Open Data Infrastructure is so vital to the AI era.
The starting point is George’s observation that AI agents make great analysts, and there is an effectively infinite supply of them as long as you pay the token bill. The data stack your team has spent the last ten years building gives them the data they need to work with. Stripe, Ramp, and DoorDash have all built their own AI data assistants. Why are so many companies building instead of buying, what should a leader do first, and what does it mean to keep your data architecture open when nobody knows what comes next?
Along the way: why Martin thinks AI analysts are a “do the work” story and not a product story, Tristan’s case that agentic analytics is mostly the 80% of work you have already done, why Martin says to compare MCP to HTTP and not to a data architecture, what vendors are up to when they put tolls on API access, and why Martin says that across the companies he sees, AI is about productivity and not headcount reduction.
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
dbt State is now generally available. Once it’s on, dbt State checks what has changed upstream, in both code and data, and skips rebuilding the models that haven’t. That’s compute you’re not paying for, and no more waiting on upstream models you aren’t touching in dev. It works wherever you use dbt. Try dbt State with a 30-day free trial for eligible new organizations.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Three ideas from the episode
1. Building an AI analyst is more about doing the work than buying a product. Martin’s view is that agents are good at what human analysts used to do, which is a lot of spelunking through a long tail of tedious problems, and now you can have an infinite number of them doing it. It is “less of a product story, and much more of a do-the-work story, and having the infrastructure to do the work.” Tristan adds that most of the work of unlocking agentic analytics is what teams have already been doing: get your data in one place, model it well, and add the right metadata. The plumbing in the middle, MCP servers and a choice of model, is not that big.
2. Stay composable, because nobody knows what comes next. In a moment of new transformation, Martin says, the market always rewards the open, decomposable stack over the walled garden. His example is Cursor, which went from tab-complete to IDE to agents to foundation model in about two years. George’s version is the architecture his team recommends: keep a copy of your business data that you control, in an open table format, and Iceberg has emerged as the one everyone supports.
3. MCP is a way to access systems, not a way to organize data. The competing picture is an AI tool wired straight into the Salesforce, Workday, and Jira MCP servers. Martin says the way to think about MCP is like HTTP: a protocol that says nothing about structured data, guarantees, or security. Tristan adds that permissions get tangled once more than one system or one person is involved, and that tokens get expensive fast.
Key takeaways
Lightly edited for clarity and length.
Why are companies building their own AI analysts instead of buying a packaged tool?
Martin Casado: I think it’s twofold. One is that these models are data frozen in time. That’s the best way to think about them. Whether you’re buying a big model from a lab or doing your own, it all comes back to the data that goes in, and increasingly that’s the story coming out of the big labs: the most important thing is clean data. The second is that picking through data is a long-tail activity. All data is different, all businesses are different, and you don’t really know what you’re looking for, so it isn’t clear what the right product to build is. Agents are great at what humans used to do, which was a lot of spelunking, and now you can have an infinite amount of them doing it. So it’s less of a product story, and much more of a do-the-work story, and having the infrastructure to do the work.
What are agents unlocking that human analysts couldn’t get to?
Tristan Handy: There are maybe two modalities. You ask an analyst for an answer and there’s a small set of likely answers, and a really long tail of much less likely ones. Human analysts are good at the first kind: there are three things it could be, I’ll check the three things. But then there’s the set of problems where you don’t know, and that’s a much flatter distribution. There’s no better search algorithm than trying some things and working your way through it. Nobody likes those problems. So the human response is to try a couple of things, pick one, sell it back to the business stakeholder as definitely the answer, and spend all your time convincing them, because you can’t search the rest of the space. Agents are going to unlock the places where we just haven’t had the human time to explore.
Martin Casado: It’s the long tail of tedium.
What happens when it gets easy to ask questions?
Tristan Handy: I thought Ramp’s results with their research agent were fascinating. They launched it in Slack and opened it to anyone. I figured they might get about as many questions as the data team used to get, or maybe double, because we’d been talking about Jevons paradox. Within weeks it was 20 or 30 times as many questions. Within six months, it was 50 times. That’s the latent demand in the organization to know things. It had been too annoying to get the answers, so people got by without them.
George Fraser: Having instant access to arcane questions is much more valuable than you realize, because the alternative is wrong answers most of the time. We have a workflow like this at Fivetran, using our own product, Fivetran Context Layer. We’ve connected Claude to an MCP server that connects to all of our data, which is modeled with dbt. In a meeting yesterday we were talking about what percentage of the Global 2000 use our product, and what percentage use a particular SKU we’re not selling to new customers. Somebody thought it was 8% and 4%. I looked it up and it was 16% and less than 1%. When you don’t know the exact answer, the vibes in the air are often very wrong. So I’m not surprised Ramp saw 30x the questions. Those other 29 questions were probably important, but it wasn’t feasible to get answers continuously.
Is AI really better than the human process it replaces?
Martin Casado: Look at support. Before modern generative models, about 30% of inbound support calls could be deflected to AI, and the rest went to a human. Afterward it was about 80%. The net impact wasn’t fewer people calling support, it was that customer satisfaction went up. But the long tail is very, very long, so you still need people to add value there. Data is the same: your understanding of the business goes up, but there is still an infinite amount of work, and you want agents working on the tail. I’d also say it’s a false dichotomy to frame it as AI versus human. It’s AI versus a rate-limited human, with too much demand for the supply, which is why support sucks.
George Fraser: A mistake people make when evaluating AI is comparing it to a hypothetical world with an infinite supply of experts who never have a bad day, and not to the reality of what we actually get.
Should you buy something prepackaged or build it yourself?
Tristan Handy: I just got back from dbt Summit and talked about this with a lot of people. Customers are looking for a piece of technology to solve the problem, and they think the technology is thick. But how do you unlock agentic analytics at your company? The answer is 80% of the work you’ve already been doing. You get your data in one place, you model it well, you have the right metadata around it. On top of that there is some additional technology, but a lot of it is MCP servers and your choice of model and provider, so the plumbing in the middle isn’t that big. When people realize they’re already doing most of this and don’t need to go wholesale on an integrated solution, it feels much more empowering. Right now there’s a lot of imposter syndrome if you’re not deep in AI, and that nervousness is what the all-in-one solutions are being sold against.
Martin Casado: There’s also a non-AI statement we can make here. In a new transformation you don’t know what the stack is going to be, so it always rewards the decomposable stack and not the walled garden. Best practices evolve every month. Whether it was the internet, client-server, or cloud, this is what happened. You would be silly to do something too prescriptive. And AI is pretty smart and knows which tools to use, so if you remove its ability to do that, you’re probably not taking full advantage of it. Go to composability and open interfaces. Maybe in five to ten years we’ll have the new new data stack and things will start to solidify again, but we’re a ways away.
Martin Casado: Look at coding alone. When Cursor started, the value of the company was a model that did tab-complete. Then it was an IDE, and the whole industry thought it was an IDE. Then it was agents, and everyone moved to agents. Then it was a foundation model. That all happened within two years, and it’s going to happen to every one of these things. You want to be very flexible and evolve with the industry.
Who should care about controlling their own data?
Tristan Handy: I think data people at every level have reasons to care. As a senior decision maker you want the strategic flexibility Martin was describing. But at the practitioner level, one of the most compelling things about any technical job is choosing your own tools. You’re more effective, and you build transferable skills that go with you from job to job. There is nothing more frustrating than taking a job and being told “we’re all in on this tool stack.” There’s also a pendulum. The modern data stack started as a reaction against an integrated, holistic view of the world. Around 2022 there was a reaction against the number of vendors you had to buy. Now the pendulum is swinging back, because agents make it so easy to integrate systems together.
Martin Casado: One important thing about disaggregating: there is an impact on your ability to secure and operate, because it’s more complex. So you want an architecture, so you can apply security at the right points. This isn’t “give one prompt to the AI and have it do everything.” Maybe next month, definitely not now. The reason we talk about stacks and architectures is you need some form that allows for security and operational control and yet flexibility. And the nice thing about AI is that if you have an architecture and you know where the control points are, it’s pretty good at staying on top of that, where with humans it’s very hard to keep new architectures in mind.
What does the open architecture actually look like?
George Fraser: First and foremost, you want a copy of all of your business’s data that you control. The way to do that is with open table formats, and specifically Iceberg has emerged as the one everyone supports. All the different tools and vendors can read and write to Iceberg, so if you put your data there, you can be confident that whatever comes around the bend next month will be able to talk to it. And if you have your own copy, you’re not at the mercy of someone else’s opinion of how you ought to interact with your own data.
Why not just connect the AI directly to every system of record over MCP?
Martin Casado: Let’s be clear: serious data-systems people don’t think that’s a viable option. MCP is an access protocol. It has nothing to do with structured data, with guarantees, with security, or with formats. The way to think about MCP is like HTTP. If I told you the answer to data is HTTP, people would laugh. It is a very important way to access things, just like the web was, but it doesn’t give you an architecture to store data and search it. One problem is getting data into one place where you can analyze it. A different problem is talking to the system. MCP solves the second one. Conflating them is a mistake, and it always has been.
George Fraser: The systems of record all organize data differently. They each have their own strategy for what they think you want to do, so you get tangled up in the product roadmap of every one of your vendors, and as the customer you end up the last priority.
Tristan Handy: And the permissions structure doesn’t make any sense. If you want a quick answer from Salesforce, using your own credentials is fine. But the minute you incorporate multiple systems, or want someone else in your organization to see your analysis, they either use their own credentials and get different data, or it’s a whole mess you can’t make repeatable. The other problem is that it’s incredibly token-hungry and expensive. Centralizing and modeling your data in one place for the whole organization is a good idea regardless, and it’s especially good once you see how expensive tokens get in the other version of the world. There’s also an opportunity for data practitioners here. A lot of what people connect MCP servers to, like Gong sales transcripts, isn’t the structured data we’re used to. So how do you model text data in a data platform? There are good answers to that.
Tristan Handy: I’ve weirdly found myself empathizing with the people who go the MCP route, even though I don’t agree with it. They’re typically individual contributors without a lot of organizational pull. They technically couldn’t do this before, but with Opus they can, and they’re asking how to get their job done. It might help them get that one thing done, but it hits a dead end pretty quickly.
Who owns the data, and what happens when vendors put tolls on access?
George Fraser: It’s partly a technical question about the right architecture, and partly a political and economic question about control. A lot of SaaS companies are saying on earnings calls that they’re going to monetize AI access to data, that it’s their data, not yours, and that they’ll put up toll gates or make you use their agent instead of the one you want. Late last year, Amazon decided to start charging for access to its Selling Partner API, which is how a vendor gets data about what they sold on Amazon. You pay a fee when you sell, and then they said you could pay again just to find out how much you sold. They walked it back after a couple of months because the reaction was outrage. This isn’t over. We see people come knocking on Fivetran’s side and say we should pay for access to their API, and our position is that we are accessing it on behalf of the customer.
Martin Casado: This happens every time the consumption layer changes. Think about operating systems and the tension over low-level access to Win32, which became a famous court case. In the end it turned out to be better for platforms to have more apps and more consumers. The same thing happened on the web, where APIs were resisted and then standardized. It’s resistance to change: the consumption layer shifts, and companies say they don’t like it because they understand how to monetize the old one. Those companies either come along, with some kicking and screaming, or they become irrelevant, because consumption is now evolving to agents.
Tristan Handy: My sense is that attempts to charge or add friction are really just to buy time. You can’t pivot business models overnight. If it’s a growing pain the industry goes through over two years, then fine.
What should a leader do first?
Tristan Handy: I don’t think this is a stage thing. If you’ve already invested in your data capabilities, with a data team and a data platform, the most important message is that this is here today and you can do it. It takes a little investment and some choice-making, and we’re going to make it a heck of a lot easier over the next six months. The question is how much you want it, and whether people across your organization need data more than they’re getting today.
George Fraser: Your data team is your friend in doing this. Make sure they understand that this is a big new part of their job.
Tristan Handy: It’s so important to frame it internally as an opportunity and not a career risk. Over the last year or so that we’ve been talking about this as an industry, I’ve had exactly one data leader come up to me and say they thought they could lay off most of their data team. Every other data leader I’ve spoken to says this is a boon, and you should make that clear to your team.
Martin Casado: Avoid the extreme rhetoric. One extreme is that it doesn’t work and it’s snake oil, which is patently not true. This is like the internet or the web: it’s going to happen, and you need to be part of using it. The other extreme is that everything changes and everybody’s out of a job. We’re four years into this and we have data points: teams that adopt it tend to grow, and they tend to grow faster, because the AI explores more and gives the humans more to do. I sit on a bunch of boards and have visibility into hundreds of companies, and to a one, this is for productivity improvement, not headcount reduction. The first-principles argument is simple: you only do headcount reduction if you don’t know how to grow. That has nothing to do with AI. If you know how to grow, you need the humans behind it. This is very positive for the industry, and the industry is going to grow along with it.
Chapters
00:00 – Tristan’s intro
00:42 – Why AI makes great analysts, and why companies are building their own
02:14 – Martin: models are data frozen in time, and agents do the spelunking
04:19 – Tristan on the long tail of analyst problems
07:59 – Ramp’s research agent and the flood of latent questions
08:44 – George on Fivetran Context Layer, and being wrong by 2x
10:20 – The customer support analogy: from 30% to 80% deflection
12:08 – Don’t compare AI to an impossible standard
13:24 – Build or buy? Cortex Analyst, Genie, and doing it yourself
13:47 – Tristan: the answer is 80% of the work you’ve already done
15:39 – Martin: in a new transformation, go composable
17:04 – The Cursor story: IDE, agents, foundation model, in two years
17:38 – Open Data Infrastructure, and who should care about control
19:51 – Security, architecture, and why AI can help enforce it
21:03 – Iceberg and the skeleton of an open architecture
21:42 – The competing vision: MCP straight to every system of record
23:20 – Martin: MCP is a protocol, like HTTP
24:07 – Permissions, tokens, and unstructured data
27:05 – API tolls, Amazon’s seller API, and who controls your data
29:12 – Martin’s history lesson: Win32, the web, and consumption layers
32:08 – What should leaders do first?
33:14 – Your data team is your friend
34:06 – Productivity, not headcount reduction
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.
the mcp point is the one that deserves more attention. the permissions problem is what kills the direct-wire fantasy in practice. every system of record has its own model of who can see what, and a protocol does not reconcile those models, it just moves the question.