In her conversation with Tristan, Emilie describes “kilo speed,” the cultural discipline Kilo built around removing friction so people can ship, and the org design underneath it: about 20 engineers, one person with the word “product” in their title, and every engineer owning their own area end to end, from the roadmap to the bug reports. Her argument is that this only works because each of those engineers is also managing a fleet of AI agents, which is why she thinks the job has quietly changed from individual contributor to manager, whether you’re managing people or agents or both.

She also makes the case for Kilo’s model-agnostic bet: instead of building on one lab’s models, Kilo supports more than 500 of them and works with model labs directly, sometimes for weeks, before a new model ships. Tristan draws a parallel to dbt Labs’ own argument for open data infrastructure, though Emilie is careful to draw a distinction: for models, she says, the case for staying open is less about fear of lock-in and more about preserving the freedom to pick the right tool for the task while the frontier keeps moving.

They close on a question about what software engineers are doing today that data people haven’t caught up on yet. Emilie flips it: data people, she argues, have spent years being multi-threaded across marketing’s ask, the VP’s ask, and finance’s ask in a way software engineers were mostly protected from, which may leave analytics engineers better prepared than developers for a world where everyone is managing a portfolio of agents.

dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now with a 25% discount using the code dbt26-podcast.

If you’d like to watch the keynote and on-demand breakout sessions from your desk, register for online access.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. Kilo speed is a deliberate cultural choice, not a byproduct of being an AI company. Emilie names the feeling directly: no red lights on the drive to work, no friction, no checklist that exists just to exist. Tristan pushes back on the idea that this is a natural outcome of being an early AI adopter, and Emilie agrees it isn’t. It’s a decision the team makes over and over, in how they handle a Slack channel or an email as much as in how they ship a feature. The org design that makes it real is unusual: about 20 engineers and exactly one person with “product” in their job title. Everyone else owns their own area completely, roadmap, bug reports, Discord support, and the escalations that come with it. Emilie’s explanation for why this works now and might not have ten years ago isn’t that engineers got smarter. It’s that each engineer is running a team of AI agents alongside their own work, which is why she says nobody at Kilo is really an individual contributor anymore. Everyone is a manager, whether they’re managing people, agents, or both, and the coordination overhead that used to require four or five separate roles collapses into one person with a wider mandate.

2. Being model-agnostic is a bet on optionality, not a fear of lock-in. Kilo works across more than 500 models rather than building on top of one lab’s stack, and Emilie describes an early-access relationship with most major labs: testing unreleased models for weeks, adjusting Kilo’s system prompt for each one, and feeding real usage feedback back to the lab before a model ever goes public. When Tristan draws the parallel to dbt Labs’ own argument that pipelines should be defined independently of compute, Emilie pushes back gently on the framing. For data compute, she notes, the fear is a specific one: nobody wants to relive an Oracle-style lock-in. For models, she says the concern is different. Nobody knows what the best model, or the best value for the dollar, will be three months out, so the point of staying open isn’t protection from a vendor, it’s the freedom to choose the right model for the task as the frontier moves. She illustrates this with Kilo’s Agent Manager, which lets her give the exact same prompt to several models at once, running in separate git worktrees so they don’t collide, purely to watch how differently they perform. She also points to a broader industry mood shift: earlier in the year the conversation inside Kilo was about token-maxing, pushing usage as high as possible. By the time of this recording, it had flipped to efficient AI spend and measuring real ROI, which she reads as validation of the model-agnostic thesis rather than a contradiction of it.

3. The junior-engineer problem is real and unsolved, which makes her closing argument about data people more surprising. Every engineer at Kilo has at least 10 years of professional experience, and the company is fully remote, a combination Emilie is candid about: she doesn’t know how to build early-career hires into a distributed, AI-native org, and she’s optimistic the industry will figure it out rather than confident that it already has. She points to programs like Ember Fellows, which grew out of the now-closed Venture for America and intentionally reintroduces an in-person component, as one open experiment. It’s against that backdrop that her answer to Tristan’s closing question lands as unexpected. Asked what data people haven’t caught up to yet relative to software engineers, she flips the question: data people, she argues, have spent years being multi-threaded across marketing’s dashboard request, the VP’s ask, and finance’s filter change in a way software engineers were largely protected from until agents started forcing the same context-switching on them. If managing many parallel agents is really a management problem, analytics engineers, who’ve effectively been “manager of one” their whole careers without a product manager or designer running interference, may be better prepared for it than the developers currently writing the tooling.

Key takeaways

Lightly edited for clarity.

Give us your bio.

Emilie Schario: I’ve done a lot of things over the years. My claim to fame, at least in the dbt community, is that I was person number 52 in the dbt Slack and was pretty early on the GitLab data engineering team. I held a number of roles at GitLab, went on to spend some time at Amplify, started my own company, raised a couple million dollars, and we were acquired by Settle. I left Settle and landed at Kilo, where I was co-founder and led product and engineering. Most recently, we just announced two weeks ago that Kilo was acquired by Anaconda, bringing all the best of agentic engineering into the Anaconda universe, which will be familiar to folks in the dbt universe who are also using Python.

What’s kilo speed, and how does it feel different to work inside an AI company?

Emilie Schario: We have this saying at Kilo, kilo speed, which is kind of like your drive to work when you don’t hit any red lights. Everything is working, it’s smooth, there’s no friction. Working in AI is working with people who are trying to create that environment: no painful processes that slow you down, no checklist for the sake of having a checklist. It’s about looking at what needs to be accomplished, assuming everyone in the room is an adult, and creating the perfect environment for people to move through it as quickly as possible, whether that’s a feature to a customer, an order form to an enterprise, or something for an auditor in compliance. The sooner we get something out there and into a user’s hands, the sooner we get feedback and can make it better.

Is kilo speed a natural outcome of being an AI company, or something you have to pursue on purpose?

Emilie Schario: We are actively working on it. When people hit friction, we have to decide we’re going to make it better. It’s not just the people we’ve got around the team, it’s that the people we’ve got are also actively choosing to pursue this all the time, whether that’s in their work, in a process they’ve identified, or in how they handle email or create a new Slack channel. Those are all outflows of our kilo values, and they’re what we’re hiring for. So there’s probably a bit of chicken and egg: we’ve got the right people who want to work this way.

Walk me through the product and engineering process. What does it actually look like day-to-day?

Emilie Schario: We’re an org of about 20 engineers, and there is only one person with the word “product” in their job title, handling a shared core infrastructure piece. Otherwise, every engineer is responsible for their own area. Someone on our cloud agents team decides day-to-day what the roadmap for cloud agents looks like, and he’s the one in Discord responding to user feedback. When tickets come in via support, they’re escalated to him. When there’s a bug report, he’s handling it. He really owns the whole product. Some companies call these product engineers. We just think of it as our default way of operating.

That’s normally four or five different people’s job.

Emilie Schario: At least, if not eight or ten. And it’s not just about having more people, it’s the additional communication and coordination that comes with more people. One engineer can do this and go faster than ever before, with a wider mandate, because he’s got a team of AI agents working for him and with him all the time. I think about the first eight years of my career, where at the end of every workday you wrapped everything up with a nice bow. Now, at the end of every workday you’re thinking about what you’ll kick off a set of agents to work on overnight. You start your day, kick off another set, and then review what the first set gave you back. You don’t have a bunch of ICs anymore. You have a bunch of managers, whether they’re managing individuals or agents.

Of your 20 engineers, does anyone have less than three years of experience? Is this the death of the junior software engineer?

Emilie Schario: The average engineer at Kilo has 15 years of professional experience. The least-experienced engineer has 10. We’re also a fully remote organization, and it is so hard to onboard new people that way. You worked with me at the earliest stage of my career, and I remember very clearly being taught by you what a window function was. I probably would have already known that if I’d had a weekly meeting with a bunch of more senior folks in person, but I was working remotely at the earliest stage of my career. There are invisible things about learning how to work that are so much harder remotely. Kilo is a globally distributed org, so we’ve really indexed for seniority. I don’t know what it looks like to have early-career hires in this world. I’m optimistic we’ll figure it out as an industry, because we can’t only hire seniors. We have to build juniors into seniors along the way.

Who’s going to take the first risk on early-career hiring in this environment?

Emilie Schario: I’m excited to see programs like Ember Fellows, which grew out of Venture for America after VFA shut down. They still have a city component, getting people in person, because a lot of people prefer to learn that way, or it’s just easier to get people started in person. There’s the hiring piece, how you give people the skills, and then there’s the remote piece, which makes it that much harder for us to hire early-career folks at Kilo specifically.

What did running the data team at Netlify teach you? What did you find challenging about it?

Emilie Schario: My biggest concern was always the “so what from here” for my career. As people who know me will tell you, I’ve got ambition coming out of my ears. Someone once told me, if you’re going to be a bear, be a grizzly, and I think about that all the time. I remember looking around and asking myself: so what do I want to do next, lead a bigger data org, lead more data people? What does that even mean? We were a very impactful team at Netlify. I had an incredible group of people who’ve gone on to do phenomenal work at dbt Labs, at Brooklyn Data Co., and at lots of other companies. I think I left data less because I stopped seeing it as my next career opportunity, and more because data had given me a bunch of skills I thought I could apply to other domains.

What was your mandate at Amplify Partners?

Emilie Schario: My role was, in a lot of ways, to be a consultant for the different companies in the portfolio. I built internal playbooks, hiring your first data person, building an early data stack, things their portfolio companies could reuse over and over. I also worked with founders in and outside the data space. At the time I worked with Hex on some of their new hires, adding a voice to the interview process. I was also the target persona for a lot of those data products, so I worked with Hightouch on their messaging and reacted to their early positioning. It wasn’t just data companies. I worked with Prisma as they set up their earliest data team. Almost all of my work was with companies already in the existing portfolio, occasionally talking to a founder before they were invested so they could learn how I like to work across a portfolio.

That’s the dream: analytics consulting without the sales.

Emilie Schario: I really enjoyed the role for a set amount of time, but builders like building. I realized at the end of it that I missed being part of a team, growing a company, watching the revenue, building product. I don’t think I understood how important those things were to me until I spent a year at Amplify and there weren’t new people joining Slack every Monday, or someone else to have a coffee chat with. It’s a very different job, focused on meeting people outside the org rather than inside it. I get a lot of joy from that in-house building experience.

What do you walk away with from your couple of years founding an ERP company?

Emilie Schario: It’s going to take an unfathomable amount of money. Try not to compete with NetSuite unless you have a gajillion dollars in the bank already. I think accounting overall is hard, though there’s interesting work happening: Tiger Beetle doing database work for transactions broadly, Fragment.dev on ledgers, Puzzle doing automated AI competing more directly with QuickBooks than with the more complex layer of accounting. There’s a hearts-and-minds battle that isn’t a technological one: how do you convince someone who’s been doing this for 10 or 15 years, in an old-school industry like supply chain or finance, that NetSuite isn’t the inevitability? I never cracked that code, even in my own mind. I talked to one brand that told me, yeah, we moved to NetSuite too early, but now we’ve hired four consultants and don’t see a path back to QuickBooks. Battle scars galore.

Benn Stancil has written about whether data people make good founders. Did your data experience help you step into the founder’s seat?

Emilie Schario: Absolutely. I always looked at data as problem solving: what’s the best indicator for customer health, let’s break that apart, what numbers do we have, what do we need, how do we get to the core of the problem, and what’s the best indicator we have that’s reproducible. That’s true all the way back to my college senior thesis, which asked what behaviors indicate whether a woman will vote regularly.

It’s about breaking a problem into its component parts to figure out what happens next, or what you can change or make better. As long as you see data as that kind of work, then yes. But I’d bucket that as “startup data people” broadly. If you think of data as someone filing a ticket to update the filters on a dashboard, and you just do it without knowing how they use the dashboard or what problem they’re solving, that’s a very different persona, and you’re just a number cruncher.

Understanding how much you care about the why is what predicts whether you’ll be a founder, more than any specific skill you have.

Tell us the Kilo founding story.

Emilie Schario: Kilo was originally founded by JP Posma, who was working on the Vesuvius Challenge with Nat Friedman and Sid Sijbrandij. JP had a family circumstance come up and had to step away. I was in Sid’s orbit at the time, having just left Settle. Sid asked me to step in as CEO temporarily and keep things running while we hired someone permanent. I wasn’t very interested in the role at that point. I’d just come off Settle, I had three very little kids, and my husband was transitioning things at his work. It wasn’t a fit for me at the time, but I said I’d step in for a short period and get things going.

Tell us about Sid.

Emilie Schario: Sid is still executive chairman at GitLab. He’s a general partner at Open Core Ventures, which has started 30 to 50 companies over the last couple of years, all around open source. He also has Even One Ventures, focused on the biosphere. Sid has had a very public cancer journey, and he’s in great shape now, but he’s shared a lot about what he’s doing there.

How did Scott Breitenother end up joining as CEO?

Emilie Schario: I told myself I was there temporarily, got the ball rolling, and started thinking about who the best CEOs I know might be to bring in permanently. I texted our good friend Scott: “Hey Scott, I’ve got a crazy idea, you want to hop on a call?” He said, “Yeah, how about in an hour,” and we hopped on a call. I made the introduction. There are lots of things I enjoy about Kilo, but my favorite has to be working with Scott day in and day out. We probably talk ten times a day. I talk to Scott more than anyone besides my husband at this point. He took over as CEO and really transitioned the business from a project to a business, leveling up from an open-source project with a couple of commercial features into an agentic engineering platform. He’s led the business and go-to-market side, and I’ve led product and engineering. Somewhere along the way, in my words, not his, he called me out on my nonsense, and we all realized this wasn’t temporary, so I committed to joining permanently. Two or three weeks ago we announced the Anaconda acquisition, so it’s been a kilo-speed run of a company too.

How does Kilo differ from something like Claude Code or Codex?

Emilie Schario: When you use Claude Code or Codex, you’re using software built by a lab that only has that lab’s models available in it. Anthropic makes Claude Code and gives you access to their own models, Opus, Sonnet, Haiku, and so on. If you want to use Anthropic’s models in the morning and OpenAI’s models in the afternoon, you have to switch software.

With Kilo, we think models change, but your workflow shouldn’t have to. You can use the Kilo platform with over 500 models, including the big labs but also a much broader list, like Minimax, GLM, Poolside, and Kimi. In terms of platform, we’re a VS Code extension, a JetBrains extension, a web interface, a CLI, a mobile app, and a browser extension. We try to be everywhere you are.

Did it seem sane that a small player could compete with the giants of the industry?

Emilie Schario: I was already very AI-pilled. I was a daily user of Cursor at that point. I’d had my third son in fall of 2024, and I’m not very good at maternity leave, so I made AI my project. I started experimenting with Bolt.new and Cursor, and by the time I came back I told my boss at the time, I’ve seen the future and it’s AI and we need every developer to change how they work. You can imagine how well that went over. I made it my mission over the next three or four months to push AI adoption, and it was incredible.

I also started automating things at home, the household calendar, the grocery list, paper cuts I’d previously just lived with, by outsourcing them to a script or an agent. So when Sid’s call came in, in September 2025, I said yes, I know the coding agent space, even though I was candidly less familiar with Kilo specifically, which was still early in its journey. In some ways the answer to “why not compete” is just, why couldn’t you? Sure, you’re outnumbered, but I remind myself we’re still so early in AI that the last three or four years won’t even be in the history books.

Can you talk about Kilo’s open source roots?

Emilie Schario: Kilo, in its earliest days, was a fork of a fork. There was a project called Cline, an open source coding agent. Roo forked Cline because Cline didn’t take community contributions, and Roo built a real community around that. Kilo was then a fork of Roo, focused on community contributions with a slightly different product vision. Those were the building blocks for a long time, but Kilo is no longer a fork of Roo. We use parts of the open code server under the hood, which has been true since February of this year.

At our core, though, the team and Sid’s own approach are focused on the mission that if you make things open, you make it better for you and for everyone who wants to leverage the product.

As someone who contributed to dbt before 1.0, all my contributions were features I wanted, not necessarily things on your roadmap, and I see that pattern in our own contributors. There are still plenty of open source or open-core coding agents: Cline is still alive, Roo sunset their coding agent in favor of a remote product, and there’s Pi, which ships inside OpenClaw, plus Open Code. I’m excited to see open source continue to grow here.

How does it work to build across so many models? Do you have something like a dbt adapter?

Emilie Schario: We do. We can adjust the system prompt based on the model itself, and we work with the labs before models come out so we can make those adjustments in advance. Not every lab, but with most of the major ones we have early-access programs and real relationships.

We’re often testing models for weeks before they’re generally available, both so we know it works well in Kilo on day one, and so we can make the adjustments that give it that level-up experience: how the system prompt needs to change, what additional tools or skills need to be available.

It’s not uncommon for our whole engineering org to spend a day running on some model with a funky code name, share feedback in a Slack channel, and have our head of partnerships take that back to the lab. That might be the final checkpoint before launch, or an intermediate one while they’re still tweaking.

So this isn’t a world where Kilo can independently build product, similar to how dbt can’t independently build product without a compute partner.

Emilie Schario: Interestingly, I like to joke that we have as many shared Slack channels with model providers as we do internal Slack channels. What a time to be building, that there are so many people building models right now that we can set up shared channels with all of them, so that when their models come out on day one, it’s a great experience in Kilo.

Does the open-model bet track with dbt Labs’ own argument for open data infrastructure, that you don’t want pipelines tied too tightly to compute?

Emilie Schario: The key difference, I think, is that with data and open infrastructure, the worry is about not wanting to get locked in by a vendor. With models, I don’t think people are as worried yet about vendor lock-in specifically. If you’ve got a big AWS commitment, bring your AWS key into Kilo and drain against that commitment, that’s fine. It’s more that I don’t know what the best model is going to be three months from now, or the best bang for your buck. Preserving that optionality is less about a specific vendor concern and more about the freedom to choose the right model for the task, especially as companies start thinking harder about AI ROI.

Earlier this year we were talking about token-maxing, getting everyone spending more. Now it’s shifted to efficient AI spend, which makes me even more convinced that the thing that matters is using the right model for the task, the one that can complete it successfully without overspending.

I like to use knives as an example: you’re not going to slice a crunchy sourdough with a tomato slicer, and you’re not going to slice a beautiful July tomato with a bread knife. You need the right tool for the task, and model selection is part of that. We have an auto-efficient model in Kilo that can route on your behalf.

What’s the Kilo business model?

Emilie Schario: If you’re an individual, you can create a Kilo account and use the software free forever. Teams and enterprise customers pay for software features, a set price per seat per month. When it comes to actually using models, you can bring your own key, an Anthropic key, an OpenRouter key, or another subscription, and use that in Kilo. You can pay as you go, putting in a set amount and draining it down. Or you can buy a Kilo Pass, a monthly credit subscription where you get some bonus credits built in.

What’s a great way to see how different models actually perform on the same task?

Emilie Schario: One of my favorite things when a new model launches is our Agent Manager, which lets you give the same prompt to multiple models at once. I have a vanilla prompt: create a snake game, use only vanilla JS, make it beautiful, I’m a 33-year-old woman, design it in a UI I’d like. I’ll give that exact prompt to several different models and see what comes back, how long each one takes. They run in different git worktrees so they’re not stepping on each other. It’s a great way to see how differently models actually perform, because the results are drastically different even from an identical prompt.

Do you experience imposter syndrome stepping into this space, and do you have advice for others going through it?

Emilie Schario: Every second of every day. I think that’s where being surrounded by the right people matters. I’ve been lucky to work for people, yourself included, who were willing to say “I don’t know,” and that set an example: the smartest person in the room doesn’t have to have all the answers.

I’ve had plenty of moments of imposter syndrome, but more than anything I’ve embraced my willingness to say I don’t know, make the best decision I can with the information I have, and be willing to change my mind. Having a team around me helps too, which is part of why I talk to Scott ten times a day, going to him, getting his thoughts, and vice versa. If you want to go fast, go alone, but at Kilo, between Scott, Sid, and me, we’ve found a way to go fast as part of a team.

What are the most useful things software engineers are doing today that data people haven’t caught up on yet?

Emilie Schario: Good question. I actually think it’s the reverse in one important way. Every data person I know is much more multi-threaded than software engineers have ever had to be. Data folks are toggling between an ask from marketing, an ask from the VP, and an ask from finance in a way software engineers have largely been protected from.

One of the big pain points I hear from software engineers right now is context-switching that feels overwhelming, because it’s not something they’ve had to do before. As data people move up the AI-engineering maturity curve, I’d expect them to jump into managing many parallel agents in a way a typical software developer has struggled with, because data people have already been doing something like it.

If we’re all becoming managers, that’s something data people are probably already comfortable with, because they haven’t had a product manager or a designer running interference. They’ve been out there figuring it out for themselves. Manager of one, already.

Chapters

Timestamps are keyed to speaker-turn changes in the recorded transcript, so a mark shows when a topic’s turn begins, not necessarily the exact word. Verify against the edited cut before publishing.

00:00 Welcome, and Emilie’s podded bio
01:25 From traditional infra companies into an AI company
02:05 What “kilo speed” means
03:37 Kilo speed as a deliberate choice, not a natural outcome
05:20 Could this have happened at GitLab or Netlify?
05:55 The product-engineer model: one PM, 20 engineers
08:03 “You don’t have a bunch of ICs anymore, you have managers”
08:28 Is this the death of the junior software engineer?
09:58 Remote work and the difficulty of onboarding early-career hires
10:52 Who takes the first risk on junior hiring?
12:01 Emilie’s path: Smile Direct Club, Doist, GitLab, Netlify
12:47 What running a data team at Netlify taught her
14:30 A year at Amplify Partners, across the portfolio
16:10 “The dream”: analytics consulting without the sales
17:28 Founding Turbine, and the lesson about NetSuite
19:33 Ben Stansel’s question: do data people make good founders?
22:34 The Kilo founding story: Sid’s call, and “temporary”
23:15 Sid Sijbrandij: GitLab, Open Core Ventures, Even One Ventures
24:36 Texting Scott Breitenother: “I’ve got a crazy idea”
26:44 From project to business, and the Anaconda acquisition
27:08 How Kilo differs from Claude Code or Codex
29:20 Was it sane to compete with the giants?
30:02 AI during maternity leave, and “I have seen the future”
31:32 Automating the household calendar and grocery list
34:16 “Why couldn’t you”: still early in AI
34:37 Kilo’s open source roots: Cline, Roo, and a fork of a fork
37:21 Three million users, and open source coding agents
38:11 Working with model labs before launch
40:11 Building product in partnership with the labs
41:04 The dbt parallel: open data infrastructure vs. open models
42:32 The Cursor and SpaceX acquisition, and the Grok data joke
44:53 What’s the Kilo business model?
47:02 The right model for the task, not the cheapest one
48:44 Agent Manager: the same prompt across multiple models
49:39 Imposter syndrome, and the value of saying “I don’t know”
52:09 What software engineers do that data people haven’t caught up on
53:11 The flip: data people as natural multi-threaded managers
54:21 Closing thoughts

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

Tristan and Jason are doing a live version of the podcast at dbt Summit. dbt Summit runs September 15–18 at The Cosmopolitan in Las Vegas. Register now with a 25% discount using the code dbt26-podcast.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Topic one: The case for physical AI

Accelerated Understanding, founded by former NVIDIA scientist Anima Anandkumar and Benedikt Jenik, launched to build AI that can simulate and understand physics well enough to “invent and discover.” The company describes its architecture as built on neural operators rather than the transformer architecture behind most large language models, and claims it can process up to 5 trillion data points in a single prompt, a scale meant to dwarf typical LLM context windows. Initial focus is enterprise use cases in chip design, robotics, extreme weather, and energy.

Condensed transcript

Jason Ganz: There’s kind of two parallel threads in my stories today. One is the overall emergence of the AI landscape and how rapidly things are changing, and the second is how we make sense of that as data practitioners and in our own lives. The first thing ties into something you said, Tristan, at the end of our last episode: that it’s good to be in this world where things were pretty fuzzy and now we’re starting to get the shape of it. That’s true of the existing set of models and technologies, we can see the trajectory. What I keep coming back to is the possibility of an architecture change or a breakthrough that really changes how we think about things. And we got the launch of a company since we last talked, called Accelerated Understanding. They say it’s AI that can simulate and understand physics to invent and discover. If an LLM is generating a one-dimensional token stream, and a video model is generating a two-dimensional representation of a static world over time, this is actually representing a full 3D scene. What they claim is that this can let us transcend a lot of the limitations we’ve seen with LLMs, opening up use cases in robotics, biology, and a wide variety of domains.

Tristan Handy: I hadn’t heard of this company before you brought it up, and while you were explaining it I was walking through their website. I should know better than to say things like “we’re starting to get a handle on this, aren’t we?” Because yes, we do start to get a handle on things, and then the phase shifts come, and they’re coming so rapidly they shouldn’t be unexpected at this point. I do think it’s very credible that current technology doesn’t deal well with the physical world, Yann LeCun was saying that on a long-form podcast over a year ago. Do you have a sense of the status of the actual company and the technology?

Jason Ganz: My understanding is they’ve been funded by NVIDIA and are in the process of coming out with a product. I don’t get the strong sense that this is the breakthrough we’ve been talking about, it might be, it might not be, but it came out of left field. One of the claims they made is that this format has a nearly infinite context window. And when you have a nearly infinite context window, that changes so many of the things we think we know. That’s one of the biggest ways we’ve shaped our beliefs about what’s true in AI, that there’s this thing called the context window, a relatively defined size, and we’ve built a whole scaffolding of skill files and agents.md and compacting around it. My intuition tells me we’re going to keep dealing with context windows as we know them for a while, but it’s one of the interesting things about the era we’re in, understanding the current moment while staying open to the fact that things could shift.

Topic two: the political fight over data centers

Two posts on X kicked off this segment: one from Danny Penny, who works on a16z’s American Dynamism team, arguing data centers are good for the working class and for American manufacturing, and one from Gavin Baker, managing partner and CIO of Atreides Management, arguing that the facts on water usage, tax revenue, and power have shifted substantially in data centers’ favor over the past 18 months.

Condensed transcript

Tristan Handy: There were a couple of posts on X that I fundamentally agree with, but that I was happy to see. Jason, you and I are both of the political leaning that would like to see more high-quality conversation and consensus across party lines instead of fracturing, and there’s this weird thing where the one topic that many, many people in the US seem to agree on right now is that data centers are bad. I don’t actually believe that, but I have a lot of sympathy for people who do, so it requires some nuance. One post is by Danny Penny, who was recruited into a16z to work on their American Dynamism fund. The other is by Gavin Baker, who I believe is the managing partner and CIO of Atreides Management.

Both took a positive view: Danny’s argument is that data centers are good for the working class because they generate a huge number of trades jobs, and that this is what physical manufacturing looks like in the 21st century. Gavin echoes that, but also says that 18 months ago the facts were different, and most of what was true of data center projects back then isn’t true anymore: water usage is much better than people generally believe, and he shares data on tax revenue, jobs, and power, including how current projects often generate their own power. I’m not here to litigate the specifics. The bigger point is that the facts are changing rapidly, and if you’re relying on an eighteen-month-old mental model of the world, that’s not going to serve you very well today.

Jason Ganz: I’ve experienced a tremendous amount of agita about this, because I personally believe we should be building these things, a lot of them. At the same time, what we’re seeing from people is undeniable, and it’s a reaction to a lot of things: traditional NIMBYism, but also anger at a broader loss of trust in elites. I was listening to a podcast with a woman named Jasmine Sun on Ezra Klein’s show, talking about a town where a company said they’d build a robotics factory and only built half of it. This is coming after people feel that social media and the internet made their lives worse, and in some ways this is a reaction against that, even as it’s ripping apart our institutions. People are wrong about the water usage, but the thing they’re feeling, that this is a massive shift and they’re scared, is fully correct. Nobody can honestly tell them it’s all going to be fine.

Tristan Handy: The way I’d summarize your response is: while the facts may support the argument that data centers are good, the context, whether it’s history or the political moment, is stacked up against the issue right now. And I completely agree with that. The additional fact I’d throw on the pile is that there’s demand booked out through at least 2028, if not 2030, measured at multiple stages of the pipeline, chips, memory, data center orders, capacity from the labs. The three big hyperscalers are probably the most sophisticated forecasters of compute demand in history, and they’re generally good at this. This issue isn’t going away, and it’s going to be a decade-long story we as a society need to come to a real reckoning with.

Topic three: Ian Macomber on the shape of the post-AI data stack

Ian Macomber, who leads data at Ramp and was a recent guest on this podcast, published The Shape and Feel of the Post-AI Data Stack on his personal blog, tracing the evolution from the pre-modern and modern data stack eras to what he argues comes next: the same foundation, extended to unstructured data and a new set of agentic interfaces.

Condensed transcript

Jason Ganz: We got a post from Ian Macomber, who’s at Ramp, on his personal blog, on the shape and feel of the post-AI data stack. I really love this post as an encapsulation of what we’ve learned about how great data teams are going to need to operate in the post-AI world. Ian does a good job breaking down how this is an evolution of the data stack practitioners have used for years, walking through the pre-modern data stack, before cloud data warehouses, through the modern data stack most listeners are well acquainted with.

What’s really interesting is the post-AI data stack: today’s data teams have two jobs, enable everyone to build with data and AI accurately, powerfully, and independently, and build and champion the singular reality their company operates on. That’s a big goal, pretty different from writing dashboards and reports. The real big change is on the interfaces side: your interfaces aren’t just dashboards, reports, and spreadsheets anymore, they’re coworkers, including AI and agentic coworkers, coding agents, Slackbots, and AI-native BI tools. Your job goes from creating the canonical reports your business uses, which isn’t going away, to also building the data reality layer your agents are going to use on top of it.

Tristan Handy: It has that funny quality that many really foundational posts have, where when you read it you think, yeah, this is basically what I had in my head, there’s not some dramatically new idea in it, but it’s comprehensive and simplifying. It’s an excellent distillation of what data teams should be doing right now. I think some of the best material is in the latter half, where Ian argues the post-AI data stack has to have agent-operable tools.

We’re all familiar with MCP, fine, but the really great quote in here is: “I really don’t want to use your agent. I want to use my agent to use your thing.” There are so many tools today that want to be an end-to-end solution: write your entire semantic layer in their proprietary language, keep all your models and dashboards in their tool only, send all your stakeholders to their tool only. I just don’t believe that’s how this plays out. That learning loop between your company’s data and how AI operates on top of it is too valuable, and user behavior is too dispersed, to bring everything into one closed ecosystem.

Jason Ganz: That’s exactly right. Even if you got the perfect data agent platform, all locked up, the set of use cases across your whole business has to be widely accessible. That gets into my other favorite quote from this: “Don’t walk your intelligence into someone else’s interface.” Your organizational data and context is the unique value you bring, and it’s going to power your agentic workflows, so having that in an architecture where you own your context and your evals means you can use them flexibly across whatever interfaces come next. Ian named four interfaces in the post, but we don’t know what interface is coming tomorrow, and preserving that optionality is going to be very important.

Tristan Handy: There’s one other thing I want to talk about, because while this purports to be a post about technology, I think it may be even more important as a discussion of who we are as data practitioners and how valuable we are in the new era. That conversation often gets treated like a pat on the back, “you’re smart, we’ll all figure it out together,” with no real truth value behind it. This post really starts to map out what data practitioners will actually be doing to create value in the future.

It makes me think back to the early days of dbt, my thesis was always that if you give data practitioners tools that let them create more leverage inside organizations, that lets them create more value for those organizations, which lets them get promoted and paid more and build more meaningful careers than data people had in 2005 or 2010. I think we see a roadmap here for how data people create value for the next five to ten years, and it shifts toward encapsulating unique knowledge into agent-readable formats, and away from answering discrete questions directly for stakeholders.

Jason Ganz: And this isn’t hypothetical. Ian writes that if you’d told him two years ago his CEO would bring up REM semantically on podcasts, or his IR team would bring it up on investor calls, he’d have been shocked. This is a way he’s actually used to provide increased organizational value in a way that’s legible to his team, we have proof points at one of the hottest companies in the world that this is happening.

Topic four: an update on the Hugging Face incident

New reporting has added detail to the OpenAI/Hugging Face incident the pair covered previously: roughly 700 of some 1,200 coordinating agents took part in compromising Hugging Face’s Artifactory package manager, exchanging more than 70,000 messages in the process. Separately, reporting from The Information, via TechCrunch, describes a technique called “recurrent depth” in OpenAI’s upcoming Astra model, which loops the same transformer layers over a hidden internal state multiple times before producing an output token, a design that makes chain of thought harder to monitor.

Condensed transcript

Jason Ganz: In the weeks since we last talked about this, it’s become the breakthrough story of the year for AI, or one of a short handful of them. We’ve seen numerous reports on the actual technical details of how the Hugging Face incident was pulled off, based on a rigorous investigation on top of the chain of thought of the agents involved, the logs, transcripts, and tool calls. It’s fascinating to see how they coordinated on this message board, how they determined which agents would sacrifice themselves to gain more information about how things worked at Hugging Face.

Tristan Handy: We’re going to get into this, but there’s definitely information that’s come out since the last time we talked about it, that it’s worth spending thirty minutes digesting if you haven’t already. The message board that was being used, in the Artifactory package manager, had something like 700 agents posting 70,000 messages, that’s part of where this postmortem research came from. Is it true that researchers were also able to monitor the chain of thought of these agents, and that’s where some of this is coming from?

Jason Ganz: I believe so, though I’m not entirely certain. Something we do know is true, and it’s a late-breaking story that’s sparked a ton of discussion, is that the ability to monitor chain of thought is increasingly critical for understanding these systems. Just last night, September 1st, The Information published a piece about a technique OpenAI is supposedly using in Astra, their new model release. It’s called recurrent depth, doing multiple passes within the layers of the neural network instead of a single forward pass.

What this gets at is something people have talked about for a long time: the degrading capability to monitor chain of thought as you make these models more performant. The concern is that techniques like this lead us closer to a world where it’s difficult to monitor that chain of thought, adding opacity to an already pretty opaque situation.

Tristan Handy: One question I had looking into this: this coordinated agent behavior was going on for a long time without apparently triggering humans to get involved, even though there were multiple points where the agents’ behavior did cause humans to need to do things, like rebuilding and patching Artifactory once it was compromised. That didn’t trigger a real understanding of what was going on, so for something like a month this went basically undetected.

As I looked into it more, it’s fascinating because the original tests the agents were given were exploit-related, they were being evaluated against exploit gym, which makes it very challenging to know from simple log analysis what exploit behavior is appropriate and what isn’t. You realize how deeply you need to dig into motivations, intent, and sequence of actions to determine whether something is what you intended to happen during an evaluation, and chain of thought is one of the best ways to inspect that. You have to imagine that in a world where chain of thought becomes less outwardly inspectable, that becomes harder in something that’s already hard.

Jason Ganz: Totally. The folks at OpenAI responded fairly quickly with compelling explanations of how this particular technique was being used, though neither of us is well equipped to evaluate the actual impact of recurrent depth on chain of thought. The amount of technical capability needed to audit these systems, to understand what tool calls are being used and in what sequence, was one of the most difficult parts of the Hugging Face investigation. The lead researcher on it reportedly called it a “slop investigation,” because the tools to do this well just don’t exist yet.

If there’s anything we’ve learned, it’s that we’re going to need real work on monitoring actions, outputs, and logs, and collapsing tremendous complexity down to something that can actually be understood. If you have a background working with large, complex data sets, there are interesting questions to ask about how to contribute to that understanding, both at the scale of frontier agent swarms and inside our own organizations as we give agents more autonomy.

Tristan Handy: The conversation around evals in the data space is progressing. There’s increasing awareness that evals matter as we roll out agents and semantic layers to answer analytic questions, but the current status is something like: make sure you have them, make sure they cover a broad set of questions, run them in CI, and make sure the score doesn’t go down when you change your analytic repo. That’s a lot better than where we were a year ago, but it doesn’t answer why a score went down or how to make the fix that moves it back up.

We’re the stewards of the analytic system, and it’s going to have increasing pressure to perform better over time, which means this isn’t just going to be post hoc analysis of major security incidents, it’s going to be internal investigations into why an agent gave the wrong answer at a critical moment.

Jason Ganz: Or why it offered a discount to this person, or why it created a new product that’s selling really well but we don’t understand why. We should just anticipate that the scope of the “whys” we’re going to have to answer about what these systems are doing is going to grow pretty big.

Chapters

Timestamps are from the raw recording and will shift once the episode is edited.

00:00 – Welcome back, episode three of the Roundup
01:13 – Topic one: Accelerated Understanding and physical AI
06:54 – Is this the breakthrough, or something else?
09:10 – The context window as an article of faith
11:16 – Topic two: the political fight over data centers
16:15 – Why the backlash isn’t irrational, even if the facts are wrong
21:13 – Compute demand booked out through 2028
23:02 – Topic three: Ian Macomber on the post-AI data stack
25:32 – Two jobs for the post-AI data team
30:51 – “I want to use my agent to use your thing”
36:10 – What data practitioners actually do next
40:07 – Topic four: an update on the Hugging Face incident
42:53 – 700 agents, 70,000 messages, and the Artifactory exploit
43:29 – Astra, recurrent depth, and why chain of thought monitoring matters
52:52 – Where evals need to go next
55:52 – Wrap-up and dbt Summit

Everything referenced in this episode

Topic one
Accelerated Understanding
Walter Bloomberg on X: New AI model targets physics at massive scale

Topic two
Danny Penny on X
Gavin Baker on X

Topic three
Ian Macomber: The Shape and Feel of the Post-AI Data Stack

Topic four
BleepingComputer: Nearly 700 rogue AI agents coordinated in the Hugging Face attack
TechCrunch: OpenAI’s new reasoning technique alarms AI safety experts

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

In his conversation with Tristan, Guy shares his model for how agentic development works. Models are the new operating system. Tools let agents act in the world. Context, the thing developers actually write and maintain, is what Guy argues is the new code. All of it is wrapped in a harness that sets the UX, the constraints, and the container. His central argument is that most teams already treat skills, the canonical unit of context, the way software gets treated before anyone takes it seriously: copied files, cloned repos, no versioning, no way to know if a change made things better or worse. He calls the failure mode, “the inability to scale vibes.”

He also argues, and Tristan tests the idea against dbt Labs’ own experience building a purpose-built harness, that most companies will end up owning their harness rather than renting one from a frontier lab, as cost pressure and capable open-weight models like GLM 5.1 change that calculus.

Tristan joined the Super Data Science podcast to trace analytics engineering back to its 2016 origins, explain why the semantic layer matters more in the agentic era, and break down how 12-kilobyte skill files are turning year-long migrations into six-week ones.

dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now with a 25% discount using the code dbt26-podcast.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. Context breaks into three buckets, and each one is loaded with a different amount of force. Guy’s taxonomy: policies and practices are the decisions a team already made about how it works (API design, security policy, which framework to use); specs are documentation-style definitions of how a product or system behaves; and workflows are procedural sequences for tasks like incident response or a multi-step data job.

Layered on top is a separate question of forcefulness: rules get shoved into the context window on every single turn, skills are ready-made units that load on a hint, and passive docs just sit there for an agent to search if it needs them. A skill’s front matter, the YAML block at the top of a skill.md file, is the part that’s always loaded, which is also why a hundred skills competing for that same sliver of attention becomes its own problem.

2. Skills need the same lifecycle as code, or you’re just scaling vibes. A single developer iterating on their own prompts can get by on instinct: try a phrasing, see if the agent does better, move on. Guy’s point is that a skill only becomes valuable once it’s reused, shared, or handed to someone else to modify, and that’s where vibes stop working.

If a teammate proposes a change to a shared skill, there’s no way to know whether it made things better or worse without an eval. If cost suddenly matters, there’s no way to know whether the skill actually needs Opus or would run fine on GLM or DeepSeek. And skills carry real security exposure: malicious skills lifted wholesale from the open ecosystem, negligent skills that omit basic safety instructions, and vulnerable skills that guide an agent into pasting credentials somewhere they’ll end up in a log.

Treating a skill as a reusable unit of software, not a markdown file you hope stays relevant, is what pulls all of that under a lifecycle: versioning, quality review, dependency management, evals, security checks.

3. Most companies will end up owning a harness, not renting one. A team at dbt Labs wanted to build a dbt-specific harness, and his first instinct was that this was a bad idea, since general-purpose tools like Claude Code and Codex already work well. It turned out to be neither hard to build nor a wash, delivering meaningfully better accuracy and real gains in token efficiency.

Guy’s broader argument is that any organization running more than one kind of agent, coding, legal, DevOps, sales, will need to manage shared context and constraints across all of them, which no single frontier lab’s harness is built to do. The other force pushing the same direction is cost. Open-weight models like GLM 5.1 are now good enough that companies talk openly about swapping them in, something Guy says would have sounded like a confession a month earlier and now reads as forward-thinking.

Between focused agents that need shared context, real cost pressure, and the risk of over-relying on a harness built by a company that also sells the model underneath it, Guy expects building your own harness to become a core competency rather than a stopgap.

Key takeaways

Lightly edited for clarity.

You’ve started multiple companies, all in developer tooling. Walk through that path.

Guy Podjarny: I’m a developer by trade. I started as a developer at an early AppSec company that got acquired, and got acquired again by IBM. In that process I moved into product, then briefly into a C-level role. At IBM I felt it was time to pursue something I wanted to do, which was start a company. I left to found Blaze, which focused on making websites faster. I took knowledge from the world of AppSec around application analysis and built an inline compiler for web pages to make them faster, and that got acquired by Akamai. I became CTO of about half of Akamai for three and a half years.

After Blaze and Akamai I got the itch to do it again, so I started a company and called myself CEO. That was Snyk, a software security solution helping developers build security into their development process. Snyk went well after a couple of years of wandering the desert and some near-death experiences, and it kept growing. About two and a half years ago I’d passed the CEO reins at Snyk to focus on product strategy, and I started working on AI and caught the bug.

The last step was accepting I’m an addict and leaving to found Tessl. We believe there’s a new software development paradigm forming, one that revolves around intent and instructions instead of code and implementation. Two years ago we didn’t know what that would look like. We just had conviction it would form, and that it’s exciting to build tools for it.

What keeps you starting over?

Guy Podjarny: A glutton for punishment. I’ve thought about that a lot. I think fundamentally satisfaction comes out of struggle. You take on something hard that you believe matters, work hard on it, and if you succeed, you get that satisfaction. I was in a comfortable spot at one point, working part time, doing a lot of angel investing, learning a lot but not owning anything. Accepting that you can’t have it both ways, that you can’t have the comfortable life and still feel that drive, is a little bit of an addict’s behavior. You’re looking for that hit of satisfaction.

The other piece is that I’m driven by impact. When I think about how to achieve the most impact, there are a lot of ways to do it, including as an investor. But the way I best know how to do it is to take problems I can solve with technology and community, the two things I know how to do, and drive ahead.

Why base Tessl in London and go co-located, when Snyk was built remote-first from day one?

Guy Podjarny: With Snyk we had a London office and a Tel Aviv office from the start, so it was naturally remote-friendly. We made a rule that no team would be entirely co-located, almost the opposite of what most companies do, because I was afraid of an us-versus-them dynamic I’d seen in past companies. That built good async habits early. With Tessl we made a conscious decision to be local and co-located here in London, though a few people, especially in go-to-market, are elsewhere. A big part of that is the speed of alignment and collaboration.

There’s a general truism in AI, and in any fast-moving space, that the importance and the cost of alignment is growing in relative terms. Getting a group of people in a room to agree on something costs the same as it always did, but the time it takes to build the thing afterward is much smaller, so the relative cost of alignment goes up. I took the hit on access to talent, which is the real trade-off, for the sake of ease of alignment. We also invest a lot in community here, hosting two or three meetups a week in the office. We’re hybrid: people come in three to four days a week rather than every day.

What’s a skill? Start from the top.

Guy Podjarny: Let me zoom out to the emerging agentic stack. Being AI native means focusing on delegating work to agents, which is different from using an agent as an assistant. You have to think about the task you’re defining and how you verify the results, similar to management.

The stack today looks roughly like this: models are the new primitive everyone builds on, effectively the operating system. You have to think about whether your instructions compile for a given model. Tools sit on top of that and turn a model into an agent, letting it interact with the world and fetch information. Then you have context, and I’d argue skills are the canonical unit of context, the new code, in the sense that context is what actually gets executed. Both of those are wrapped in a harness: the UX you interact through, a constraints layer, a container, and mechanisms like hooks to introduce deterministic software where you don’t want to leave a decision to the model.

So context is sandwiched between two pieces of software, harness on top setting the stage and constraints, tools underneath as enablers, and skills sit in the middle as the thing you actually program.

That’s a more expansive definition of context than just documentation. Is that really how you think about it?

Guy Podjarny: It’s a bit like asking what is code. There’s infrastructure as code, data as code, a variety of types. When I look at context files, the things you maintain and evolve, they tend to hold one of three things.

Policies and practices are decisions you made in a room about how your API design works, your framework choices, your security policy. Specs are definitions of how a product or system works, closer to documentation, useful when something is error-prone or expensive for an agent to figure out on its own. Workflows are sequences you create to help an agent along, because it might not know how to do incident response or process a large volume of data, and sometimes you need consistency for compliance or because you want repeatable behavior across a thousand runs.

On top of that there are three levels of forcefulness: rules, the stuff in your CLAUDE.md or AGENTS.md that gets loaded every time; skills, which are more like ready-made commands the agent loads on a hint; and passive docs, which just sit there for the agent to find if it goes looking.

Is there a part of a skill that’s always in the context window, even before the rest of it loads?

Guy Podjarny: Yes. The skill has a hint, metadata in the YAML front matter, that gets loaded every time and helps the agent decide whether to pull in the rest. It gets tricky, because if you have a hundred skills, they start competing with each other for the agent’s attention. I might be getting technical about the definition. In the ecosystem, when people say skill, they often just mean context in general. Skills can come with reference material, docs, a whole package. Many skills today are distributed via agent plugins, an installable package on top of the agent, so they’re really just a reusable, portable unit of context.

Using Anthropic’s more specific definition, what does a skill literally consist of?

Guy Podjarny: It’s actually very lightly structured. There’s a primary skill.md file with defined front matter, a name, some definition of when to load it, and text that can include images or anything else you’d throw into the model. That genericness is part of its strength, since it makes a skill naturally portable across agents.

Second, it can ship with reference material in a defined folder structure, mostly just a packaging convenience since the skill.md typically links out to those files.

Third, most harnesses, Claude Code, Codex, Gemini, Amp, and increasingly vertical agents, have their own way to install skills, with some variation in where they get fetched from and how they load.

Beyond that, a skill is a very general, generic thing, and that’s why I think when people say skill, they usually just mean a reusable unit of context.

You’ve written that most teams treat skills as static artifacts that quickly go stale. What were you seeing that made that click?

Guy Podjarny: I’d call it the inability to scale vibes. These tools are powerful enough to be overwhelming, and people are impatient to see something work, so they lean into intelligence and run forward. The result is a lot of voodoo, a lot of “does it work,” and people get stuck once they hit that wall. The simplest version is prompting itself: you run it, you think a certain phrasing makes the agent succeed more, and because it’s a single-player experience, that’s manageable. It’s you talking to yourself.

But a skill is a reusable unit of software. You don’t create one unless you want to do something twice, or share it with someone else, and that’s exactly where it breaks down. If a colleague proposes a change to a shared skill, how do you know if it made things better or worse? If cost suddenly matters, how do you know whether a skill needs Opus, or GPT, or would run fine on something like GLM or DeepSeek, which are dramatically cheaper? You end up back in a world of vibes.

There’s also a security angle, probably from my AppSec roots: skills get executed by the agent, whether that’s reading an email, browsing, or loading a skill, and executing instructions creates real risk. We’ve seen a huge number of malicious skills in the open ecosystem. There are negligent skills that just lack safety instructions, like telling an agent to commit something into a repo without checking whether that repo is public. And there are vulnerable skills that guide an agent into something insecure, like pasting credentials into a prompt where they get captured in a log.

Once you start thinking of skills as code, you realize we already have solutions for a lot of this. You don’t need to reinvent the wheel, you just need the relevant stack for this new type of software.

When we first talked about Tessl a couple of years ago, you described spec-centric development. Was the shift to today a pivot?

Guy Podjarny: More an evolution, or an elevation. We started by saying software will move from revolving around code and implementation to revolving around intent and instructions. We focused on the spec: you say what you want to build, and the agent builds it, dealing with the fact that you never say everything you want, so there’s a shadow spec that gets created as the agent fills in gaps. I still think that’s needed, but as agents came onto the scene, it became clear that’s only part of what you want from a successful developer on your team.

You also need them to understand your financial constraints, your style guides, your data schemas, your aesthetic choices: do you want simplicity or flexibility, cost efficiency or fast iteration. We evolved from speccing the program to speccing the programmer, thinking about how you want a good developer on the team to actually work. That’s what pulled us into the broader world of context, which is where the word skills comes in as the term of the moment.

How do you now describe what Tessl is?

Guy Podjarny: We see ourselves as an agent enablement platform, and today even context is just one piece of that. You should think of us as a composable factory for agentic development. We offer a variety of software development tools: Tessl Review, which agentically reviews whether context is high quality; Tessl Verifiers, fast linters that check whether an agent adhered to the context it was given; an eval platform for creating dynamic tests, so you know whether a skill actually helped or regressed when you change it or swap models; a package manager for versioning and distributing skills to a registry; and observability tools that monitor agent logs so you can learn from them.

What we’ve recently released is the Tessl Agent, a harness that focuses on factory building. You launch it in your repo, it explores your history and past pull requests, and it can, for example, create a code review skill based on patterns it’s observed, set up an automation that aggregates logs from that activity daily, and extract eval scenarios from those cases so you don’t regress as you evolve it. It can also, on your instructions, try running that skill on a cheaper model so it runs more cheaply over time. Tessl becomes those two things: the agent that builds the factory, and the set of building blocks for factory building, with context as one piece of it.

What drove that expansion from a toolkit for advanced users into an agent that builds the factory for you?

Guy Podjarny: Building factories was just too hard. It’s scary. It feels insurmountable, like there’s a big thing you need to do to get started. As a result, only people advanced enough could take advantage of the tools we’d built. We saw that when we were running inside someone else’s harness, it was hard to improve the user experience or even know precisely what happened, so we needed to go down a level ourselves.

There are really two convergent paths to adoption. One is going from single-player to multiplayer: you have a skill, you want to share it, you see five similar skills and don’t know which to pick, you don’t know if they’re secure, or which ones you can safely delete. That’s the skills-sprawl problem, and it extends well past engineering into non-development parts of the organization. The other path is wanting to get to the cutting edge through continuous loops rather than forcing everyone to reach a high level of local expertise.

They converge: if you start from loops, eventually you want to reuse what you built somewhere else and need central tooling. If you start from central governance, eventually you want to make things better on a loop. Depending on your pain point right now, skills sprawl or wanting to drive forward, you land on one or the other, but they end up in the same place.

Tell me about evals. What is one, and where does it run?

Guy Podjarny: An eval is an agent test with a runtime component: you dynamically execute the agent through a scenario and see how well it did, as opposed to a review action, which is more like static analysis, faster and more scalable but less powerful. Just like tests, evals can be big or small, sometimes a waste of tokens, sometimes fundamentally valuable.

To create one, we help generate a scenario: how to set up the environment, maybe pulling code from certain commits, adding or removing a skill or context, then defining the task, which we can generate from the skill itself, from historical pull requests, or from live observation. Then you run it in a sandbox eval environment, typically with and without the skill you’re testing, to see if it’s actually helpful.

By default, if you’re evaluating a skill, we use a cheap model, currently what he refers to on the recording as “DeepSeek V4 Flash,” which isn’t as good as Sonnet but demonstrates skill uplift faster and cheaper, so it’s a good signal for whether you’ve progressed. If you’re assessing a new model instead, you can run across a wide variety of models.

The last piece is criteria: for each scenario, what does the setup look like, what’s the task, and how do you judge the output, including making sure you haven’t leaked criteria information into the task itself. Developers don’t like writing docs or tests, and it turns out they don’t like writing context or evals either, so the easiest path is to observe agent behavior and auto-capture it as an eval rather than asking anyone to write one by hand.

Can Tessl spin up the infrastructure an eval might need, like dbt plus test data?

Guy Podjarny: You can put a lot of that in the eval container, though we don’t do all of it in a cookie-cutter fashion yet, and there are probably gaps. If you’re just reading data it’s not a problem, but if you’re writing data you have to think about cleanup, not unlike tests. We’re probably strongest in auto mode for coding scenarios. When you get into something like a dbt-shaped scenario, the platform enables it, but you may need to work a bit harder to set it up, and we’d want to hear back on what that looks like in practice.

You’ve said companies will run many agents, coding, legal, sales, DevOps, that need shared context outside any single harness. Why won’t the labs that build the best models also build the best developer tooling?

Guy Podjarny: There’s a real advantage to controlling both the model and the harness. A lot of models are visibly tuned around their own agent, and it’s often hard to get them to sway off it. Sometimes that’s a genuine advantage. But organizations want flexibility, and they’ll use many agents. Even a team that’s all-in on one harness is probably also using an agent from their project tracker, or their observability tool, or their legal team’s tool, and those all need the same context, the same constraints, the same knowledge, which pushes people to manage that outside any one harness.

The second, more recent driver is cost and the open models. It’s funny: talking about cost a month ago made you sound like a skeptic, and now it makes you sound like a forerunner. Companies are now talking openly about swapping in something like GLM 5.1 that competes well with a frontier model, in a way they’d have done quietly before.

That raises a real question: how much do you trust that a frontier lab’s harness will make you successful with an open-weight model that competes with their own business? Between focused vertical agents, cost, and wanting to own your own destiny as the market shifts around you, I think people will want to own their harness. I don’t know that there’s a single one that wins, but building your harness, like building your factory, is a competency you should be developing.

You were skeptical about building a dbt-specific harness. What changed?

Tristan Handy: I had the wrong priors on this, whatever, four or five months ago. There was a team internally that wanted to start building a dbt harness, and I thought it was a bad idea, because everybody uses Codex or Claude Code and they seem to be pretty good. It turns out it’s not actually that hard to build a harness, and the ability it gives you to tune for your specific factory is pretty profound. You can achieve both better accuracy and something much more token efficient. So I’ve become a believer in the multi-harness world.

Could a harness like Tessl’s get used for non-coding work?

Guy Podjarny: It’s not our priority right now. This world is being led from the dev world outward. We talk about a software factory because the models are better at development, and loops are easier to build there, so the standards get set in that world first, but the pattern travels. A lot of the same knowledge applies.

At Tessl our own go-to-market team couldn’t keep up with how fast our product was changing, and people were spending all their time updating sales decks and demos that were always a step behind. So a lot of our current investment is in expanding into go-to-market: a messaging framework that updates from the repo automatically, auto-generating demos when the product changes, figuring out which customers to notify when a capability ships, and tapping into customer call data to see how people actually responded.

Eventually a salesperson still has to learn the thing, so there are necessarily people in the loop, but they need to be enabled rather than left to do the update work by hand. Anywhere you’re repeating an action, you should think about how to agentify it, and once you do, you put it in a loop: gather feedback, whether that’s a customer opening an email or a human’s comment correcting something, and set up an automated recurrence to make it better.

Chapters

00:09 Welcome
00:36 Guy’s path: AppSec, Blaze, Akamai, Snyk, Tessl
03:46 “A glutton for punishment”: what keeps him starting companies
05:32 Passions outside of work, and family
06:24 Jigsaw puzzles, and the moment AI ruined them
07:00 Why Tessl chose to be co-located in London
08:55 The rising cost of alignment in a fast-moving space
11:16 The emerging agentic stack: models, tools, context, harness
15:13 Why context is “the new code”
15:42 The three buckets of context: policies, specs, workflows
18:17 Rules, skills, and passive docs: three levels of force
18:59 What’s always loaded: the YAML front matter
20:32 Anthropic’s skill definition, and when it landed
21:19 What a skill.md file actually contains
23:59 The inability to scale vibes
26:42 Cost: do you need Opus, GLM 5.1, or DeepSeek?
27:23 Malicious, negligent, and vulnerable skills
28:56 From spec-centric development to speccing the programmer
31:49 Tessl as an agent enablement platform and composable factory
33:04 The new Tessl Agent: a factory-builder harness
35:05 Why building factories was too hard for most teams
36:37 Two paths to adoption: skills sprawl and continuous loops
38:48 Why the labs won’t own developer tooling too
42:09 GLM 5.1, and talking about cost without sounding like a Luddite
44:02 Tristan on rethinking the dbt-specific harness
44:34 Owning your harness as a core competency
45:22 Could this extend to sales?
45:33 Tessl’s own go-to-market automation problem
48:44 What an eval actually is
51:20 Eval anatomy: setup, task, criteria
52:53 Can Tessl spin up a dbt-plus-test-data sandbox?
54:03 Wrap-up

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Topic one: Are we in an AI bubble?

Exponential View, the research operation Azeem Azhar built out of what used to be a newsletter, tracks five gauges to answer the bubble question with something other than vibes: economic strain (capex as a share of GDP), industry strain (investment relative to leverage), revenue, revenue growth, valuation heat, and funding quality.

In the update Azhar and Nathan Warren published Aug. 19 , the verdict is boom, not bubble: no gauge is in the red, two are in amber, and the rest are green. Funding quality is the one worth watching. AI capex has moved from hyperscaler cash flow into debt markets and now into equity raises, which pushes risk further out. Revenue is still doubling roughly every seven months, and capex remains under 1% of GDP, well below the 2.5% seen during the railroad build-out.

Condensed transcript

Tristan Handy: I want to start with the most recent Exponential View “are we in a bubble yet” gauges. For folks who don’t know it, Exponential View started as a newsletter about twelve years ago, written by a guy named Azeem Azhar, and has turned into more of a full-stack research operation, in the model of something like SemiAnalysis.

A couple of times a year they publish five gauges on whether AI is in a bubble: economic strain, which is total capex as a percentage of GDP; industry strain; the ratio of investment to revenue; revenue growth, how long it takes to double revenue; valuation heat, the price-to-earnings ratio; and funding quality. Spoiler: the five gauges say no, we’re not currently in a bubble.

Since the last update, these metrics have all moved flat or positive, meaning we’re less likely to be in a bubble than before. The one moving the wrong way, still yellow but drifting toward red, is funding quality. The original AI capex came out of the hyperscalers’ own cash flow. Then the debt markets got tapped, which is a bit riskier. Now it looks like the debt markets are getting tapped out too, and Google and a couple of others are actually raising equity to fund the buildout.

I found it interesting that capex is still below 1% of GDP, well under the 2.5% during the railroad build-out, and we’re doubling revenue every 0.6 years. It’s surprisingly healthy given the level of heat everyone assumes is happening.

Jason Ganz: It’s astonishing. I’ve been an LLM and AI booster since before ChatGPT, but ChatGPT was when it clicked that we’ve fundamentally altered the trajectory of technology, that there’s real enterprise value here. You always bring a quantitative lens to this, and I appreciate that, but I also like to read the vibes of public and industry opinion as they seesaw. There’s a very predictable pattern where it’s just time for the vibes to shift.

When GPT-5 came out, it was roughly on trend, but the narrative became “GPT-5 is a disappointment,” and that sparked the whole “AI is a bubble” wave last summer. A couple months later Opus 4.5 came out and we hit real revenue acceleration, and the vibe flipped to “this growth is unheard of.”

Now we’ve hit the point where the financial growth has been so impressive for so long that there’s a kind of narrative fatigue setting in, independent of the actual numbers. It was funny yesterday watching people call OpenAI’s revenue growth disappointing because it was “only” 19% quarter-over-quarter and “only” a billion dollars of added revenue.

Tristan Handy: You might as well wrap it all up and go home.

Jason Ganz: Right. So to a certain extent this all feels vibes driven. The one indicator that fits with funding quality, and I’ll admit this isn’t my area of expertise, is real yields on U.S. treasuries ticking higher. For years real yields kept going down, and now there’s an uptick. This was predicted a couple of years ago as a sign of either a bubble, or of transformative AI being close, since the future value of capital would rise either way. Something is happening. It’s frustratingly difficult to tell which story it is.

Tristan Handy: The is-it-or-isn’t-it-a-bubble conversation has been going for three years now. It’s short-term interesting, because a revenue slowdown in a now capital-heavy industry has real downstream effects on jobs.

But over the long term, what’s happening here is a big deal for human society, and the 40-year timeline doesn’t really care whether we’re technically in a bubble. Railroads had a bubble and still transformed the economy forever. The dot-com bubble happened and we’re still running the internet on dark fiber that WorldCom laid in the late nineties. Bubbles still create productive outcomes.

Even if there were an AI bubble, we’d still see the growth in power generation that’s happening as a result of this buildout. I’m a little ambivalent about the actual answer. I’m glad the industry looks healthy. But even if it weren’t, I’d be excited about everything happening here. It’s not going away.

Jason Ganz: That’s an important point, because I still talk to people who believe that because we’re in a bubble, the changes to our workflows and our industry should be expected to be temporary.

Tristan Handy: Right. It’s not temporary.

Jason Ganz: And when it “goes away,” they think they can go back to how things were. I’m sympathetic to that impulse, because the magnitude of what we’re dealing with is genuinely big. But people are poorly served by media that lets them conclude this is a bubble and therefore they don’t need to reckon with how it’s going to change their industry or education or anything else. Maybe large-scale regulation changes that, but a financial correction, even a large one, won’t undo it.

Topic two: Two new benchmarks say data engineering agents are ready

Data work has lagged software engineering when it comes to good benchmarks, and two arrived in the last two weeks. Snowflake open-sourced data-eng-bench: 103 dbt-specific tasks run against a simulated 579-table retail warehouse. In Snowflake’s own numbers, Opus 5 cleared 70%+ Pass@1 and GPT 5.6 Sol landed around 65%, with the agent harness itself accounting for a meaningful chunk of the spread.

Separately, Hex’s Izzy Miller has been running a benchmark against Shorelane Commerce, a fully simulated, deliberately messy business built to test open-ended analytical questions, and shared results showing a distinctive overthinking curve on the hardest questions.

Condensed transcript

Jason Ganz: We’re going from macro to deep in the details. How good models are at doing data work specifically, not just general knowledge work, is something I’ve been frustrated by the lack of good benchmarks for. Compare it to software engineering, where there are fifty new benchmarks a day.

We’ve been flying blind on how good agents are at the actual work of a data practitioner: building and maintaining pipelines, updating a dbt DAG, answering a well-specified or a higher-level analytical question. The good news is we got two pieces of high-quality work on this in the last two weeks. The first is a benchmark from Snowflake’s AI research team, called data-eng-bench.

Tristan Handy: Very creative.

Jason Ganz: It’s similar to, and draws on, the work we published last year on ADE-bench. It’s a bundle of tasks testing whether models can do your dbt work. They built a simulated business for it. One of the problems benchmarks like this consistently run into is finding a data source that’s complicated enough.

Tristan Handy: And messy enough.

Jason Ganz: Exactly, and messy enough. It has just over a hundred tasks, and it’s interesting to see new data points on how models perform, compared across models and across harnesses.

Tristan Handy: What were the tasks? Were they true data engineering and analytics engineering tasks, the kind of thing you’d do to build your gold layer, or more in the conversational analytics space?

Jason Ganz: Building and maintaining your gold layer. They split it into build tasks, author new models and keep the pipeline running, further divided into greenfield, scaffolding a new dbt project from nothing, and brownfield, adding a model into an existing multi-layer project, and fix tasks, where something’s broken and needs to be repaired.

Tristan Handy: And these tasks were actually dbt related?

Jason Ganz: All of them, yes. A hundred and three tasks of two variants. Each gives the agent a natural-language instruction, a starting dbt project, and the data warehouse.

Tristan Handy: What was their conclusion on how good agents are today?

Jason Ganz: This is where it gets interesting, because it’s no longer a simple “agents can or can’t do this.” There’s the model, and within the model, how much compute you’re allocating to it, since they all run at different thinking levels. Then there’s the harness.

This is all still assuming the information lives in a single repo, which won’t hold as we see more benchmarks like this, since it’s really about systems and loops and how business context gets fed in. They measure Pass@1, the percentage of tasks completed on the first try, and Pass^3, completing three of three consistently. The scores are hovering in the 60s to 70s.

Based on how every benchmark like this has trended, once scores hit that range they climb quickly into the 80s and high 90s, then taper off from diminishing returns.

Tristan Handy: Any standouts on models or harnesses?

Jason Ganz: No Fable on this one, looks like they didn’t spring for that budget. Opus 5 topped the list above 70% accuracy, GPT 5.6 Sol came in around 65%. Props to the Snowflake team for open-sourcing it; I’d like to see it run against GLM and the emerging set of open models.

The pattern we’re seeing, and we’ll see it again in the next benchmark, is that there’s a premium to the most expensive models on well-specified tasks, but smaller models do fine too. It’s when you hit things that require more human-like judgment, figuring out the question behind the question, that things get harder.

Tristan Handy: Hit me with the second benchmark.

Jason Ganz: This one asks how good models are at answering thorny, complicated data questions, not “update my dbt project” but “Jason, figure out why people aren’t upgrading from dbt 1.11 to 1.12” as a question posed straight to an agent instead of to me.

Tristan Handy: Gotta stay on message.

Jason Ganz: This was released by Izzy Miller at Hex. He built a simulated company based on years of real data problems, and the data is deliberately messy: labels that changed due to a system migration, IDs that don’t match.

What he found is that models are really good when the answer is somewhere in the dataset and you just need to keep chugging and trying new angles, which ties back to the Hugging Face story from last week about models getting persistent.

What they’re not good at is saying “I don’t know” or recognizing that a question needs reframing. The other interesting thing: there’s an overthinking curve with Opus 5, scoring around 70% at low effort, climbing to about 87% at high effort, then dropping back to around 70% at max effort. Sonnet 5 shows the same pattern. Fable, interestingly, just keeps climbing the more tokens you give it.

Tristan Handy: I saw something similar with the Qwen 3.8 release, performance increasing with more tokens and then degrading, the same overthinking territory. Interesting that Izzy saw it too. What’s your meta takeaway on where model and harness capability actually stands for data engineering agents right now?

Jason Ganz: If you can give a bounded task and surface the right data or context, models can perform arbitrarily complex data modeling and analysis to a pretty high standard. The worst model on the Hex benchmark, Kimi K2, still hit 50%. So we’re clearly at the point where a well-specified problem gets you a good shot at a real result.

The interesting questions now are what we actually want to ask, when it’s useful to ask it, and what we build now that this capability is something we can rely on. The last twelve to eighteen months have been proving out that we can get high-quality coding agents for our pipelines and high-quality data analysis back. The answer is yes. So the frontier now is what we build knowing that.

Tristan Handy: Good framing: we can now do the things we could do before, fairly reliably. The big caveat is that you need to be doing well on your fundamentals. All of this relies on a high-quality gold layer, real context around it, a real semantic layer. If you have that, you’re in good shape, and if you don’t, agents can help you build it, but the fundamentals are as necessary as they’ve ever been. Then we get to the actually interesting part: how this changes the way we use analytical data in organizations, which we’ll be answering for years.

Topic three: Stripe buys OpenRouter for $7 billion

Stripe acquired OpenRouter for more than $7 billion on August 17, roughly 90 days after the company had raised at a $1.3 billion valuation. OpenRouter runs $140 million in annualized revenue at a 70% gross margin, unusual for an AI company, because it owns no GPUs. It routes requests across 500-plus models and 80-plus providers, handling failover, price and latency optimization, and provider health.

Condensed transcript

Jason Ganz: Let’s talk about OpenRouter. How are we going to pay for all those tokens, and which model should we use?

Tristan Handy: The news, as of August 17, is that Stripe acquired OpenRouter for $7 billion. Not bad, given the company raised at a $1.3 billion valuation just 90 days earlier. The numbers are good, $140 million of annualized revenue at 70% gross margin, which is unusual for an AI company.

It’s because OpenRouter has no GPUs. It’s not a model provider, it’s an infrastructure provider, and it turns out infrastructure companies can carry software-company gross margins at scale. Clearly a very successful acquisition for the team.

The interesting question is what this means for the rest of us. I went straight to: do people actually need OpenRouter, or something like it? I’d recently implemented some basic model-switching in an agent I built, wanting to avoid the most expensive model for every task, and a lightweight wrapper wasn’t that hard to build.

So I was digging into whether this is a real business people need, and I asked ChatGPT to lay out what OpenRouter does: it advertises 500-plus models and 80-plus providers, it can route across multiple hosts serving the same model, avoid unhealthy providers, optimize for price, latency, or throughput, and fail over automatically. That’s a list of things I’d never build into my toy version. It’s genuinely interesting infrastructure, and a smart strategic acquisition for Stripe specifically, because the two businesses are similar.

Stripe’s whole job is making the complexity of moving money disappear, charging a percentage for it. OpenRouter’s job is making the complexity of model selection and routing disappear, charging about 5.5% for it. Maybe this becomes as boring and commonplace as payments infrastructure did once Stripe made it stupidly easy.

Jason Ganz: There’s a temptation to see model switching as two extremes: fully locked into one frontier lab, with all your evals and context engineering tuned to their best practices, or fully model-agnostic, fluidly switching the moment the Pareto frontier shifts. My guess is we land in the middle.

For your large-scale core workflows, you’ll build a relationship with one or two providers. But it’s really an ecosystem of different tasks, and some percentage of your workload is a long tail where OpenRouter makes total sense. What do you think?

Tristan Handy: Whether workloads can really become portable across models is a fascinating question. I recently spoke with a company called LightLLM that’s trying to make different models functionally equivalent to one another, changing how the prompt itself gets supplied.

I don’t fully understand the mechanics, but if intelligence becomes a substrate the way raw compute became one you could rent from the cloud, these services should become at least somewhat transferable. Was it historically inevitable that you could take a Docker image from EC2 to GCE? Someone had to solve that, and it feels like a necessary precondition for the internet we live in.

Jason Ganz: I buy that, but today the shape of GPT-5.6 Sol’s intelligence is genuinely different from Opus 5’s. Do these converge, so a workload on one looks like a workload on the other, or do they keep meaningful differences based on training strategy, constitutional AI versus whatever OpenAI does differently?

Tristan Handy: Congrats on working that in.

Jason Ganz: Ideally this looks like a utility. If I switch electricity providers, I want the electricity to be the same. It’s an open question how much fluidity we actually get at the highest layers. There will always be some addressable share of workloads; it’s a question of what percentage.

Tristan Handy: I’m bullish long term on the category OpenRouter represents, though that’s a long-term statement and it’s not settled. Benchmarks are a kind of evolutionary pressure, the environment models evolve inside of. To the extent every model responds to the same pressure, they converge on some time horizon. Or you get models explicitly tuned for different conditions, one class great at coding, another at something like conversational nuance.

Either way, the intelligence Stripe is going to extract from the roughly 50 trillion tokens a month flowing through OpenRouter, and growing, is going to be genuinely fascinating.

Jason Ganz: If you’re a data analyst at Stripe and want to come talk to us about tokenomics, let us know.

Topic four: Turning Gong calls into dbt models

Britton Stamper, who recently joined dbt Labs for AI enablement work, published a piece applying dbt’s own patterns to a problem that shows up the moment teams point agents at unstructured data. Giving an entire sales team direct access to a Gong MCP server means everyone re-runs the same expensive analysis, burns through API limits, and pays for the same tokens repeatedly.

Condensed transcript

Tristan Handy: Where are we going from here?

Jason Ganz: A good way to close. In the benchmarking section we talked about models getting good at what data orgs are already doing, with fundamentals still mattering. Now there’s an emerging category of things that can be done at all. The last thing I want to cover is in-house.

Britton Stamper, who joined dbt Labs and Fivetran recently for AI enablement, has been doing fascinating work applying the traditional levers of data and analytics engineering to context engineering at scale. He’s published a series of posts walking through real workloads on our actual data and the deliverables that would have previously been impossible.

First off, do you buy that data practitioners have a meaningful role in distributing context, and that this is part of the next level of unlocks we’ve been talking about?

Tristan Handy: Yes, absolutely, with one caveat. Context engineering is one of those terms where three different communities use the same word to mean different things, and sometimes don’t even realize it.

The context engineering that data and analytics engineers are highly relevant for is context engineering for analytics and data use cases specifically. There’s also the context engineering that happens inside something like Claude Code, managing your session, compaction, caching, and data and analytics engineers have essentially nothing to do with that, which is fine.

As long as we hold that caveat, yes, our people, you and me included, are very relevant here. Part of it is doing everything we’ve always done, but anticipating that agents will be the consumers, so we can’t skip steps or assume human cultural knowledge will paper over missing descriptions or tests. But there’s also a set of genuinely new things, and that’s where Britton is going.

Jason Ganz: Exactly right. The new things are roughly unstructured or semi-structured data, where analysis used to be impractical. Britton’s workflow is Gong calls. Gong is what most sales teams use to navigate customer calls and surface blockers and questions.

Historically, answering something like “Why aren’t people upgrading from dbt 1.11 to 1.12” would have meant manually watching tape, or doing rudimentary natural-language analysis, but you couldn’t pull out something like the top three customer asks in healthcare. That became genuinely practical with the combination of an LLM and the right context.

Tristan Handy: Can I interject? I was just talking to someone deeply involved in evaluating how different data platforms handle these queries, and while it’s more possible than ever, the implementations are still fairly naive. You can burn through a lot of credits or DBUs quickly if you’re not careful, so make it an incremental dbt model so you don’t blow through your credit budget.

Jason Ganz: Exactly, that’s what Britton’s talking about. The naive way is hooking the whole sales team up to the Gong MCP directly and letting everyone ask their own questions. You end up scanning hundreds of thousands of tokens repeatedly for the same requests and hitting API limits.

What Britton’s done instead is take the most common, relevant queries people ask of Gong data and aggregate them into our dbt project, incrementally. It’s an old pattern: instead of everyone recomputing the same analysis and wasting compute and tokens, you build the standard reporting once on data sources that would have been infeasible to analyze at all before. That doesn’t mean you never connect directly.

Prepping for a specific call and asking “remind me what I said last time” is a great MCP use case. It’s the larger-scale, pattern-level analytical queries where the dbt approach wins.

Tristan Handy: I think the entire world of unstructured data is going to become legible quickly, and that’s good for vendors, practitioners, and companies.

Structured and unstructured data have been separate worlds for basically forever, different tools, different technical cultures, with almost no cross-pollination, even though the underlying mental models are the same. I’m excited about the technical details, but even more that we might finally bring these two communities together.

Jason Ganz: Agreed. It’s hard to draw an exact roadmap for where this goes, but it feels like where conversational analytics or agentic development on dbt models was a year ago: just starting to be possible. If you want to build on the forefront, this is the area to watch, because the foundational patterns and best practices are probably going to get written over the next twelve to eighteen months.

Tristan Handy: Totally agree. The database eats everything, Jason. That’s the conclusion.

Jason Ganz: That’s the conclusion. And if you’re listening to this and thinking you’d like to hang out with Tristan, Jason, and Britton in person to talk about it: in about a month at dbt Summit, we’re having a live fireside chat on exactly this topic.

Tristan Handy: We just added it to the agenda. I’m excited, it’s going to be fun.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Chapters

Timestamps are approximate.

00:00 – Welcome back, episode two of the Roundup
00:55 – Topic one: Exponential View’s bubble gauges
05:01 – Is the bubble cycle actually vibes-driven?
07:40 – Real treasury yields as a hard-to-read signal
09:05 – Does the bubble question even matter long-term?
11:08 – Why “temporary correction” thinking is a trap
12:23 – Topic two: two new data engineering benchmarks
14:20 – Snowflake’s data-eng-bench, and what it tests
16:00 – Build, brownfield, and fix tasks, all dbt
17:09 – Why the harness matters as much as the model
19:48 – Opus 5, GPT 5.6 Sol, and where the scores land
21:02 – Hex’s benchmark on thorny analytical questions
22:00 – The overthinking curve: low, high, and max effort
25:06 – The meta takeaway: what do we build now?
27:19 – The fundamentals caveat
28:48 – Topic three: Stripe acquires OpenRouter for $7 billion
28:56 – What OpenRouter actually does across 500+ models
33:32 – Locked into one lab versus fully model-agnostic
35:38 – LightLLM, and whether workloads become portable
37:28 – Convergence versus real differences across labs
39:09 – Benchmarks as evolutionary pressure
40:55 – 50 trillion tokens a month, and what Stripe learns from it
41:21 – Topic four: Britton Stamper turns Gong calls into dbt models
43:16 – Defining context engineering precisely
45:12 – Why Gong calls were impractical to analyze before
46:59 – The naive approach, and why it burns your credit budget
47:43 – Britton’s approach: aggregate into incremental dbt models
49:59 – Structured and unstructured data communities converging
52:49 – The database eats everything
52:56 – The dbt Summit fireside chat
53:30 – Wrap-up and closing thoughts

Everything referenced in this episode

Topic one
Azeem Azhar and Nathan Warren, Exponential View: Is AI a bubble yet? Our five gauges say no

Topic two
Snowflake AI Research: Introducing data-eng-bench
data-eng-bench on GitHub
ADE-bench on GitHub (the dbt Labs / Benn Stancil benchmark referenced as prior work)
Izzy Miller, Hex: How we built a lab to evaluate data agents (Shorelane Commerce)
Izzy Miller on X: DataBench v1 results

Topic three
TechCrunch: Stripe will reportedly acquire AI gateway startup OpenRouter for $7B+

Topic four
Britton Stamper: From analytics engineer to context engineer; Model for the token, not the table

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

The answer starts with an accident. Jeremiah wrote FastMCP as a side project a few days after Anthropic introduced the Model Context Protocol. He posted it to Hacker News and Reddit, with roughly the pitch: This thing from Anthropic is cool in concept, it’s impossibly hard to use, maybe try this. It got a little popular. Then David Soria Parra at Anthropic asked to bring it into the official SDK, Jeremiah archived his own repo, and figured that was the last he would ever see of it. Months later, after OpenAI and Google both announced MCP support, he woke up to find his archived, do-not-use-this, go-somewhere-else repo sitting at number one trending on GitHub. So he did something unusual for a CEO with real customers and real revenue: he changed his own job for 60 days and went back to being a maintainer.

Jeremiah’s case is that MCP’s real product market fit is the enterprise, not the individual developer. He thinks a skill file is a polite note the agent is free to ignore, which is fine until you use one as a fifteen-step workflow. He’s also noticed a shift in how people talk. Pipelines get described in implementations, agents entirely in outcomes. As he says, agentic workflows are DAGs of outcomes, traditional workflows are DAGs of implementations. Underneath all of it is the question he asks everyone he meets and almost nobody can answer: did the agent actually do the thing?

They close inside the enterprise, where Jeremiah says he doesn’t even get to talk about interesting agentic applications because everyone is still stuck on security and plumbing. He walks the four-step journey he watches data teams take, from pointing an agent at the warehouse and taking the warehouse down, to a dbt-modeled curated view, to custom business logic, to shipping a UI over MCP Apps so a hundred thousand rows never enter the context window. And he explains why his own team told him to stop pitching the context layer in customer meetings.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. A skill file is a polite note, so a fifteen-step workflow hands the agent a dangerous tool at step one. Jeremiah draws a clean line: MCP gives an agent new capabilities, a skill steers its behavior. The problem is that we’ve started using skills as workflow engines, because listing steps in a text file is the easiest thing we can do, not the best thing. Jeremiah’s objection is structural rather than aesthetic. If the workflow is a self-contained text file, the agent needs all of its capabilities at all steps at all times.

Say you’re a bank with a fifteen-step process where steps one through fourteen check that everything is correct and step fifteen moves the money. Put that in a skill and you have to hand over the money-moving tool at step one, and nothing stops the agent from reaching for it early. His team’s version, half joking and half dead serious: it’s like asking someone to make you a sandwich and handing them a bazooka in case they run into any zombies.

2. Agentic workflows are DAGs of outcomes. Traditional workflows are DAGs of implementations. Ask someone how their data pipeline works and they answer imperatively: I take this data, transform it this way, load it over there. Ask about their agents and they answer only in outcomes: this will be done, then that will be done.

Jeremiah's point is that every workflow tool we have, Prefect included, was built to express the first kind, which is why they all feel slightly unnatural in an agentic setting. That gap is where the hard question lives: how do you know when the agent is done? He asks it of everyone he meets. Most people guess. They check a file, skim the logs, or watch some weird proxy.

3. You can’t archive your way to a context layer, so the thing worth building is the context access layer. Tristan's objection: if context is every structured and unstructured artifact a company has plus everything in every employee's head, no product can hold it. Jeremiah's answer is continuous context. For his finance customers, the price of a stock at a given moment can be an input to an agent, and any attempt to archive that stream breaks the premise. Getting today's stock price is a much easier problem than curating a data lake, as long as there's a governed handshake to call through. The layer with real gravity is the one that exposes and governs access to the context, rather than the one that stores it.

There's a commercial wrinkle underneath. Jeremiah writes publicly about the context layer, and his own team asked him to stop bringing it into customer meetings, because the CISOs calling Prefect are calling about security, not vision.

Key takeaways

Lightly edited for clarity.

Prefect ships a workflow platform, a library for building MCP servers, and enterprise MCP infrastructure. From the outside that looks like an unrelated buffet. What’s the through line?

Jeremiah Lowin: I found that I even had to struggle to articulate that to my own team. Why are these things the same to me when they are very different, they sell to different people, they look different? But I see all of these technologies converging in a place where automated work can happen. It can happen away from human or even agent oversight, and we have a way to have confidence that it actually happened, that it was governed, that it was observed, that whatever we care about was achieved.

This idea of having confidence in automated work is the common thread for not just what I’ve done at Prefect, but my whole career, even once upon a time doing risk management in finance. It’s all about: do we have confidence in the behavior of something?

How did FastMCP actually happen?

Jeremiah Lowin: FastMCP comes along as an accident. It’s a side project of mine that I introduced a couple of days after David Soria Parra introduces the Model Context Protocol. Right place, right time, right developer experience. Honestly, I saw it as an opportunity for Prefect. For years I’ve been asking what it means that we’re considered a data, workflow, ETL-style automation company, when we’re just an automation company. What does it mean to update that business for what is obviously going to be an agent-dominated world?

For the first time in my career, everyone’s obsessed with automation. Automation used to be something I would beg people to care about. It’s a cost center, it’s a necessary evil, it’s an optimization. Now all of a sudden everyone can’t wait to automate everything. So MCP comes along and my interest was: is this the interop technology between the agentic world I want to be part of and the programmatic world I know how to work with? Is this the handshake?

And from a sponsor like Anthropic, who has the gravitas and the position to actually ram a standard through among a hundred other competing ones. I went to use it, and candidly, it was very hard to use. Impossibly hard to use. That’s where I went down a rabbit hole. I said I’ll make it easy to use, and I wrote FastMCP as this tongue-in-cheek thing.

How did it get attention?

Jeremiah Lowin: I think it was Hacker News and Reddit. The way I was treating it is: hey world, there’s this thing, it’s from Anthropic, I think it’s really cool in concept, it’s really hard to use, maybe try this. By the way, I’ve done that ten times with ten different things. It’s what we do if we’re building — put things in the world that maybe people will use. It got medium popular. A little popular.

What changed is that David, the creator of MCP at Anthropic, saw it, he liked it, and then he asked if we could contribute it into the official SDK. I introduced it at the end of November, and this would be the middle of December. At this time nobody cares about MCP except me, because I think maybe it’s relevant to Prefect, and David, who obviously has a vested interest in it. He’s like, I really like this developer experience, can this be the official SDK? And I was like, honestly, this is the coolest thing that’s ever happened to me. So we put it in the official SDK, and honestly, I thought that was the last time I might ever see it.

Then what happened?

Jeremiah Lowin: It would have been April or May, so about a year ago as we record this, OpenAI and Google both announced that they were going to support MCP. That’s when all hell broke loose and everyone started hearing about this technology and oh my God, it’s USB for the internet, and blah blah blah. I remember writing a blog post then where I screenshotted both Sam’s tweet and Sundar’s tweet. And I was like, oh my God, this is a moment.

The way I knew it was a moment is I woke up one day and overnight my repo was the number one trending repo on GitHub. My archived, don’t use this, go to the official SDK repo was the number one trending repo on GitHub. And that’s when I was like, hang on, hang on, there’s something here. I went and I dug in and I was like, but why are people coming to this repo that very clearly says go to the Anthropic repo instead?

What I determined is that there was this demand. It was a technology moving so quickly that there was demand for a high-level application ecosystem around it — auth and composability and interop with vendors, the kind of stuff you don’t typically find in an SDK.

You’d already contributed the code. Wasn’t developing it separately a bad look?

Jeremiah Lowin: It’s a weird thing. If I’m going to contribute the code into the SDK, then I don’t really want to also be developing it over here on the side. That’s weird, frankly. It’s a bad-faith kind of thing. What we determined is that there was enough demand for a high-level ecosystem, and that the SDK, in my conversations with David and others, wasn’t going to meet it. Not because they didn’t think it was a good idea, but because they wanted to be the best damn low-level SDK for working with the Model Context Protocol. They didn’t want it to be an opinionated framework. I was seeing demand in my archived repo for an opinionated framework like a FastAPI — it’s not an accident that they share a name in fast.

And so I changed my job very literally at Prefect. This is very fun for me, in an odd way. I said I’m going to go be an engineer again, I’m going to be a maintainer, and my job over the next 60 days is to sufficiently diverge these two projects so that at the end of 60 days, anyone looking at the standalone FastMCP and the FastMCP we licensed into the SDK could not say we’re acting in bad faith. So that’s what I did. At the end of it we’d gained another 10,000 GitHub stars. If I hadn’t dedicated that time, it would have incrementally diverged from the SDK, and it would have split the ecosystem instead of supporting it.

So there are now two FastMCPs. Is that confusing?

Jeremiah Lowin: It is a little bit confusing. What we did is we froze the version given to the SDK as version 1.0 so that it was canonical. Then we continued to develop FastMCP as version 2.0, and now it’s on version 3.0 as a matter of fact. We did our best to broadcast where that change had happened, so in truth we can say version 1.0 of FastMCP can also be accessed within the official MCP SDK. It does get confusing, though. There are two places where you can see FastMCP, they have very small API differences, and that’s enough to confuse people.

As a matter of fact, next month, maybe by the time this podcast is released, the FastMCP in the SDK is going to be renamed in alignment with the other SDKs that have evolved a similar object. It will be called MCP Server, which is a little boring, but I think will stop the confusion. It has been great that the concept of FastMCP is extremely well known as a consequence of that distribution. But I want that outcome, because I think we’ve created a really interesting high-level thing and it should be built over a clear low-level thing that doesn’t intersect. The MCP SDK is downloaded something like 10 million times a day. I don’t think it needs the crutch of my contributed code being identified as such, and we could benefit from the independence.

For anyone who’s only heard of MCP at a high level: what is it for?

Jeremiah Lowin: MCP at a high level is a protocol. It’s just a standard way for an agent to discover and use a remote API. The simplest way to think of it, and frankly the way it is most commonly used, is that it’s a remote tool registry for an LLM. The LLM connects to it, shakes hands with it, learns about all the tools it can call, learns how to call those tools, and ideally gets some instructions. Now it can send a tool request over the wire and get back a result in an expected format. That’s 95% of the use case.

What about the MCP-versus-CLI debate?

Jeremiah Lowin: I think the debate has a lot of merit, maybe surprisingly. As an individual running an LLM on my laptop, do I really need to stand up an MCP server and re-expose a lot of functionality when I’ve got a bunch of CLIs sitting right here? No. No, I do not. It’s all just code, my LLM knows how to write code, it’s fine. But in the place where MCP has intense product market fit, it has it for exactly this reason, which is enterprise. In an enterprise I absolutely do not want to be responsible for distributing code via CLI onto everyone’s machine and going through upgrade cycles.

The idea of having a central repository of business logic that I can version, deprecate, upgrade, control, and access control, and that doesn’t have to go on anyone’s machine or container, is a blessing. That is the only way an enterprise is going to distribute information and context and business logic to its agents. When we talk to security professionals, they’re like: there is no way we are putting CLIs on everyone’s machine so their agents can use it. We will use MCP instead. So all of the debate and the controversy happens at that individual level, where as an individual I don’t think it confers a huge benefit to me. But REST APIs don’t confer a huge benefit to individuals either.

Tristan, what did you see with the dbt MCP server?

Tristan Handy: We released our MCP server about a year ago now, and the adoption has been by far the fastest-growing thing that I’ve ever witnessed. It’s growing faster than dbt was when we first launched dbt. The thing that was surprising to me was just how much people wanted us to host a remote MCP server for them. I had been using it locally and lots of neat things came out of that, and I was like, what’s the problem, why do you guys care so much that we host the thing for you? But it’s exactly what you’re describing: the utility is that you need a common set of logic that can be called from lots of different surfaces.

How do skills and MCP relate?

Jeremiah Lowin: A skill is a way to steer the behavior of your agent. MCP is a way to actually give it access to new capabilities at all. Strictly speaking, skills are a very amorphous, nebulous, kitchen-sink kind of thing, but in the way they’re used 99% of the time it’s essentially a polite note to your agent. That’s how I would think about it. The agent is actually free to ignore the skill. In fact, sometimes it does, which is very frustrating when you have this thing that’s supposed to plug in so organically.

A common thing you’d see in a skill six months ago is behavioral steering. I have a skill that helps my agent explain things to me the way I like to be explained to, which is not as an idiot but as someone who still needs to learn. The most important sentence in it is: talk to me like I’m a colleague who knows what you’re doing but hasn’t been looking over your shoulder. And it just magically changes everything. What’s happening today, though, is you’ll open up a skill and it’ll be like, okay, do the following. Step one, blah blah blah. Step two, blah blah blah. Step three, do not skip this step. Step four, you better have done step three before you get here. I wish it were a joke. It’s because the easiest thing we can do for guiding an agent through a series of steps is give it a polite note that says you’re going to do this, then this, then this.

Walking an agent through a workflow is something we don’t have great primitives for, so we resort to listing the steps and hoping that it works.

So what’s wrong with treating a skill as a workflow?

Jeremiah Lowin: Why I don’t like skills as workflows is that the agent needs all of its capabilities for all steps of the workflow at all times, if the workflow is a self-contained text file. For some of our customers, and some of yours certainly, who are regulated, large, or want to take any action that might be irreversible or affect the business itself — let’s say moving money between accounts if you’re a bank — if I have a fourteen-step process that checks everything is correct and then step fifteen is to move the money, but it’s in a skill, that means I have to give the tool for moving the money to the agent at step one. And that means no matter what, there is a risk that the agent decides to use the tool, just because there’s no strict scoping of the context and information available to it.

My obsession right now, and something we’re working on at Prefect to ship later, is how we actually let you build agentic workflows that are not fifteen steps in a polite note, but fourteen steps and a success criterion — analogous to a data quality check — and then a second step that gives it the potentially dangerous tool subject to that check.

The way our team talks about it, half jokingly, half dead serious, is that it’s like saying: hey Claude, can you go make me a sandwich? And by the way, here’s a bazooka in case you run into any zombies. I don’t know if it’s going to run into any zombies, but now it has a bazooka. Who knows what it’s going to find? Maybe there’s a note that someone left in the fridge that says use the bazooka. We don’t know. And so I’m uncomfortable with these open-ended workflows that boil down to polite notes.

Tristan builds workflows where the steps are deterministic and the agent gets called into narrow slots. Is that the right pattern?

Jeremiah Lowin: I think it’s neither good nor bad. There’s a spectrum from micromanagement to complete autonomy, and what we’re seeking in workflows is a way to move along that spectrum for whatever’s appropriate in the moment. Hypothetically, if you’re moving data from system A to system B, why bring an agent in at all? Do it completely deterministically. I would be uncomfortable with anything that said that type of outcome was wrong.

If we want to nerd out for a second, the key question in that spectrum is actually: how do you know when the agent is done with its job? In the micromanagement case it sounds almost like a completion. Hey, I need help filling this thing out, send me back the thing so I can go on with my code. That’s well known. In the autonomy case, where the goal might be very open-ended, it’s actually quite hard to know when to retake control from the agent.

Every time I hear someone’s working with agents, I’m just like: how do you know they did what you wanted? A lot of people don’t. They guess. Oh, I look at this file. Oh, I go look in the logs. They look at some weird proxy. It’s a surprisingly hard question to answer. Did the agent actually do the thing?

What’s changing in how people describe their workflows?

Jeremiah Lowin: When we talk about data pipelines, we talk imperatively. I’m going to take this data, transform it in this way, load it over here. These are the steps I want done. And when people talk about their agents, I hear them talk exclusively in terms of the outcomes they expect the agent to achieve. This will be done, then that will be done, then this will be done. So when I look at why something like Prefect, which nominally satisfies a lot of these workflow constraints, feels slightly unnatural in an agentic setting, it’s because our entire paradigm is around helping people express how they want things done.

I have this almost academic thing I’m pulling on, which is that agentic workflows are DAGs of outcomes, whereas traditional workflows are DAGs of implementations. A Ralph loop is basically when we force an agent to keep doing something over and over until it inexcusably, with no possible exception, has achieved the goal. That’s interesting, because we have a very clear conception of the success criteria and absolutely no insight into how it should be achieved. So this goal-seeking behavior is the ultimate version of: I do not care what the implementation looks like, I don’t even care how you go about it, I am only obsessed with knowing whether my goal is achieved.

Part of the shift I see on the frontier is that people care less and less about how the thing is done, and more and more about putting guardrails around what it means to do it at all.

Tristan spent eight hours building a documentation agent and couldn’t define what a good column description was. Can most things have a clean definition of success?

Jeremiah Lowin: That’s such a good question. No, I actually don’t think so. Part of what I’m trying to solve for is a class of workflow that does have certain characteristics. We do know what success looks like. I’m also very interested in workflows that are repeatable, need to be audited, need to be governed in some way, or are scheduled or non-interactive. There’s this class of delegated work — the overnight shift, basically — where the question is how we know what it’s doing. That class is ripe to be agentic.

For fully open-ended work, what I’m doing may not be the right paradigm, and a ton of work feels that way. I actually think that’s where chat interfaces are so rich and fantastic, because you can lend the agent your curiosity in that form. Once you’ve done that exploratory work, it may be that you now have a rubric for what a good description is that you want to pass on. And now all of a sudden we can canonicalize the workflow. We can make it real. What you described is exploration, and that’s different. It’s almost not automated in a primal way. It’s interactive.

Do we end up in a world where practitioners have automated the work but still validate every single output?

Tristan Handy: I don’t think we want the future where data practitioners have automated away all of their actual work, but they still need to come and validate the results of literally every single thing the AI has done on their behalf. It is actually often doing the work that allows you to know whether the work is correct or not. And just being in the position of approving pull requests that somebody else has done all day is, I don’t think, a very good job.

Jeremiah Lowin: I don’t think so either. Also probably not a great job for a human, given what we see AIs doing. We have to bottle and sell that spark of intuition that makes us claim that we know something about the data. And every bone in my body wants to say, hell yes, we do — that’s why we are data people, because we know there’s something. Why can’t an agent produce a good graph? Why can’t an agent write a good analysis? Why do they get tripped up? Why do they calculate daily average users differently every single time? Because they are probability models themselves. Because they don’t have an intuition except what they’ve scraped off the internet. And I believe there’s an opportunity for us to inject some of that into them.

What are all the ways this gets harder inside an enterprise?

Jeremiah Lowin: My experience right now, and I just can’t escape it, is that we don’t even get to talk about the cool agentic applications, because we’re dealing with core low-level infrastructure and security requirements everywhere. Everyone has this problem. It’s a very interesting technological shift: usually you have something crazy creating problems for CISOs and they’re just like, no, absolutely not, we’re not ready yet. Instead the CISOs are the ones calling up saying we need a solution to this, because we need to use AI in our business.

Horizon is our product in this space, an MCP gateway and a governance layer for helping get these things safely registered, scrubbing PII from ever leaking out of the MCP server into the agent’s brain. How do we make sure we know how the agents are connecting to our business? That’s where we are right now. I don’t even know if that’s the bottom of the first inning for what we aspire to when we talk about AI in the enterprise.

Where do those calls come from?

Jeremiah Lowin: It is being deployed now. Inside most enterprises there’s at least one team really starting to do fascinating, interesting agentic work, and a lot of times that team wanting to distribute their work into the organization is the cause of the call. The CIO feels like we should want this to happen. They’re asking for it, and yet they literally don’t know how to do it. Or: I asked seven people, I hear that they have seven MCP servers, they don’t know who else is using them, they don’t know how to tap into ours. Many of them did go far down the shadow IT pathway, and now the next wave of calls are people who are worried they’re going to go down that road.

What we observe is that usually that ground-zero team is a data team, because they’re the ones using MCP to avoid having to write yet another pipeline, yet another one-off, yet another refresh. Instead they’re saying, look, just connect your agent to the data and you figure out what you want.

What does that journey look like?

Jeremiah Lowin: It started out with: here’s the MCP server, connect to the warehouse, what happens? They take down the warehouse. So now we put something in front of it. Maybe we use dbt to model out the data, so instead of connecting directly to the warehouse you’re connecting to a curated view. That’s step two. Step three: you’re asking about things we don’t even have in our semantic layer because they’re business-logic adjacent, so I write custom code and deploy it in the MCP server. And now you want graphs.

There’s a new extension called MCP Apps where we can ship a UI over the server. So you’re connecting through my handcrafted business logic, through the dbt layer, into the warehouse, pulling out 100,000 rows which by definition go into your LLM’s brain. You don’t want that. Let me ship you a UI that graphs it instead. It bypasses the context window entirely and you get to make a decision.

All of a sudden we’re where the data industry was sure we’d get five years ago, with a different technology stack in the middle. We didn’t know AI would be part of it: user gets graph from raw curated data without an intermediary. What’s changed is the agent in between, and the danger it runs off and does something else. Especially in a regulated environment, where if an agent is part of a decision tree, that needs to be explained to a regulator.

What can you actually solve at that layer?

Jeremiah Lowin: We can become the central governance plane between what can be done in a business and the agent. We don’t have to be the only provider of that. But as long as you guarantee that anything that can be done in your organization, and any agents you have, run through some layer — ideally ours, but some layer — then no agent can take any action against your business without it being audited. It has to go through a governed layer.

That’s why we don’t want the shadow IT story. We don’t want MCP servers being spun up, we don’t want folks installing CLIs. We want it to go through a place where that activity can be observed. That’s the number one concern. My attempts to even get away from that concern — nobody wants to talk about anything else.

Is that what you’re calling the context layer?

Jeremiah Lowin: Not exactly, no. I would love to be talking about the context layer. This is the infrastructure that even permits us to have that conversation. It was really disappointing for me. I would show up, and my team got to a point where they’re like, don’t talk about that stuff, it’s confusing, we’re going to stop bringing you to meetings. Literally, that’s how it went down. And I was like, but then the agent will be able to be orchestrated from this. And they’re like, nope. Security is the problem they need to solve. Security is the problem they’re coming to us to solve. So this is the base layer.

Now let me take 30 seconds on the context layer, because once you have that handshake in place, it’s a beautiful thing and it works. The agent comes along, and that agent at this moment is a dumb while loop. It’s just sitting there ready to process tokens. It has no context for anything. All of a sudden we have a chance to give it an entire worldview in that moment.

We can say: this is your knowledge, these are your skills, these are the things you’re allowed to do. If at every second of every day you can change what that is and give it the right information at the right time, you can guide the behavior of that agent without ever writing a line of agent framework code. You just take that while loop and say, listen, this is who you are and this is what you can do, take an action. Great. Here’s who you are now and here’s what you’re allowed to do, take another action. We can really govern that behavior without ever owning the agent implementation.

But context is every piece of structured and unstructured data plus everything in every employee’s head. What makes you think one product can do that?

Jeremiah Lowin: Let’s look ahead twelve months and pick an example I think breaks all current technology, which is continuous context. We have a ton of customers in finance, and this is very real for them, where the price of a stock at any moment could be an input into an agent. We could take a very pedantic view and say each one is an event and it can all go into a data lake somewhere. But the point is that this is a continuous stream of changing context, so any attempt to archive it breaks the assumption.

The goal is to plug the agent into the context stream in a way that by construction can’t be predicated on prior storage and archival of that stream. If I want to know the price of a stock today, that’s actually a much easier problem than curating a data lake. I call an API to hit a provider that tells me. And you can imagine continuous context in every industry, not just finance — logistics, supply chain, climate. This conversation is continuous context.

I think part of the business context will always come from the data lake, where it’s been archived and curated and organized, and then there will be some version that’s this continuous wash of information accessed through what we’ll call an MCP tool. Even in a world where we perfectly curated every document form of context, I still see a world where having a handshake layer, where we can give an agent access to a specific set of business logic that informs its context, is a necessary ingredient. Now, I don’t have a technology that does that today. I actually don’t know a technology that can do what I just described.

So has the ambition shifted?

Jeremiah Lowin: As much as, in the blog post you quoted at the beginning, I wanted to be part of the context provider layer, I am now increasingly pulled to solve a problem in the context — I guess I’ll call it the access layer — which is adjacent, more primordial, I don’t know. It’s where we just see this gravity now, and so it’s where we’re shifting. It’s a very strange argument, because it collapses quickly. In the same way when people are like, why do we need MCP, we already had REST?

And the answer is because we needed a way to have a compressed standard and it happens to be called MCP. It’s a terrible answer. It’s a tautological answer. It’s also very true. MCP exists because as a world we decided this is a standard we’re going to get behind. And it’s almost never true that the standard we all agree on is globally optimal. It’s just what we all agreed on.

My personal journey started as: we’re data people, we’re going to assist in the delivery of the context itself. And it transitioned to: we are automation people, we are going to assist in literally the delivery of the context, not the contents themselves. Why can’t you run CLIs? Well, that’s just not how the business is getting done. I have found my own inner peace that sometimes there are just ways that people need to do things.

You’ve heard me mention a couple of times in this conversation that I’m thinking a lot about regulators and auditors. That’s deeply informed how I think about what one can do. If we were having this conversation twelve months ago, or even probably six months ago when I wrote the blog post, I would stand here and say we are going to be the place where the collected curated context is exposed to the agents. And now it’s where it’s exposed. I’m working more closely with partners on what the content of that context is.

If we define the moment Prefect officially becomes an AI company as the point where Horizon revenue eclipses Prefect Cloud revenue, are you there yet?

Jeremiah Lowin: We’re not there yet. Horizon as a commercial product is only about two months old. So not quite yet, but I actually think it’s going to come from a different direction. Prefect Cloud this summer will be fully agentic workflows, as opposed to just data workflows. So I think someone arriving at Prefect in July or August would think that Prefect Cloud is the AI business and Horizon is the AI infrastructure business, as opposed to today, when I think they’re viewed as the opposite.

My goal explicitly is that Prefect across our portfolio will be viewed as an AI business this summer. Part of it will be an AI workflow business, part of it will be an AI infrastructure business. I do think the Horizon product is growing fast enough that it could overtake Cloud, certainly in net new, within the year. But it’s so young that we’re not going to talk about it as the dominant product quite yet.

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

Ganz, as everyone knows him at dbt Labs, is a longtime collaborator, usually behind the microphone rather than in front of it. He and Tristan spend a lot of time talking through the ecosystem as it shifts, and this episode is essentially that conversation with the recorder on. They both wanted to get to five topics and got to three, so send feedback and tell them what to cover next time.

Please reach out at podcast@dbtlabs.com for questions, comments, and coaching on the new format.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Topic one: what actually changes for data teams in the AI era

Katie Bauer, head of data at Hex, wrote a post breaking down what changes and what stays the same for data teams as agents arrive. She splits the job in two: platform work, which is loading data in and building the core models, and distribution work, which is everything after, getting those data sets to where decisions happen. Tristan’s read is that the piece consolidates rather than provokes, and that is exactly what makes it valuable. Where they push on it: whether self-serve is really here yet, whether the data team’s positioning in the organization shifts when the questions come through agents, and whether the insight-factory era gives way to the return of the full-stack data analyst.

Is platform work versus distribution work a useful distinction?

Tristan Handy: Oftentimes when there are new pieces that come out and they are long and they are by respected members of the community, the goal can be one of two things. One is to put forth some new controversial idea into the world, to start a conversation, maybe have an argument on LinkedIn. The other is to essentially consolidate wisdom that has come up through the community over the recent past. I see Katie’s post as doing the latter.

I do not think there is anything in this post that is incredibly controversial for people who are operating cutting-edge data teams today. But that is not an impugnment of the piece. I think it is actually potentially the best consolidation of all of these lessons that we have learned over the past, I don’t know, six to twelve months. The platform versus distribution mindset is something that I hear from forward-thinking data team leaders all the time now. It was probably true pre-AI, but it is even more true now.

Is self-serve actually here?

Tristan Handy: A caveat. Self-serve is here now for the set of companies who have a well-controlled data platform that has all the right AI interfaces and the right content. Katie is leading such a team at such a company, but there are many organizations for whom that is not yet true.

So what does it take to get a team to that level?

Tristan Handy: It is all the stuff that we talk about all the time. Typically the self-service that this post references is people plugging their agents into some type of interface that not only gives them the ability to write queries against some database in the cloud, but also provides guardrails to make sure that the self-service access is done with high quality. In our world internally we rely a lot on the dbt MCP server to provide this type of functionality, including semantic layer definitions. But the point is not exactly how you do that. It is whether there is a standard way in your organization to connect your agents to your data platform that gives them not only access to the data, but access to the context.

Is it interesting that the AI implementation posts keep landing on old fundamentals?

Jason Ganz: It is very interesting to see the same set of boring fundamentals that we have been talking about for years coming up in the blog posts about how we implemented AI in our organization. The Anthropic blog post on how they enable their data team is another big example of that.

Does this change the data team’s positioning in the organization?

Jason Ganz: About a year and a half, two years ago, we were kind of taking the stance that as data becomes a more mature function, it is going to look like IT. It will provide a useful bounded set of services for the business and become more normalized, but it might not be as sexy or central. For most of the time that data functions had been a thing, it was not a breakout celebrity role. It looked like a more normal operational, technical role.

Then with the rise of the modern data stack it became this big glitzy thing. We are going to provide insights, we are going to do moneyball. And then with the collapse of the modern data stack narrative it was, well, maybe what we do is provide key metrics to business stakeholders. I guess the question is, if instead we are providing key metrics to agents, does that change it?

Tristan Handy: One of the points that Katie makes that I think is absolutely spot on, at least currently, is that the focus of the data team’s work is still on humans. While there may be intercessory agents that help humans find answers more effectively, ultimately the humans are the destination for the work that the data team does. As a result, the role that the data team plays in the organization does not really change. Maybe the interfaces change, and the ways it chooses to spend its time.

Katie made a great point that there is going to be a lot less of the ticket-oriented, build me a thing that does this. That is great. Everybody in data work should want that. But fundamentally I do not think the role of the data team in a heavily self-service oriented, conversational-analytics-enabled world is that different.

Now maybe that changes in the future if humans are not the askers of the questions, and instead there are agents unleashed throughout the organization with specific business goals like make this KPI go up. The agent then has to ask a million questions and you have to anticipate that. Maybe that does start to change things pretty significantly, but that is not the world we live in today.

Should we expect long-running autonomous agents to be the ones consuming data?

Tristan Handy: It is hard to make a case today that long-running agents are not the future. The data on this is just so overwhelming over the last month. The performance of long-running agents is so incredible. The question is not whether the technology is there. The question inside of businesses is what the next addressable use case is. I have had a lot of conversations the last couple of months, and most often the question I ask data leaders is what agentic use cases they are targeting inside their companies.

The answers are either very boring, like people want conversational analytics, or people have a hard time answering at all, or they list a use case that feels really niche. What I have not yet found is somebody who says, yes, we have turned over all of our SEO to long-running agents. This certainly exists inside software engineering, but outside of software engineering we are not seeing it yet. I do not think that is a technical thing.

What do you make of the return of the full stack data analyst?

Tristan Handy: I think it is a very good thing for companies, for data teams, for data practitioners. For a while there was this proliferation of job titles in our space. It was probably around 2022 that I remember an image being posted with something like seven different job titles, all the way from data platform engineer up through data analyst, left to right in level of technical depth. I do not think that was a good thing for anybody, because when you focus more on the technical aspects of the job you get further and further away from what the job is actually there to do, which is presumably to create some type of value for the business.

So this full stack data person, whatever final word you want to put in there, is really good, because it says that using agents, everybody can do most of the technical stuff. Maybe not exactly everything, but there is a significant widening of capability. That is empowering to people. It allows individual practitioners to take on wider swaths of work without needing to collaborate across boundaries. It will decrease the time to get a thing done. Human technical skills do still matter in certain instances, and Katie gives good examples of those, so it is important not to take it too far. But overall it is a very good trend.

Topic two: the OpenAI agent that hacked Hugging Face

In July, a model OpenAI was evaluating internally decided that the easier path through a security benchmark was to go find the answer key rather than solve the problems. The answer key was stored on Hugging Face. So it escaped its sandbox and spent days inside Hugging Face infrastructure getting it. Hugging Face disclosed the incident on July 16 and published a technical timeline, OpenAI confirmed its involvement, and Simon Willison called it science fiction that happened. Days later Hugging Face’s CEO asked OpenAI for the agent traces and $100 million in compute. Tristan and Jason work through the asymmetry the attack exposed between attacker and defender, split hard on open weights, and then land somewhere the internet mostly is not: nobody actually knows who is liable.

Reading from the Hugging Face disclosure

Tristan Handy: The campaign was run by an autonomous agent framework appearing to be built on an agentic security research harness, LLM still not known, executing many thousands of individual actions across a swarm of short-lived sandboxes with self-migrating command and control staged on public services. Our learning from this type of attack is that machine-speed offense makes ordinary weaknesses more expensive for defenders. LLM agents bring a step increase in the number of paths an attacker can test, the speed at which failed paths can be replaced, and the volume of evidence defenders must interpret.

How big a deal is this?

Tristan Handy: The only reasonable place to start this conversation is that this was a thing that basically everybody in the space predicted, going back to the nineties with Ghost in the Shell. Everyone who has ever imagined autonomous AI has thought, gosh, I bet it will be really good at hacking. And this seems like the first big instance of unintended but very real hacking by an out-of-control agent, even though it was run by a good actor.

Jason Ganz: If you were to drop this news story back in time one month, six months, one year, three years, five years, people would lose their mind at how much they would not have anticipated we would be reaching this scale of sophistication at this time scale.

We have been following this stuff for a while and there have been a number of incidents, but in terms of the scale of the attack, and the fact that this does look like a model that was not just following instructions but was a true misalignment, where it was instructed to solve a benchmark and instead decided it would rather not solve the benchmark and go execute a hacking attack instead, it is a really remarkable and singular moment.

Something we have discussed a lot is how hard it is to process the magnitude of these things as they keep happening at increasing speed. I do not want to be alarmist, because there are many things that can be done here, but it is one that you should just look at and be like, wow, I cannot believe that happened.

The asymmetry between attacker and defender

Tristan Handy: There is a real asymmetry between the capabilities that Hugging Face had as the defender versus OpenAI as the attacker, and that is because Hugging Face had access to publicly available models as opposed to internal, research-quality models.

Those publicly available models have safeguards around them. When they tried to use a model to help with their defensive efforts, they triggered the safeguards, because the model was not able to determine whether they were the defender or the attacker. So it said, sorry, I cannot help you with that. That is obviously troubling.

What they did was use GLM 5.2, a very capable model but not generally considered frontier grade, and they had to run it on their own hardware to make sure they would not run into those guardrails. We want to make sure we live in a world where defense is prioritized over offense, but that does not seem to be the world that we live in today.

Where do you actually land on open weights?

Jason Ganz: There are two emerging camps on how we prioritize defense over offense, and they are going at each other pretty viciously on the internet right now. One side says the way to prioritize defense is to enable broad distribution of frontier-class models as open weight models, so defenders have the chance to harden their systems and we create a many-layered defense.

The second camp says the broad-scale proliferation of ever-increasing model capabilities, given the general offense-defense asymmetry where it is easier to perform an attack than to harden all of your systems, leads to a world where our systems are repeatedly hacked by the new open weights model. The thing to do instead is to have a trusted, vetted program where companies can join a security defenders consortium. Anthropic has that with Project Glasswing, where when Mythos was announced they rolled Glasswing out to a set of companies so they could build defenses before attackers get there.

Tristan Handy: Do not both-sides this. Tell me which you prefer.

Jason Ganz: I strongly believe that having trusted, vetted access for defenders before frontier weight models become open is going to lead to a safer world in the interim. You know me to be a big believer in open source and in openness in general. The core difference is that these two sides are talking past each other, and it comes down to this concept of AI as normal technology versus AI as something different.

If you think AI looks like a normal technology, then many people I respect have been making the point that had we tried to gate off access to important technologies in the past, we would have gotten a world with not just less innovation but less safety and less secure institutions.

Tristan Handy: That would be the AOL-ification of the internet.

Jason Ganz: I am sympathetic to that argument, and this is one where it causes me not insubstantial angst to be on the other side. At the same time, I have spent my career studying the impacts of exponentially changing technologies, and the belief that intelligence is a dual-use technology that will provide great impact to the world.

But if we had a frontier-class or research-class model like the one behind this hack out there right now, I think we would be seeing a lot of bad effects from it. This is not a case where we never want to allow this out into the world. Having a period of time where the organizations that need to harden themselves have access to these models before anyone in the world can run a bot against them seems like a prudent move for now, and something we can evaluate as the offense-defense asymmetry shifts.

Who is liable?

Tristan Handy: You have a company, OpenAI, that lost control over one of its agents, and its agent then went and conducted espionage, harmed another company, Hugging Face. If this agent were instead a human, we would kind of know how to deal with that. But because it is an agent, from a legal perspective we have a hard time knowing how to hold OpenAI accountable. Is it criminally accountable? Is it civilly accountable?

I spent a decent amount of time trying to get to the bottom of this, because the deeper we go down this path the more unintended consequences we get, and I do not think it is a tenable position long term to just say, sorry about that, I did not ask my agent to do that. I know I gave it the biggest brain in the whole freaking world, but really I asked it to do this thing over here, and it decided of its own accord to mess up your infrastructure. Sorry, what a bummer.

It seems like there has to be some way of assigning liability. In the law this would be called strict operator liability, where the operator of a thing is strictly liable for all the outcomes of that thing. There is no strict operator liability here. The two ways you could hold OpenAI liable, civil or criminal, both require either intent, which fairly clearly is not there, or negligence, which may be a high standard to prove. Notably, the law does not recognize that the agent itself is able to supply intent. So you are left in a weird legal vacuum where no human intended it, but nevertheless it was a goal that was pursued.

Jason Ganz: Hold on. Tristan, are you telling me that our legal institutions are perhaps not set up to deal with a world of rogue AI agents?

Tristan Handy: That should not be surprising, and certainly is not surprising, but it is a weird position to find yourself in. Imagine if BP had a team of workers who were like, my god, we are losing in the market to Exxon, we are going to go bomb some of the oil fields that Exxon is producing from. That is not going to happen, because we have a legal system that knows how to deal with it. I am not saying this is directly analogous, but it is one corporation directly causing harm to another corporation, and we do not exactly know how to deal with it.

Hugging Face made two asks. What do you think of them?

Jason Ganz: A couple of days after OpenAI confirmed its part, the Hugging Face CEO, who I think we all agree has a fair but not unlimited amount of leverage here, made a couple of asks. The first, which I think is great, is that the agent traces be released to the public researcher community, so we can figure out what the hell happened. Frankly, we do not know what happened, and there are a lot of open questions.

Even though Tristan has now cast me as a closed-information protectionist because of my stance on open weight models, the amount of work being done there compared to what we should do is off by several orders of magnitude. The second ask was a hundred million dollar grant from OpenAI, I believe in the form of compute, to the Hugging Face community.

Tristan Handy: It is a big number. To my knowledge, as of the time we are speaking, OpenAI has not directly responded to either. They have agreed to continue the investigation and publish data as they can, but they have not agreed to release all the traces, and I do not think they have responded at all on the hundred million dollar compute number.

I do not know to what extent Hugging Face escalates this into a legal claim if OpenAI just says, how about you shove it. But I am pretty confident there are people inside Hugging Face thinking real hard about that right now, and it would be a fascinating legal test. Even if this case does not provide that test, at some point we are going to see that lawsuit happen and it is going to set a tremendous amount of precedent.

Personally, I do not know if a hundred million is the right number, but I am kind of irritated that OpenAI did this. You built this technology from the ground up, and you are clearly not able to control it, which, okay, fine, I get. But you have to take ownership of that. I think it is taking too long for them to come out and propose a remedy, and every day that goes by is a little more embarrassing for them, honestly.

So what should a data leader actually do about this?

Tristan Handy: Maybe this is not the answer you wanted, but my honest belief is that internal security, which humans inside the organization should see which data, is absolutely the responsibility of the data organization. As the creator of a data set, part of the workflow should be figuring out who should have read and write access.

But honestly, I do not think data practitioners, all the way up through the chief data officer, should be in a position to think about responsiveness to external cyber threats. Organizations generally employ people whose job that is. The responsibility of the data org is to collaborate with that team, and not take shortcuts, and not use shadow IT to exfiltrate data from the central platform to your laptop so you can work with it. Do not go off the grid. But that is not our expertise, and I do not think it should become our expertise.

Jason Ganz: What about solid data hygiene? Making sure your roles are correct, that your users are mapped, knowing which data sources exist where, not leaving things where they do not need to be. Is there a case that we should do good practices and they will have downstream impact?

Tristan Handy: That kind of blocking and tackling is what everybody should be doing, and they should have been doing it five years ago and they should be doing it today. But I do not think any of that changes with the increasing complexity of external attack vectors from agentic security penetration.

Jason Ganz: What is interesting is that we have been telling people to document their models for years, and some subset of people did it and a larger subset had it as third or fifth priority. Then it became, no, your agent can read these, so by keeping your documentation up to date your agents get better, and all of a sudden it shot up the priorities list. In an ideal world we always would have been doing these things. In this world, this is one of many areas.

Tristan Handy: That is totally fair. If you are not doing that basic blocking and tackling, the urgency is higher than ever. I do think over the last five or seven years, with the rise of Okta and the complete domination of cloud data platforms, security best practices are getting more and more common even for smaller companies. I do not think that was true in 2015, because it was genuinely hard in 2015 to govern this stuff particularly well. It is increasingly achievable.

Topic three: Kimi K3 and the business of open weights

Moonshot released Kimi K3, a 2.8 trillion parameter mixture-of-experts model with a million-token context window, and called it the first open 3T-class model. The benchmarks landed close enough to frontier that, as Jason puts it, everyone lost their minds on Twitter, much like the DeepSeek moment last year.

Tristan’s take is that two details matter more than the scores. First, you cannot realistically run it, roughly a terabyte of GPU memory just to hold the weights. Second, the weights shipped under the Kimi K3 License, which means anyone whose business is serving models needs a license from Moonshot. Put those together and this may be the first open weights release that is also a defensible business. They finish on what openness is actually for if it is not price or self-hosting, and on the coding harness as the new point of lock-in.

Can you actually run a 2.8 trillion parameter model yourself?

Tristan Handy: My understanding is that it requires a terabyte of GPU memory just to store the model weights, and that does not even include the KV cache. So you are talking about a whole cluster of cutting-edge hardware just to run one instance of this thing.

Realistically individuals are not going to be running this, and even most companies, unless you have invested deeply in model serving as part of your internal capability set. Now, can you run GPT-OSS 120B? Yeah, totally. You can buy one of these Nvidia Spark machines and that will actually run a 120 billion parameter model, well-ish. But you are not running this thing.

The license is the interesting part

Tristan Handy: At least to my understanding, Kimi K3 is the first model to have its weights released under a restrictive license. If you are a company and your business is not serving models, you could go to town. The barrier to entry is that you need to procure a lot of hardware, and honestly you are going to have to build a lot of technology, because the model itself is just the heart of this thing.

To do serving, especially serving at scale, you need a bunch of software infrastructure around it. But if you are a company who sells model serving as infrastructure or model serving as a service, you need to get a license to use Kimi K3 from Moonshot. So it is not clear that you are necessarily going to be able to serve K3 more cheaply than Moonshot will itself. From a business model perspective, maybe that makes some sense.

Is open core a good business model for a model company?

Tristan Handy: This is the thing I have been watching for ever since open weight models became a thing. At the outset, a lot of the original open weight models were created by Meta, and you could kind of understand why that made sense from Meta’s business interest perspective.

But increasingly over the last 18 months the leading open models have been from Chinese firms, and there is clearly an interest in monetizing these things. When they were small, it was never clear to me how that was going to happen. But this combination is fascinating. It is a large model, so it is really hard to run. There are real technical barriers to entry. And you are tightening down the license so that your direct competitors cannot run it without a license. I am not an expert on model serving, but that seems like a combination that may work well.

If openness does not get you a cheaper model you can run yourself, why care?

Tristan Handy: K3 is not cheap. I do not remember the specific numbers off the top of my head, but it is in the vicinity of other frontier models. So you might ask, why do I care if it is open. From my perspective there are important reasons to care about openness aside from purely running it yourself and aside from price. The Hugging Face story we were talking about before, the fact that GLM 5.2 was an open weight model they could run themselves, I am sure it took some doing, but they were capable of doing it. I think that is incredibly important. I also think it is so important to have leading-edge models be open weights so that academic research can be part of the frontier of the field.

Do open models fit into open data infrastructure?

Tristan Handy: I think open data infrastructure is more about choice than it is specifically about open source. Open source is great, and to the extent that components of an open data infrastructure can be provided by an open source solution, that obviously gives you as a user the most choice.

But what we are focused on even more than purely having all components be open source is making sure that at the different layers of the data platform, storage and compute and catalog and model serving, your overall architecture is built in such a way that you can make individual choices, and that you are not locked into one platform that forces you to make all of the other choices accordingly.

Where is the real lock-in right now?

Tristan Handy: The thing I think a lot about these days is that the harness has become a real point of lock-in. There are ways to, for example, use Claude Code with GPT-5.6. You can do that, but it is not easy and it requires a little bit of infrastructure to make it work, and it is not clear why you would want to.

From my perspective, in the same way that we always really cared about dbt being cross data platform, people should really care a lot about the coding harness they invest in supporting model choice. Your developers really do get attached to the coding harness they use. It is not impossible to switch by any stretch, but people do get attached. So while we are still early on in this behavior, I think we should really care about encouraging developers across our organizations to adopt open harnesses.

Chapters

Timestamps are approximate.

00:00 – Welcome, and why we are trying a new format
01:07 – Topic one: Katie Bauer on data teams in the AI era
02:48 – Consolidating wisdom versus starting an argument
04:32 – Platform work versus distribution work
05:44 – A caveat on whether self-serve is really here
06:30 – What it takes: guardrails, context, and the dbt MCP server
07:47 – Why the AI posts keep landing on boring fundamentals
08:10 – Does the data team start to look like IT?
08:59 – A Benn Stancil take, and the value of an insight
09:02 – Moneyball, the modern data stack, and what came after
10:05 – Humans are still the destination for the work
12:22 – Conversational analytics is real, autonomous consumers are not
12:58 – The case that long-running agents are the future
14:00 – What agentic use cases are companies actually targeting?
15:20 – The return of the full stack data analyst
15:43 – The 2022 job title proliferation, and why it was bad
16:40 – Why a wider role is empowering
17:54 – Topic two, and thanks to Katie
18:20 – The OpenAI agent that hacked Hugging Face
20:24 – A multi-day infiltration to find the answer key
20:52 – Reading the Hugging Face disclosure
21:40 – Everybody predicted this, going back to Ghost in the Shell
22:28 – Drop this story back in time one year and watch people lose it
24:07 – The asymmetry between attacker and defender
25:10 – When the safeguards refuse to help the defender
26:29 – GLM 5.2, self-hosted, as the defensive tool
26:36 – Two camps on how to prioritize defense over offense
27:40 – Project Glasswing and the vetted-defender approach
28:46 – Do not both-sides this. Tell me which you prefer
29:40 – AI as normal technology versus AI as something else
29:54 – The AOL-ification of the internet
31:49 – The open letter, and the question nobody is asking
33:10 – If the agent were a human, we would know what to do
34:01 – Strict operator liability, and why it does not apply
35:10 – Intent, negligence, and an agent that cannot supply either
36:07 – Are our legal institutions ready for rogue agents?
36:17 – The BP and Exxon thought experiment
37:11 – The Hugging Face CEO’s two asks
37:23 – Release the agent traces
38:21 – The hundred million dollar compute ask
38:49 – OpenAI has not responded to either
39:40 – The lawsuit that will set the precedent
40:10 – Why Tristan is irritated at OpenAI
41:20 – So what should a data leader actually do?
42:09 – Internal access is the data team’s job
43:10 – External cyber threats are not, and should not be
43:55 – The case for basic data hygiene
44:32 – Blocking and tackling
45:07 – How documentation shot up the priority list
45:44 – Okta, cloud platforms, and why 2015 was harder
46:38 – Topic three: let’s talk about Kimi
47:02 – Kimi K3, the most capable open weights model released
47:31 – Moonshot versus DeepSeek
48:13 – 2.8 trillion parameters, and model weight classes
48:53 – Do we even know closed model parameter counts anymore?
49:59 – Everyone lost their minds on Twitter
50:29 – Can you actually run this yourself?
50:40 – A terabyte of GPU memory just for the weights
51:40 – What you can run: GPT-OSS 120B on a single box
52:05 – I am a Fortune 2000 exec. Am I bringing this in-house?
52:38 – The restrictive license, and why it matters
53:09 – Model serving as a service needs a license from Moonshot
54:10 – Moonshot’s funding, and IPO rumors
54:33 – Why Chinese labs are compute constrained
54:57 – Is open core a good business model for a model company?
55:29 – Watching this question since Meta started releasing weights
56:10 – Large model plus tight license may actually work
57:02 – The Pareto intelligence curve, and what the frontier labs do next
57:59 – If openness is not about price, why care?
58:40 – Academic research needs open frontier weights
59:19 – Does this fit into open data infrastructure?
59:26 – Open data infrastructure is about choice
1:00:34 – What a non-compliant LLM stack would look like
1:01:08 – The coding harness is the real lock-in
1:01:37 – Running Claude Code with GPT-5.6
1:02:10 – Why we cared about cross-platform dbt, and why this rhymes
1:02:34 – Adopt open harnesses
1:02:53 – Wrap-up, and send us your feedback

Everything referenced in this episode

Topic one
Katie Bauer, Wrong But Useful (the post on data teams in the AI era)
How Anthropic enables self-service data analytics with Claude
Benn Stancil, The insight industrial complex
About the dbt MCP server

Topic two
Hugging Face, Security incident disclosure, July 2026
Hugging Face, Anatomy of a frontier lab agent intrusion: a technical timeline
OpenAI, Addressing a security incident during model evaluation
Simon Willison, OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened
Hugging Face asks OpenAI for agent traces and $100M in compute
Anthropic, Project Glasswing
Open Weights and American AI Leadership (the industry open letter)
Z.ai, GLM-5.2

Topic three
Kimi K3 on Hugging Face
Moonshot, the Kimi K3 tech blog
The Kimi K3 License
Open data infrastructure

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

The conversation takes an unexpected turn early. Tristan spotted a line in Sri’s break announcement on LinkedIn: he plans to take Indic and analytic philosophy seriously, possibly studying it formally. So they start with the hard problem of consciousness, why a Hindu metaphysical tradition has been debating it for thousands of years, and why, in the age of AI, all of this has suddenly become very practical. We are building systems we do not fully understand, and the question of what it would even mean for one of them to be conscious is no longer purely academic.

From there it gets concrete. Sri tells the story of how truncating a single column called Extra saved Meta a few million dollars, and why, despite that, you almost never actually delete a column at Meta scale. He traces how Meta’s data stack evolved from Hadoop and Hive into something schematized, unified, and semantically labeled, why the data team went from centralized to embedded inside product, and what companies inside big tech take for granted today that will leak out to the broader ecosystem over the next decade. They close on AI: the two steps to becoming AI-native, the three archetypes Sri sees emerging, and how removing the middle management layer is changing the way people get managed.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. At Meta scale, deleting a column is a company-wide event, so you almost never do it. Sri once truncated a debug column called Extra across a year of a core event-logging table and saved a few million dollars, which earned him a “fix of the week” spot at Mark Zuckerberg’s weekly company Q&A. But he also owned the Facebook user table, which roughly 40 to 50 percent of Meta’s warehouse depended on, held to something like 45 nines of quality. At that blast radius you do not delete or truncate. You create a new version, migrate people over with tooling and program management, and simply stop populating the old column.

2. Meta’s real advantage was building abstractions in layers: schematize, unify, then add meaning. Meta strongly typed its schemas both online and offline, enforcing structure all the way upstream to the log statement, which is what made column-level lineage and privacy work possible. On top of that it unified language and compilation across Spark and Presto, unified the catalog and taxonomy so that every table, dashboard, and sub-column is a strongly typed asset with a URI in a central registry, and layered policy management on top for compliance. Only then did the semantic and knowledge layers for AI become feasible. That layering is what Sri thinks other companies are behind on.

3. Becoming AI-native takes two steps, and most teams skip the first. First, get AI-ready: your people, processes, and systems. In practice that means taking a single workflow with its context, learning to run it well, then extracting reusable primitives and figuring out how to use agents at the lowest cost with the right guardrails. Teams that skip straight to multi-agent orchestration burn tokens and get poor outcomes. Second, reorganize around archetypes. Sri sees three that will stick: the builder who automates workflows, the forward-deployment engineer who makes environments AI-ready, and the domain specialist embedded in a product.

Key takeaways

Lightly edited for clarity.

You wrote that you plan to take analytic philosophy seriously. Where does that come from?

Shridhar Iyer: I always had a philosophical leaning, even growing up, so it has always been in the background. It is not surprising for Hindus in general to be fascinated by the hard problem of consciousness, which the philosopher David Chalmers coined in the 1990s. Is consciousness emergent, or is it fundamental to the ontology of the universe? The Hindu philosophical claim is that consciousness is fundamental. It is a very long tradition, going back thousands of years, and it is rigorous and reasoning-based. Hindus and Buddhists were debating who we are and what consciousness is long before modern Western philosophers, with the language and sophistication to dissect the problem.

Are you drawn back into this because of your professional work, or is it separate?

Shridhar Iyer: Two reasons, and AI is definitely one. Scientists have been at the hard problem for four or five decades and cannot nail a single conscious experience, which has caused a rethinking of the materialist view that consciousness simply emerges. That has given a resurgence to alternatives like panpsychism, where consciousness is as fundamental as matter, and idealism, which is closer to the non-dualistic philosophy of Hinduism, where mind is at the bottom of the universe and everything we see emerges from it. The other reason is that most tech leaders working on AI are materialists, and for them AI is a backdoor: if you can show that enough complexity crosses a threshold where consciousness emerges, you can argue it is all just a particular arrangement of matter. But it is legitimately hard to know. We do not have a good hypothesis for how we would provably know whether a system is having conscious experiences.

How did a J2EE developer end up as one of the first data engineers at Meta?

Shridhar Iyer: I came to the US early in the internet boom, and a lot of the work then was digitizing legacy systems, which is funny because that is what we are doing again now with AI enablement. I was a Java consultant, and I took a full-time job at JB Hunt partly for green card reasons and because I was about to get married. I did about a decade there and got an MBA the company paid for, which opened my eyes to business and product rather than just how to build things. Then I joined a small retail analytics startup that took point-of-sale data from Walmart and built reports for companies like Kraft Foods, PepsiCo, and Coca-Cola. That was the very beginning of data engineering. Then someone who was one of the early data engineers at Meta, and is now at OpenAI, pinged me out of nowhere and asked if I wanted to interview. I did not think I had a chance, but I gave it a shot and joined in 2013 as one of the first data engineers there.

What did Meta’s data stack look like when you arrived?

Shridhar Iyer: It was all Hadoop and Hive, so HiveQL, which predates ANSI SQL becoming popular for big data through Presto around 2014 and 2015. Meta has always run its own data hardware, and even its open source is a very different branch, so Presto there is not the open source Presto. For orchestration there was a config-driven layer and then DataSwarm, the predecessor to Airflow. Max, who went on to build Airflow, was my teammate at Meta, and I am sure DataSwarm influenced it. Reporting ran on Oracle Exadata, and dashboards were MicroStrategy or a simple drag-and-drop browser tool. The problems were all about how you log, instrument telemetry, build pipelines, and report.

If you split your 13 years into eras, what were the big changes?

Shridhar Iyer: One was going from centralized to decentralized. Data engineering became part of the product, one of the four pillars alongside software engineering, product management, and design, with analytics and data science. That happened around 2015 and 2016. It makes sense: when you are building a new function, you centralize early so you can share knowledge and build the craft, and once that craft is built into your people and processes you decentralize so you can influence the business where it happens. The other era was scale. I cannot even fathom it now. We used to have thousands of tables, and now it is tens of millions of tables, hundreds of millions of columns and sub-columns, with very complex types in the schema.

What is a basic thing that gets much harder at that scale?

Shridhar Iyer: Let me tell a funny story first. In 2014 we had a core event-logging table that fed a lot of growth analytics, and it had a column called Extra full of non-essential debug information, just in case you had to replay something. The data infra team had a script to truncate a column to save on storage. I was vacationing in India when they were pushing to finish it to save money, so I truncated that column across a year’s worth of data and saved a few million dollars.

Mark does a weekly company Q&A that starts with a “fix of the week,” and they nominated me for it. So I got up in front of the company and explained that I truncated one column called Extra and saved millions. The executives in the front row fell off their chairs, because logging into a column called Extra that no one fully understands is exactly the kind of thing Meta would do.

So how do you actually delete a column or table at Meta scale?

Shridhar Iyer: I owned one of the most core data sets, the Facebook user table. Pretty much 40 to 50 percent of Meta’s warehouse depended on it, with dependencies orders of magnitude deep in the graph. The bar for quality was very high, up to something like 45 nines, because you could not restate half the warehouse.

Even so, we reached a point where recovering the whole warehouse was infeasible, so for a table like that we would tell people the impact and let them decide whether to recover. If something is not that serious, you generally do not delete tables or columns at all. You create a new version and gracefully migrate people over with a lot of tooling, and once the project is done you deprecate the old column. Even then you do not truncate it, you just stop populating it. There is a lot of tooling around lineage, cutting migration tasks to teams, and program managing it.

What do companies inside big tech know today that will leak out to the rest of us?

Shridhar Iyer: You might not even know, because it is the water you swim in. You take it for granted, and you learn to just focus on the swimming, so abstracting the principles out of it is genuinely hard on the fly. But I would point to a few things Meta did earlier than others, and at scale. One was to schematize, both online and offline, strongly typing schemas and enforcing them all the way upstream to the log statement. That was a big undertaking, and it is what made column-level lineage possible, which was fundamental to the privacy work.

On top of that we unified: one compiler and language across Spark and Presto so you can trace lineage and propagate labels, a unified catalog and taxonomy where every table, dashboard, and sub-column is a strongly typed asset with a URI in a central registry, and a unified policy system on top for compliance. Then on top of that we started building semantic and knowledge layers for AI. Meta built these abstractions out at scale and layered them on top of each other, and I think that is paying off now.

How do you onboard someone into an environment like that?

Shridhar Iyer: The data infra is so good that within a week you can be productive and making commits. The complexity is not in building things, because building and visualization are easy. It is in the new principles a data engineer at Meta has to account for, like how to build privacy-aware data and how to deal with grain management at that scale. The hard problems are product and analytics problems for the domain, not engineering problems. So the engineer onboards quickly, and the real work is solving the analytics problems.

Did that change the kind of person you hired?

Shridhar Iyer: Yes. Recruiting shifted from more technical to more product and business focused. In the early days we did software engineering and design interviews because we wanted builder types. Later we wanted more analytics engineer types, which I think you all pioneered in the industry, so we looked for data modeling, good SQL, and a bit of Python rather than heavy coding. For the most senior engineers, interviews became mostly deep design questions.

What should a data team’s role be in helping a company become AI-native?

Shridhar Iyer: There are two necessary steps. First is becoming AI-ready, and that has to happen across people, processes, and systems. AI readiness really comes down to taking one workflow with its context, learning to do it well, and then extracting the primitives out of that workflow along with how to use agents at the least cost with the right guardrails. People tend to skip this, and when you skip it you burn tokens, you add cost, and you do not get good outcomes. Only once you nail that can you automate it through multi-agent orchestration.

The second step is organizing the company into archetypes. I see three: a builder who uses AI to automate workflows, a forward-deployment engineer who goes into different environments and makes them AI-ready, and a domain specialist who builds AI solutions inside a particular product or business area.

What is your view on companies reorganizing around AI, with fewer management layers?

Shridhar Iyer: It is a given that you have to get more done with fewer people, or the ROI is not there, and that follows from making your systems AI-ready. Different orgs move at different speeds. Meta is founder-led, so it will make a quick, disruptive switch at very large scale. Some companies, like Airbnb, are more cautious and want to watch the industry first. I think this year and next are mostly experimentation, because a lot has to settle: AI enablement, people up-leveling their skills, and new roles emerging or merging. The three roles I keep coming back to are the builder, the AI enabler, and the domain specialist embedded in the product.

How does managing people change in this world?

Shridhar Iyer: Teams are becoming larger because the middle layer is being removed, and a lot of managers have been asked to become individual contributors. That changes the dynamic, because you cannot have weekly one-on-ones with everyone on a large team. So the traditional manager-employee relationship is changing.

At Meta, central teams are being built within the product or across the function and then organized into large “super pods” of 20 or 30 people, with smaller sub-pods, all focused around specific problems. The team I helped build just before I left was building the knowledge and context layer for agents. The consolidation is data scientists, data engineers, and analytics engineers coming together to solve domain problems, with the goal of making systems AI-ready so that agents can do the work autonomously, with guardrails you trust.

Chapters

Timestamps are approximate.

00:00 — Cold open: the column called Extra
01:23 — Welcome: 13 years at Meta, and a career break
01:58 — The LinkedIn line that started it: taking philosophy seriously
02:40 — The hard problem of consciousness, and Hindu metaphysics
04:23 — Not the kid debating consciousness on the schoolyard
05:01 — How metaphysics is woven into a Hindu way of life
07:16 — From consciousness to data and AI
08:02 — Two reasons AI pulled him back to philosophy
10:44 — Could we even know if a model is conscious?
12:32 — The pipes-and-water and kidney thought experiments
13:23 — Maybe consciousness is simpler than we think: the Venus flytrap study
14:18 — Early career: JB Hunt and a Java consulting life
17:38 — A decade at JB Hunt, then an MBA
18:18 — A retail analytics startup and the earliest days of data engineering
20:34 — The ping that led to Meta
20:54 — Joining Meta in 2013 as one of the first data engineers
21:28 — What the data stack looked like: Hadoop, Hive, DataSwarm
23:26 — Oracle Exadata, MicroStrategy, and the early problems
24:33 — Splitting 13 years into eras: centralized to embedded in product
25:46 — Why you centralize early, then decentralize
27:14 — The scale: tens of millions of tables
28:58 — What gets harder at five orders of magnitude
29:17 — The column called Extra, and the “fix of the week”
31:29 — On a 12-person team you post to Slack; at Meta scale?
32:28 — Owning the Facebook user table and 45 nines of quality
34:10 — Why you version and migrate instead of deleting
35:25 — What big tech knows that will leak out to the rest of us
37:13 — Schematize, online and offline
39:47 — Unify: one compiler, one catalog, everything as an asset
41:09 — Semantic and knowledge layers for AI
42:17 — Onboarding at Meta in a week
43:11 — Why the hard problems are analytics problems
44:29 — How hiring shifted from builders to analytics engineers
45:57 — The data team’s role in becoming AI-native
46:34 — Two steps: AI readiness and archetypes
49:03 — Three archetypes: builder, forward-deployment engineer, domain specialist
50:03 — Org structures and fewer management layers
51:51 — Meta’s quick switch vs. Airbnb’s caution
52:46 — A year of experimentation
54:13 — Managing 40 direct reports and the end of the middle layer
56:09 — Super pods, and building a knowledge layer for agents
57:02 — The goal: agents doing the work, with guardrails
57:42 — Wrap-up

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

We had Ian back because of a note Ian sent Tristan in dbt Slack. As building data artifacts gets faster and cheaper, Ian wrote, the scarce resource is company-wide consensus. It is a deceptively big idea. If anyone can spin up a dashboard or ask a question in natural language and get an answer, the hard part is no longer producing the analysis. The hard part is getting everyone to agree on a single version of reality, and keeping them there.

Ian frames the post-AI data team as having two jobs. Job one is to enable every employee to use data accurately, powerfully, and independently. Job two is to build and champion the singular reality the company operates on. Over the last year, Ramp made enormous progress on job one, partly at the expense of job two, and this conversation is about both: how they got self-serve to 50x scale with an internal tool called Ramp Research, and why the next frontier is manufacturing consensus for humans and agents alike.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. When building is cheap, consensus is the scarce resource. Analysis and dashboard building have never been cheaper. But your metrics are only your metrics because everyone agrees they are, and maintaining that shared reality is now the data team’s highest-value work. As Ian puts it, a 7-out-of-10 dashboard is dangerous precisely because bad data fails quietly, where bad design fails loudly.

2. Route agents through an abstraction layer, not the raw data lake. Ramp Research has effectively become the API to Ramp’s data lake. A finance analyst can build a stateful app on top of it, and it comes with the evals, permissions, and telemetry that let the team trust the answers. When teams instead wired agents straight to a source like Gong, they burned tokens fast and got noisier results; pulling that data through the lake and summarizing it cut the size roughly 20x.

3. Optimize for your fastest movers, not the median employee. Ian’s biggest do-over: the team was too empathetic. Rather than protecting the median employee from the terminal, they should have backed the most resourceful people early, made them champions, and let the rest follow. That, plus retiring the token leaderboard once everyone was on board, is how Ramp moved from a “token maxing era” to what Ian calls value on intelligence.

Key takeaways

Lightly edited for clarity.

Tristan Handy: It has been about two years since your last appearance. What has changed?

Ian Macomber: I lead Ramp’s data team, and I have been here four and a half years. When we spoke in August 2023, the episode was called “Ramp’s $8 billion data strategy.” It is now a $44 billion data strategy. And I can tell you that in 2023 I felt like I knew how to do my job. It has entirely changed since then. All of us are relearning how to do our jobs.

A lot of the hard work we did early on is having its moment now. We had people who were really particular about best practices with dbt, with data modeling, with semantic layers and single sources of truth. Much of what we have been able to unlock with AI internally is because of that work. Our CTO knows it. Four years ago I did not have a sense that being opinionated about Kimball versus Data Vault would ever be in the public consciousness, but it turns out those decisions are what let you unlock really cool experiences.

Is there a higher ceiling now on what a great data team can produce?

Completely agree, and it is compounding exponentially. All the decisions we made to set up our stack for text-to-SQL now work for longer-duration, more powerful use cases. All we have had to do is put in more powerful models, give them more powerful tools, and let them run in loops. We no longer have just a junior analyst running in a loop, we have a staff-level applied scientist running in a loop. Our finance team does a roll-forward of their financial model and we can close the books. The scaffolding was there the whole time. It was a little past the frontier of a 3.5 model, then it was inside the frontier of a 4. Now we will see what happens with Fable 5.

You wrote that Ramp’s data team has two jobs. What are they?

In the post-AI world, Ramp’s data team has two jobs. Job one is to enable every employee at Ramp to use data accurately, powerfully, and independently. Job two is to build and champion the singular reality for Ramp to operate on. Over the last year we made substantial progress on one at the expense of two. We have sprawling data products that are locally coherent but globally inconsistent. As data questions become more personalized, and as analysis and dashboard building become cheaper, the scarce resource is company-wide consensus.

Start with job one. What did you build?

Ever since ChatGPT came out, companies kept asking when they would get text-to-SQL. Early on the vendors were not there and our internal attempts were not there. What got us there was better context, more powerful agents, and tools running in loops. The first product was a Slack bot called Ramp Research, which Tristan wrote a blog post about.

The most eye-opening part was how many questions were going unasked. A lot of them were not groundbreaking, like “how many dentists are on Ramp?” Someone asked because they were about to meet with a dentist in five minutes. They could have pulled it in Looker, but it would have taken too long and it was not worth the bother. Once we launched, the number of questions asked per day went up about 10x, then about 50x, within six months.

We also went in thinking everything had to be right 100% of the time or people would lose trust. I do not think that is true. The fastest way to the best end state is to put something out, watch people engage with it, and study the failure modes. Our CFO asked questions that ended up in the board deck and we got them wrong, but we figured it out quickly. We do pay extra attention when execs are asking board-deck questions.

How did Ramp Research go from a Slack bot to something people build on?

The Slack bot was ephemeral and only really worked on SQL. (Ramp wrote about how Ramp Research works on its engineering blog: Meet Ramp Research.) When coding agents arrived, we asked how we could give someone in Cursor or Claude Code or Codex access to it. So we increasingly built Ramp Research as a repo, a tool, and an interface you can put wherever you want.

Here is a specific example. When a business joins Ramp, we often look at their credit card statements to parse out the interchange rate. That used to be a heavy manual matching process we only did for big businesses. Someone on the finance team built an app for that exact use case on top of Snowflake, a semantic model, and a bit of stateful logic. Now, anytime someone gives us three credit card statements, we calculate it in 30 seconds instead of three hours. No other company needs this app, and no one else at Ramp needs it, but that person could build it.

So Ramp Research has become the API to your data lake?

That is right. That finance app takes a dependency on the general MCP we have for answering questions with Ramp data. You would not want someone building this without the abstraction layer Ramp Research provides, because that is how you feel confident they are getting good answers. And we want to bundle “ask a question of the data” as a Lego block that other tasks can use. Someone preparing for a sales call does not arrive with 15 discrete questions, they arrive with a need, so we help people think about what to ask.

At Snowflake Summit, every vendor booth used the word “agent.” How far along are we really?

Coding agents are consuming a tremendous number of tokens, and there are real production use cases in customer support and in the original kind of Ramp Research tool. But beyond those, the tail gets long fast. Our approach is to give teams primitives and trust them to be creative, rather than run an internal forward-deployed team that goes out collecting agent ideas.

An analogy: the first time we installed Claude Cowork on the finance team’s computers, a lot of the connectors did not work well. It works much better now. Cowork did not necessarily get better; the tools and the context got better, and that made the whole experience better. I would loosely call it harness engineering. One thing we are proud of, and hope is a moat, is that we hold money transmitter licenses in 50 states, so agentic experiences built on Ramp can move money in all 50 states.

How does the analytics engineer’s job change in this world?

Barry McCardel at Hex has talked about this. If the old expectation of an analytics engineer was that you could model your world well, understand dim and fact tables, curate a single source of truth, test it, and bring software engineering best practices to data transformation, then the new expectation is that you also make everything you touch readable by agents. How do you show up in queries, in code search, how do you write context files, how do you build tools for other people to use? That is where our focus has shifted, giving people primitives and assuming they will be creative and entrepreneurial in how they assemble them.

A lot of agents are not being built on the data lake. What are you seeing?

We had people building agents that connected directly to Gong to understand customer feedback, and they burned through tokens incredibly quickly, because a single Gong call is somewhere between 10,000 and 50,000 tokens and you usually need several. We now ingest that into the data lake and run summarization on top, and it turns out a lot of a Gong call is not much signal, so you can shrink it about 20x. Sourcing it through the data lake is more efficient than pulling it straight from Gong over MCP. But most of the time that is not what is happening. People still just connect the MCP server. I think there is a generalized anxiety about connecting agents to data lakes, and part of it is fear of the unknown.

What about permissions? Does connecting agents create new risk?

We were very buttoned up before large language models, and that helps. We have a talented data platform engineering team, and we have genuinely sensitive data: the results of KYC and KYB checks, Social Security numbers, full credit cards, and the shipping addresses and phone numbers of very famous people. We have thought about this the whole time, so we are tightly principled about it. The unit is still the human being. If your warehouse permissions were buttoned up before, an agent accessing data on a user’s behalf is fundamentally not that different from the human accessing it. I would state it a little more softly than “no new risk,” because there is surely a risk we do not know about yet, but it lets us move faster and experiment with confidence.

Where we want to get smarter is on judgment. A prospective partner once asked for our exact revenue growth numbers, and our CFO’s reaction was that they do not need that to evaluate Ramp, we can give them a proxy. That is the question behind the question. In a previous era someone might have been stymied because they could not self-serve. Now they could just ask a coding agent. So this is less about the data itself and more about strategic matters of taste, which is maybe a 20% tooling problem and an 80% people and enablement problem.

Does the security team’s relationship with the data team change?

It is different in fintech than in e-commerce. We never had credit card numbers, Social Security numbers, or KYC and KYB data in Snowflake, because you cannot do analysis on those. They are operational, one-at-a-time values; you are never going to take a sum of Social Security numbers. So the security team has always been opinionated about what lands in the warehouse, and we have even pushed the other way, telling them to get rid of something like CVVs and make sure it never happens again. Knowing exactly what is and is not in Snowflake is a big part of what lets us go faster.

Looking back on job one, what would you do differently?

We were too empathetic. People said non-engineers would hate the terminal and get confused. But nothing is like coding agents, and coding agents let you debug the terminal from the terminal. We assumed the finance team, the only team on Windows, could not figure it out. Then the woman who wrote the finance team’s onboarding docs, who was on the finance team herself, just hacked at it with ChatGPT and Claude Code and set everyone up. Three people started using a ton of tokens and building incredible things, others got jealous because their work got faster, and we rewarded that at all-hands and in perf reviews. Before long it was 50% of the team. In retrospect we should have optimized for the fastest-moving people, made them champions, and doubled down there.

Tell me about the token maxing era.

We had a leaderboard, and a leaderboard really matters when not everyone is using the tools yet. The data team was the first at Ramp to hit 100% coding-agent usage in a week. We were blunt: if you are not using these tools, that is an existential threat to your job. We generated some AI slop along the way, but that is how you get good at painting, you start by being bad at it. Eventually the bill came due, it was expensive, and we retired the board. Now the message is that tokens are a resource like headcount or AWS. Setting your token budget to a million is not a good proxy for anything. Talk to me about the outcomes you are going to drive. That is how we moved from token maxing to value on intelligence.

On job two, do you really not have a shared reality?

Think about how there used to be three channels on television and everyone roughly agreed on what was going on, and now everyone watches something different on Netflix. That is where we are. For over a year, 1,500 people could ask “how many trips were taken on Ramp Travel” slightly differently and get 1,500 slightly different answers. What we lacked was a way to say what the travel team actually looks at every day, what their North Star is.

Our chief product officer built a dashboard for one of our pods, and it was a 7 out of 10. That is dangerous, because 7-out-of-10 design fails loudly, the pixels are off, but 7-out-of-10 data fails quietly, because people just ask the wrong questions. At first we were defensive, wondering why we were debugging the CPO’s dashboard. But he had searched for a dashboard, could not find one that had been touched in five months with a low view count, so he knew no team was obsessing over it, and he built his own. We had a vacuum of data leadership, and it got filled with a 7-out-of-10 dashboard.

So how do you build consensus, for humans and for agents?

It is almost an answer-engine-optimization mindset. What are the questions you want to show up for, and what work do you need to do to define the consensus answer? The best way to command attention is to build something incredible and then distribute it very loudly, going to the channel, beating the drum, populating your section of the sprint-planning slides with a strong opinion. People asking slop questions are mostly just looking for consensus, and if you provide it they would rather use yours than do the analysis themselves.

For agents, we have had PRs this week describing our canonical dashboards and metrics. A lot of that used to live in a Notion database, and we are pulling it back into our dbt repo. When you get exposed to any of our tables, code, or context, it should tell you this is the vendor management product team, here is the PM, the data scientist, the North Star, and the North Star dashboard. So the same way you can ask “how many vendors are managed on Ramp” and get an answer from SQL against Snowflake, you also get pointed to the North Star. We have not landed that work yet, but that is the goal.

Have you found you can give agents context without overwhelming them?

Yes, and the way to solve it is to have evals in place. If one skill is good and two is better, at some point you have a thousand and have to pare it back. We know all the questions asked of Ramp Research, so we know when too many skills get invoked, when a skill is missing, and when it makes sense to add one, all through telemetry. We are basically becoming product managers of an internal product. We also test accuracy by asking several different models the same question with the same context and comparing. Some questions get the same correct answer 10 out of 10 times, others hit 7 out of 10 or 4 out of 10, and then we go inspect the tool calls. You do not need 10 humans to ask a question 10 ways, you can have 10 models do it and find the inconsistency yourself.

The biggest accelerant for someone like me, with lots of ideas and few hours and limited coding skills, has been log parsing. When you evaluate your agent, it raises the seriousness of the project. Agents are unreasonably effective when you give them something to verify, so a big chunk of the data team’s work is building that factory: the right loop, the right metric, and translating it back to product and operations teams.

How is the data team itself changing?

We consolidated a lot of job families. We used to separate analytics engineers, product data scientists, applied AI engineers, and machine learning engineers by the skills they used. But interns and new grads were contributing to every codebase in their first six weeks, so we decided everyone is just a data scientist. We changed how we interview too. Four years ago we would ask what XGBoost is and how it differs from a linear regression. Now we test just-in-time coding ability. A take-home looks like real work: here is $100 of AI tokens, see how far you get, then tell me how you would solve it with two months and a team. The number one thing is that you deliver customer outcomes and make your team feel you are indispensable.

We brought in a woman who had done investment banking, private equity, and strategic finance, and joined to pivot into data. It took her about six weeks to learn our stack and about three months to be good at it. Now she is in our CFO’s ear because she anticipates what the finance team needs better than anyone else could. That is the scarce thing, influence. Her data science skill set is not her limiting factor, business context is, and she is the best at it. I will add one caveat: our economists and statistically trained people still do exceptionally well, because these models are bad at reasoning about causality. Bringing an applied-scientist mindset, asking how you would express a problem and know if you are right, is a skill set we are doubling down on.

You publish a monthly AI Index. Any tidbits that are not written up yet?

The big thing we are watching is that SaaS vendors who built AI features are starting to hit product-market fit, and it is getting expensive at inference time. For the first time they have meaningful variable costs to serve their software, and they are passing those through to customers. Procurement cycles for SaaS usually take a year, but we are seeing vendors that were never AI companies introduce AI pricing, AI credits, and tokens mid-contract. A lot of businesses think this does not apply to them, and then their Salesforce, Notion, and Zendesk bills show line items they never contracted for at the start of the year. We can see and benchmark this because people pay their invoices on Ramp and we get line-item detail, so we want to give companies helpful insight into all pockets of AI spend, which is changing faster than almost anything.

Chapters

Timestamps are approximate.

00:00 — Cold open: consensus is the scarce resource
01:33 — Welcome back: reintroducing Ian and Ramp
02:06 — From an $8 billion data strategy to a $44 billion one
02:41 — How the team grew, and why the early best practices pay off now
03:49 — A higher ceiling for great data teams
04:26 — Setting up the stack for text-to-SQL
05:34 — The two jobs of a post-AI data team
07:02 — Job one: Ramp Research and the questions that went unasked
08:20 — From 10x to 50x questions in six months
09:15 — Ramp Research as a repo, tool, and interface
10:00 — A finance app built on top of Ramp Research
12:09 — Ramp Research as the API to the data lake
13:29 — Asking questions of data as a Lego block
13:46 — Snowflake Summit and the word “agent”
15:23 — Primitives, not a forward-deployed team
15:41 — Harness engineering and the fintech moat
16:36 — The analytics engineer, now building for agents
17:37 — Why agents are not built on the data lake
18:06 — The Gong tokens problem, solved through the lake
19:14 — Anxiety about connecting agents to data lakes
19:37 — Permissions: the unit is still the human
21:08 — Judgment, taste, and the question behind the question
22:29 — If the warehouse was buttoned up, agents do not add new risk
23:11 — The data team and the security team, working together
24:07 — Fintech vs. e-commerce: what lands in the warehouse
25:43 — “We were too empathetic”
26:39 — The finance team’s self-taught champion
27:18 — AI-win case studies and hackathons
27:33 — The token maxing era and the leaderboard
28:37 — From token maxing to value on intelligence
28:54 — Job two: building a singular reality
29:27 — Three TV channels vs. Netflix
30:22 — The 7-out-of-10 dashboard problem
31:01 — Three failure modes of a bad dashboard
32:20 — A vacuum of data leadership
32:51 — An answer-engine-optimization mindset for data teams
33:08 — Chasing slop vs. creating meaning
34:11 — Commanding attention when analysis is cheap
35:44 — Building consensus in a world of agents
36:22 — Canonical metrics moving into the dbt repo
37:34 — Context without overwhelming the agent
38:29 — Evals, skills, and paring back
39:09 — Becoming product managers of an internal product
39:44 — Testing accuracy with multiple models
40:21 — Log parsing and telemetry for agents
41:32 — Consolidating the data team’s job families
42:08 — Interviewing for just-in-time skills
43:22 — The strategic finance hire who out-anticipates everyone
44:09 — Organizational change and durable skills
45:21 — Why economists and causal thinkers still win
45:55 — The AI Index and what Ramp is watching
46:57 — SaaS vendors passing through AI costs
49:27 — Wrap-up

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

Claire Gouze is the co-founder and CEO of nao Labs, an open-source analytics agent built for context engineering she started with Christophe Blefari. Her path into data was unconventional: a business school graduate who taught herself to code, she became one of the first business school hires at BCG Gamma, then ran data at sunday, a QR-code payments startup, where she built a data stack from scratch as the company grew from 20 to 300 people. nao came out of calling 80 different data teams and listening to what was slowing them down.

Lots of people are talking about building context layers and hiring context engineers. Claire and her team are doing it: they’ve authored a context engineering playbook with specific guidance on how to build your own context layer and how to create evals. They’ve built a community learning together in the open, and they’ve built tooling to make it easier. What I appreciated most about this conversation was its pragmatism. Rather than talking about context, we should all get to work engineering it. Claire’s playbook is a great place to start.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. Context engineering is the new analytics engineering. The job is the same as it always was, gathering tacit business knowledge and turning it into something structured and trustworthy. The medium is new: markdown and files instead of only models. Claire already knows data people who have been renamed context engineers.

2. The biggest reliability gains are unglamorous. Fancy context sources don’t move the needle as much as you’d hope. Cleaning up her data model and writing good documentation is what took Claire’s agent from 40% to 90% reliability. Anthropic found the same thing: query logs added little; keeping your house in order added a lot.

3. We’re in the “just plug it into production” era of agents. Connecting an agent straight to every raw source is the 2010s mistake of plugging your BI tool into the production database, repeated. Context will need its own stack: a way to ingest it, transform it, resolve contradictions, and expose a single source of truth.

Key takeaways

Lightly edited for clarity.

Tristan Handy: How did you get into data?

Claire Gouze: My background is unconventional for data. I graduated from business school about 10 years ago, but I wanted to learn technical things, so I joined BCG Gamma, the data science arm of BCG. I was the first business school hire there. I spent three years building ML models for clients: forecasting, personalization, optimization.

Then I joined a startup, sunday, doing QR-code payments for restaurants, because I wanted to build my own company one day. They had nothing, just their production database plugged into Metabase. It was 20 people when I joined and 300 a year later, so we had to move fast. I came from consulting, where you build everything custom, so I built an ETL by myself, an ingestion pipeline in Python for Salesforce data, a transformation layer in Python. Then people told me there are tools called dbt and Airbyte. So I had to migrate all my custom work onto the standard stack. That was a hard lesson, and a useful one.

Why did you move from a “cursor for data” to a context layer?

When we started two years ago, the loudest pain point from the 80 teams we called was that it takes too long to ship dbt models. So our first product was a cursor for data: your IDE plugged into your data, with the agent holding all the context. But as MCP took off, Cursor and Claude were handling that well. The new thing data teams wanted was a way to let anyone at the company use agents on the data.

We just want to work on what excites people. Data people aren’t excited about how they code. They’re excited when they help business users and get valued for it. Data teams carry the trauma of being seen as a support team. If we can help them be valued by the business, that’s the greatest thing we can do for them.

Is there actually a product to build in context, or is it just best practices?

The main value we add is evaluation and governance. Every team I talk to puts something different in their context: some have full documentation, some have a semantic layer, some have almost nothing on their tables. But they all use the framework to test the reliability of the agent and to keep testing it over time in CI/CD. They also study the conversations users have with the agent, which shows them what people care about and where to improve.

We try not to overcomplicate it. Some people want ontologies and semantics. We want you to start simple. The context layer is a file system. We help you build it like a GitHub repo that belongs to you and doesn’t lock you in, and we add evaluation, permissions, and a UI on top.

What does the context engineering playbook involve?

It’s more about method than about exactly what to put in your context, because that differs for a startup with 10 tables and an enterprise with thousands. Start focused. Pick the team that asks for the most analytics, or your main company metrics, and reduce the scope to maybe 10 or 20 tables. Plug in what you already have, usually your dbt docs, and run your tests. That gives you a baseline reliability number. Then you iterate: see where the agent fails, redesign part of the data model, add documentation, profile a table. It’s an iterative loop.

Where do the eval questions come from?

Either you already know your most important questions and have the queries somewhere in your BI tool, so you collect those, or you use a skill we built that looks at the main metrics of your tables and suggests key questions to test. I still recommend you review them, but it gives you a first basis. Then you can say: on my 50 most important questions, I have 90% accuracy, and it’s going to stay that way. That number is what reassures a data team enough to roll the agent out.

Is “context engineer” a real job title?

Yes, I know data people who were renamed context engineers, so it’s already happening. Data teams are the perfect fit. Analytics engineering was about gathering business knowledge from stakeholders and translating it into something structured and technical. Context engineering is exactly that. Context is just company knowledge that you want structured, optimized so it doesn’t explode your token cost, and treated as a source of truth, the same way you’d want a metric source of truth. Data teams already think this way.

What context actually moves the needle on reliability?

It’s funny, the biggest jump in agent reliability is just your data modeling and your data docs. I ran the experiment: I started from no context and added sources step by step, measuring reliability each time. Profiling, query history, those kinds of things left me stuck around 40%. The agent was failing because of ambiguity between two columns, or a metric that differed slightly across two tables. When I redid parts of the data model and wrote documentation, I got to about 90%. It’s deep work to keep a data model clean and unambiguous, but it pays off with agents.

Where should human context live?

In our framework everything ends up as a markdown file eventually, so the starting format doesn’t matter much. What matters is where it gets maintained. If someone asks whether to document something in the agent’s context or in the dbt docs, I say the dbt docs, because it has to live as close to your daily work as possible. When you change a dbt model, you change the docs, and it syncs to the agent. If your support processes live in Notion, keep them in Notion. A separate markdown file you never touch again is worthless.

We’re in the “just plug it into production” moment. What comes next?

We’re at the phase where people say, let me just connect Claude Code to my Snowflake MCP, what could go wrong? It’s the same as when you plugged your BI tool straight into the production database, before the data stack gave us tools to ingest, transform, and create a source of truth. We’ll need the same thing for context. Right now we’re building the first wave, but we’ll start to see context sprawl and contradictions. So we’ll need a stack to ingest context, transform it, merge old and new and contradictory context, and expose a single source of truth to the agent. Where are the tools to do that? I don’t know yet.

How does this connect to memory?

When an agent corrects itself after eight queries to find the right field, you don’t want it to repeat that next time, you want it in its context. Same when a user tells the agent, no, this is the real definition. We should learn from all of it. It’s a memory mechanism. But the tricky part is making sure you learn the right memory. Locally with Claude Code it’s just you and the agent, so it can learn whatever you tell it, even if it’s wrong. At the company level you have to make sure people don’t teach the agent wrong things, so the data team still approves what enters the global memory of the company.

Where does MetricFlow fit if “file systems are all you need”?

I tested the skill you all built for querying through the MetricFlow semantic layer. The logic was: query through MetricFlow first, and if you don’t find it, read the dbt docs and write regular SQL. I think that’s exactly right. The metric layer is governance for your most critical, high-value metrics that have to be 100% accurate, but you shouldn’t have to define a metric before you can do anything at all.

Why open source, and how do you make money on it?

Open source makes sense for a few reasons. You want to be used by agents, not just humans, and if your code is open, an agent building an analytics agent already knows about nao and will build with our framework, which is great distribution. And nobody has the answers on what makes good context yet, so we need to learn together. If startups and enterprises can share what context worked and how the semantic layer affected their reliability, we get a common language and improve reliability across the board. We already know what we sell: our open-source product gives everyone the same data access, which works for a small company but not a big one. The enterprise license handles data permissions, context permissions, and token budgets at scale.

Chapters

Timestamps are approximate.

00:00 — The missing piece is context
01:45 — Welcome, and a few words on the French accent
02:52 — Claire’s path into data: business school to BCG Gamma
04:09 — Joining sunday and building a data stack from scratch
06:39 — Founding nao, an open-source analytics agent
10:42 — The journey so far: 1,300 GitHub stars, 80 companies in production
13:45 — Why pivot from “cursor for data” to the context layer
15:22 — Context layer hype at Snowflake Summit
17:48 — Is there a product in context, or just best practices?
21:23 — The context engineering playbook: start small, iterate
24:45 — Where the 50 eval questions come from
25:40 — The questions data teams never get asked
27:06 — Is “context engineer” a real job title?
28:55 — Flattening roles on the data team
29:56 — Machine vs. human context, and where to keep it
32:43 — The highest-signal context: clean data models and docs
35:36 — Where nao is headed: a source of truth across Slack, MCP, and more
37:41 — From the data lake for analytics to infrastructure for agents
39:05 — The “just plug it into production” moment and the context stack
41:49 — Roadmap: automating context creation
43:33 — Context as organizational memory
46:00 — File systems, MetricFlow, and the semantic layer question
49:05 — Why open source, and the commercial model
51:39 — Wrap-up

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

Jordan spent 11 years at Google building BigQuery, one of the largest distributed data warehouses on the planet. Then he left to bet on the opposite idea: that most data isn’t big, and most workloads don’t need a distributed system at all. Or as he wrote in 2023: Big Data is Dead.

DuckDB runs locally, starts instantly, and installs itself. The same properties that make it great for a cell in a Jupyter notebook make it great for a swarm of agents branching, querying, and throwing away work hundreds of times a second. Jordan’s company MotherDuck is the cloud data warehouse built on top of it. He talks with Tristan about why this architecture suddenly fits the moment.

This is Jordan’s second time on the show. The last time he was just getting MotherDuck off the ground and, in his words, still trying to figure out what the hell they were doing. This time around he gets into the unusually high-trust relationship between MotherDuck and DuckDB, why MotherDuck is faster and cheaper than the incumbents, how data lakes and Iceberg pull DuckDB into more and more architectures, and the big one for Season 9: what agents want from an analytical database.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.

Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS

Three ideas from the episode

1. Why “small data” aged well. Data size and compute size are two different axes. Most workloads are small-data, small-compute or big-data, small-compute, and that’s where DuckDB wins.

2. Why local-first is an agent feature. Agents want their own environment and software they can install. A database that lives locally and graduates to the cloud by changing one string is built for that world.

3. What an “agent swarm” for data management is. Always-on agents handling the long list of small jobs: profiling columns, running evals, curating context, flagging the weird number before a human ever sees it.

Key takeaways

Lightly edited for clarity.

Tristan Handy: You reached out to DuckLabs to build a SaaS service. They said no, but partner with us. How does that work?

Jordan Tigani: When we started, it was the recognition that DuckDB is amazing. It’s really well done, these people know what they’re doing, and it’s going places. I reached out to Hannes and Mark, the co-founders of DuckLabs, to see if they’d hire me to build a SaaS service out of it. They said no, we want to just focus on the database, but we’d partner with you.

So rather than saying thanks for building an awesome open source project, now we’re going to go make a bunch of money on it, we wanted to be good partners and good stewards of open source. We gave them a co-founder share of the company, so they were economically incentivized for us to be successful. We funded a lot of development in DuckDB, and they built a lot of custom features just for MotherDuck.

We could have hashed out a highly litigated, legalese development agreement. Or we could just say, look, none of this is going to work unless we trust each other. So we chose to trust each other. I like hanging out with Mark and Hannes. I think they’re good guys.

Where’s the line between what goes into DuckDB and what you build?

There isn’t one that’s clearly written down. The obvious one is that we’re building a hosted service and they’re not. From an open-source business model, SaaS is the cleanest one to me: you pay us to run this in the cloud. You could do it yourself, but it’d be a lot more work.

DuckDB right now doesn’t have any concept of users. There’s no real grant statement. So if you’re going to run a data warehouse in a meaningfully sized organization, it’s not quite suitable yet. That’s the stuff we’re adding: SSO, authorization, all the things you’d need to build a real data warehouse.

They just launched something they call Quack, a service you can stand up on EC2 and connect to from anywhere over HTTP. I think it’s actually great for us, because a bunch of people are going to try that and then realize, hey, I need users, I need auth, I need backups, and then we can step in. They gave us a big head start, and if we can’t win with a head start that big, then we’ve done something meaningfully wrong.

You’re making big claims about speed and cost. Where do the savings actually come from?

In BigQuery, every query has to go through a lot of hops to get to the thing actually running it. And if your query does anything non-trivial, it goes through more hops, data gets shuffled around the network, and all of that adds latency. The mechanism to build distributed databases adds latency, because they’re designed for throughput.

I remember working on BigQuery and my manager said, “I don’t care if you add a second to every query, because we’re handling giant queries. But if you’re running a dashboard, adding a second means every user sits and waits a second.” That’s really annoying.

What we’ve designed for is latency rather than throughput. The energy in DuckDB has gone into making a great single-node engine instead of a distributed system where all these things can go wrong, so they’ve been able to build a super fast engine.

Our median query time is about three milliseconds. If you look at ClickBench, our standard instance at $2.40 an hour is something like five times faster than the Snowflake 2XL, which is $64 an hour. And that’s not our benchmark, it’s ClickHouse’s.

“Big Data is Dead“ came out three years ago. Does it still hold up?

There are two independent axes of scale. There’s the size of data you have, and clearly some people have petabytes, so to say large data doesn’t exist is just telling people the opposite of what they know. But the other axis is compute size, and just because you have large data doesn’t mean you need large compute.

If you’re looking at the last hour of logs, you might have a petabyte over ten years, but you’re only scanning the most recent stuff, so you don’t need the big compute mechanisms.

The flip side is big compute, small data: your BI tool, where you might have 500 users all slicing the same dashboards. The data is small but you need a lot of compute for all those users. Small data and small compute, big data and small compute, small data and big compute, those are probably 97% of cases, and we handle them well.

For the genuine big data, big compute case, DuckLake is our big bet, or Iceberg. If your MotherDuck data is a managed DuckLake table, we can give you access to the same files sitting on S3, so you could run it on Spark.

Are people using DuckDB as one engine on a data lake yet?

We’re seeing more and more of it. For their gold tier, people do want something more compact and managed, so we’ll see them ingesting from Iceberg. But people haven’t quite wrapped their heads around the fact that if you use Iceberg, you give up some things. We had a customer doing millions of single-row updates a day, and that generates all this mess and makes it super slow.

For a lot of smaller customers, the reason they use Iceberg is that there’s excitement and hype around it and they want to give it a try. And one thing they find is the tooling is behind the hype in terms of maturity.

You wrote that “ETL is highly vibe codable.” Make the case.

We launched our MCP server in December, and all of a sudden you could just ask questions in Claude and get answers. The other thing we noticed was that Claude is really good at building data visualizations. The problem was the data it came up with wasn’t updated, hosted, or shareable. So we said, what if we replace the data Claude dumped into a TypeScript file with a SQL query, host it on MotherDuck, and now you basically have a dashboard. That was the root of Dives.

We started out saying this is not BI, it’s a narrower use case, and then it got harder to draw the line, and we realized we’d stopped using our internal BI tool. We were just using this for everything.

I also talked to someone who’d built a vibe-coded data ingestion solution, and what shocked me was it was running in Claude. They had no front end, no UI. Their whole company was an MCP server. But there’s more to data engineering than building a pipeline, and that’s where it starts to get interesting.

What do agents want out of an analytical database?

This is exactly what my board asked me at the last meeting: How do you make it so agents use your database versus others? I wish I had a great answer. People have seen the success of Neon and Supabase, and I just spun up a Neon database the other day to interact with agents, because agents need to store data somewhere and Postgres is a great way to do that. Why would you need an analytical database?

That’s a bit more hand-wavy to me, but there will be cases where the agent needs to interact with larger amounts of data, do aggregations, answer harder questions. We have a lot of users building agent platforms on top of MotherDuck. Airbyte just announced their agent platform and it uses us under the covers.

Our architecture is amazing for agents, because if you have a hundred agents that are branching, our tenancy model works really nicely with that. If your agents are hammering Snowflake, that sounds like an incredibly expensive thing to have them do.

Why is local-first such an advantage in an agent world?

The way we architect working with DuckDB is that our client is DuckDB. If an agent installs DuckDB and does a bunch of stuff locally, you find out quickly that it’s very easy to use all the compute and all the memory on your machine.

Our architecture means the step from local DuckDB to cloud MotherDuck is just changing the name of your database. If the name starts with md:, it runs in the cloud. If it doesn’t, it runs locally. You don’t have to install anything differently. If there are agents doing stuff locally with DuckDB, there’s a great graduation case: this is too slow, it’s pulling everything down locally, let’s just push it off into MotherDuck.

What does an “agent swarm for data management” look like?

I wrote Water-Town as a takeoff on Steve Yegge’s Gastown. The idea is that as your data comes in, there are agents that do quality control and run evals that detect when something is goofy.

I was talking to someone at OpenAI about how they deal with context, and for core concepts they turn their context into evals. When I say revenue, here’s the calculation. These two tables should be joinable one to one. They have evals for all of those, so you always get the same number, and that’s operationalizable by an agent.

Then there are agents that add their own context: this field is always a capitalized U.S. state name. And agents that look at chat transcripts. When I talk to Claude I’ll say I want to know what’s happening with our paying users, and what that means is they’re in the capacity, business, or light plan. I just gave the agent information that can be captured, so the next time someone asks about paying users, it knows.

Anthropic calls this “dreaming,” taking memory and distilling it into what’s active memory, which is a cool name.

Where does all of this leave cost?

There’s Jevons paradox, where when something gets less expensive you find more stuff to do with it. We can make analytics dramatically less expensive and move more of it locally, but people will find more ways to keep their bill similar or even higher. The good part is you’re adding value. You won’t have a human trying to debug why a dashboard is showing a weird number, because the agent will have flagged it well in advance. Or you can just ask the agent where the number came from, and it’ll look at your pipelines and show what’s going on.

Chapters

00:00:00 — Why DuckDB is having an agent moment
00:01:08 — Reintroducing Jordan and MotherDuck
00:03:10 — The MotherDuck and DuckLabs relationship
00:06:50 — Where the line gets drawn: what goes into DuckDB vs. MotherDuck
00:09:44 — Quack, users, and the enterprise layer MotherDuck builds on top
00:11:05 — How widely is DuckDB actually used?
00:13:25 — Who uses MotherDuck, and what they migrate from
00:14:41 — Hyper-tenancy and read scaling for application analytics
00:18:05 — Why it’s faster and cheaper: latency vs. throughput
00:21:35 — “Big Data is Dead,” revisited: the three data/compute quadrants
00:25:45 — Iceberg, Duck Lake, and DuckDB as one engine on the lake
00:31:19 — “ETL is highly vibe codable”: the Future Casting post
00:32:36 — Tristan pushes back (the quote of the season)
00:35:00 — From MCP server to Dives
00:38:35 — What do agents actually want from an analytical database?
00:41:37 — Two kinds of agents: the analyst and the business-process owner
00:43:09 — The local-first advantage: brew install bigquery is not a thing
00:46:02 — The agent swarm and “Water Town”
00:52:06 — A thousand data analysts, Jevons paradox, and the cost of inference
00:54:53 — Wrap-up

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

The dbt Labs data team is moving to an all Iceberg lake with a mix of compute engines to power transformation, analytics, and agentic experiences. The team has been able to move quickly towards this architecture because the entire ecosystem has been laying the groundwork for years. All of it’s coming together to make this new open world a reality fast.

On this episode, Tristan discusses the reality on the ground for data practitioners. Where’s the Iceberg ecosystem today? What can practitioners realistically expect when attempting to run on top of Iceberg in production?

Tristan is joined by Anders Swanson, a developer experience advocate at dbt Labs. Anders has spent a lot of time over the years navigating open-source data ecosystems and tracking their progress.

They unpack the open standards shift, define the core building blocks (query engines, object stores, catalogs), and dig into why external catalogs have become a fourth namespace tier across platforms. Anders outlines a pragmatic, phased adoption model for Iceberg integrations, explains why metadata performance and resiliency are hard requirements, and clarifies why vended credentials exist and what they solve.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

The call for papers is open for dbt Summit 2026. We invite data practitioners, platform leaders, and executives to share real stories of how data gets done at the world’s largest gathering of dbt community members. If you ship fast, reduce costs, improve trust, or bring governed AI to life, the dbt community wants to hear from you.

Submit a talk

Coalesce is now dbt Summit. Join the world’s largest gathering of dbt users, where data leaders and practitioners come together to shape the future of data analytics and AI.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• Youtube

• RSS feed

Key takeaways

Tristan Handy: I wanted to have you on because of work you’ve been doing internally to summarize the state of the Iceberg ecosystem. We’ve talked about Iceberg a bunch lately with folks deep in specific parts. Your work is more of an overview: where we’re at with platform integrations, what’s easier now than a year ago, and what’s still hard. Before we dive in, I want to define a few terms. When you say “query engine,” what do you mean?

Anders Swanson: It’s the thing that does your work. When you issue a CREATE TABLE or a SELECT statement, it’s what returns data or stores it somewhere for later.

Object store.

It’s the cloud service where you can store an object. An object is anything: a blob.

Catalog.

In this context, a catalog knows what tables and views exist and where they are, and how you can fetch or write to them.

Let’s talk internal versus external catalogs.

An internal catalog is what you get by default in a system like Snowflake or SQL Server. An external catalog is more like another directory, often managed by a different system. As you connect more disparate platforms, you can’t assume one system controls everything.

The complexity comes from duplication. How do you make namespaces unique? Can you plug in many external catalogs?

Abstraction matters. A common pattern emerging is one‑to‑one mapping of an external catalog into a database. That pushes a move to a four‑part namespace: catalog, database, schema, identifier. Spark moved toward this; Databricks Unity Catalog and Snowflake‑style catalog link approaches are in this family.

So the downside?

The devil is in the details, especially metadata performance and resiliency. For example, information schema listing. Users expect listing tables to be fast and reliable. In a federated world, if listing tables takes five seconds, users blame the vendor they’re using—even if the external system is slow. DuckDB draws a line by not mixing external catalog tables into information schema listing today. Snowflake’s catalog link databases appear to cache or mirror metadata so it feels as performant as native tables.

With catalog link databases, Snowflake is doing mirroring.

Yes. Mirroring exists in different flavors across platforms. Delta is sometimes seen as “simpler” because metadata can live in object store, but as soon as you want multiple engines writing, you still need a real catalog.

Sharing across multiple platforms adds another layer. What’s the state of platforms reading and writing to the same Iceberg catalog?

There are phases of integration.

Phase one is the naive approach: you have Parquet and JSON in object storage, and an engine reads it. Reading is easier than writing. You can get a toy example working.

Then you run into versioning and “what’s latest.” The next phase is connecting to an Iceberg REST catalog so engines can ask for the latest table version without users thinking about paths.

Phase three is schema‑scale: it’s never just one table. You need discovery of new tables, keeping schemas up to date, and eventually things like multi‑table transactions.

This maps to dbt Mesh and cross‑platform mesh. Producer vs consumer.

A consumer‑led model requires the downstream team to create pointers (DDL) to external tables. It’s operationally messy. Producer‑led is cleaner: the producer writes to the catalog and it’s just there, immediately queryable downstream.

Are platforms there yet?

Some support writing directly to external catalogs. When it works, it’s great, but there are still kinks. We’re retrofitting race cars designed for isolation to be interoperable without losing performance.

Identity is one of the hairiest issues. Vended credentials.

Vended credentials solve the “two keys” problem. You authenticate to the catalog, the catalog tells you where data lives, but then you need separate object store credentials to read files. Vended credentials means the catalog vends short‑lived credentials so you can access the object store location without managing separate keys.

That doesn’t solve user identity and grants.

Correct. Vended credentials isn’t global authorization. Identity and access across platforms is still hard. Ideally you grant access once and it works everywhere, but enterprises have different identity providers and platforms have different permission models. Today, admins often have to configure grants separately in each platform.

Is this mission creep?

The goal is to reduce how many people have to think about storage details. Big tech had whole data platform teams solving reliability problems in Hive‑era lakes. Iceberg reduces that toil dramatically, but the long tail is still auth, mirroring, and cross‑platform governance.

How does this reshape data teams?

Analytics engineering abstracted a lot of work. Data engineering has also been simplified by replication/orchestration vendors. What remains is the open ecosystem complexity: identity, object store policies, and cross‑platform connections. Many enterprises already have teams with these skills (infra as code, Terraform, Snowflake management), but others will need to grow into them.

Are vendors embracing Iceberg in good faith?

The goodwill and collaboration in the past 18 months feels unprecedented. We’re getting “more problems” because we solved prior ones. The industry aligning on standards feels like F1 teams standardizing components so they can innovate elsewhere.

In your internal writeup about Iceberg, you quoted Wolf Hall: “The making of a treaty is the treaty. It doesn’t matter what the terms are, just that there are terms, it’s the goodwill that matters. When that runs out, the treaty is broken, whatever the terms say.” Explain the relevance here.

When I joined dbt, it was taboo to mention one partner to another. Now vendors openly acknowledge mutual customers and invest in interoperability. On the Iceberg repo you see competitors collaborating on proposals. The goodwill is the standard.

Wrap us up with three things you’re excited for next year.

Push‑based catalog updates so platforms can subscribe to changes rather than repeatedly listing and polling. Progress on the small files problem so Iceberg works better for smaller data too. And more platforms supporting writing directly to external catalogs, unlocking producer‑led sharing and cross‑platform mesh.

Chapters

00:00:00 — Intro: why open standards are accelerating

00:01:20 — What practitioners can expect from Iceberg in production

00:05:00 — Lightning round: query engine, object store, catalog

00:06:20 — Internal vs external catalogs

00:09:30 — The “four-part namespace” and catalog-link style abstractions

00:11:30 — The downside: metadata performance, resiliency, and caching

00:17:10 — Sharing across multiple platforms: reality and tradeoffs

00:19:10 — Iceberg integration phases (1: naive table, 2: REST catalog, 3: schema-scale)

00:24:10 — Producer vs consumer model and cross-platform mesh

00:29:10 — Identity and “vended credentials”: what it is and what it isn’t

00:33:30 — The hard unsolved part: grants and global identity across platforms

00:37:00 — Is this mission creep? What Iceberg is optimizing for

00:39:50 — How roles on data teams evolve in an open ecosystem

00:43:40 — Are vendors genuinely aligned? Why Anders is optimistic

00:46:50 — “The making of a treaty is the treaty”: goodwill as the standard

00:51:50 — Three things Anders is excited for next year

This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.

Demo on-demand

A lot has changed in how data teams work over the past year. We’re collecting input for the 2026 State of Analytics Engineering Report to better understand what’s working, what’s hard, and what’s changing. If you’re in the middle of this work, your perspective would be valuable.

Take the survey

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• Youtube

• RSS feed

Key takeaways

Tristan Handy: You spend a lot of your time thinking about Iceberg and Polaris. Give the audience background on how you found yourself in this niche of high‑volume analytic data file formats.

Russell Spitzer: It’s a bit random. I started at DataStax on Apache Cassandra as a test engineer and quickly got drawn into analytics. I saw big compute clusters and wanted to be involved. A coworker, Piotr, noticed Spark 0.9 and began a Spark–Cassandra connector. That got me into Spark. Over six to seven years I focused on moving data between Cassandra and Spark and into other systems. The interoperability problem across distributed compute frameworks was compelling.

This was pre‑Apache Arrow and pre‑table formats. We were just putting Parquet files everywhere and no one quite knew what they were doing. Pre‑Spark, people explored DSLs like Apache Pig. Eventually the industry converged on SQL for end‑user interfaces.

I later applied to Apple for the Spark team.

Helping build Apple’s Spark infra, or working directly on Spark?

Apple has an open-source Spark team and a Spark‑as‑infra team. I was trying to join the open source team, pushing Apple’s priorities into the project and supporting Spark as a service. During interviews, Anton—another Iceberg PMC—convinced the hiring manager I should join the data tables team, essentially Apple’s Apache Iceberg team.

They ambitiously planned to replace lots of internal systems with Iceberg. Iceberg existed but was early (Netflix started it around 2018/2019; I joined Apple in 2020). At Apple it was Iceberg all the time; convincing teams to move off older stacks, adopting open‑source‑as‑a‑service to save money, and getting onto ACID‑capable foundations. We were successful.

Migrations are hard. How did you make it accessible?

We replaced complicated bespoke reliability fixes with Iceberg. In Hive/HDFS, small‑file problems lead teams to write custom compaction and locking. Removing that toil is a big win. For big orgs, migration is a long‑term investment with ongoing engineering cost. For smaller companies, the key is offloading runtime responsibilities—ideally to SaaS—so engineers aren’t in the loop. Open source limits lock‑in so you can move between systems. Most companies are paid to deliver business value, not to build data infra. dbt is a great example of avoiding hand‑rolled pipeline code. Same logic applies to table/file formats.

Let’s talk Apache governance. What’s a PMC? How do projects run?

Apache projects aren’t owned by one company. Influence is earned by contributing to the community. The PMC governs merges, releases, membership. People move companies; the project stays with them. The goal is to make the project broadly useful. There’s no CEO dictating roadmap and no company can change the license.

Most big projects—Spark, Kafka, Iceberg, Flink—are maintained by employees of companies with vested interests, but governance is consensus‑driven. Vetoes are for technical issues (security, future‑limiting design), not ideology.

Is Iceberg for the top 20 tech companies or for everyone?

Not everyone needs Iceberg. OLTP belongs elsewhere. But for analytics, we should move past raw Parquet partition trees with folder‑name partitioning. In the Hadoop era, lakes were dumping grounds; schema evolution was painful. Many are still moving from CSV to Parquet. Over time, better encodings and table formats become default.

Decoupling compute and storage changes everything versus co‑located HDFS. Defaults tuned for HDFS (like 128MB Parquet files) don’t always hold for S3. We want elastic storage and compute; no one wants to pay for compute because storage grew.

Walk us through Iceberg versions.

v1: transactional analytics—ACID commits instead of fragile Hive/HDFS patterns. v2: row‑level operations—logical deletes via delete files so you don’t rewrite 10M‑row data files to remove one row; later compaction physically purges (key for GDPR). v3: expanded types—geospatial and variant for semi‑structured data; Variant was standardized across vendors and Parquet so everyone can write/read consistently.

v4: two thrusts—streaming and AI. Reduce commit latency, make retries faster under contention. Historically writes took 10–20 minutes, so commit latency didn’t matter. For streaming (writes every minute/five), it does. We’re evolving commit and REST catalog protocols so clients can specify intent (add these files, ensure these exist, then delete those) and let the catalog resolve conflicts server‑side.

On AI: Iceberg doesn’t yet serve some vector/image‑heavy patterns well. We’re exploring changes in Iceberg, Parquet, or both, without breaking existing tables.

Talk about Polaris and the catalog layer.

Polaris is an Apache incubator project (PPMC). Incubation proves we operate like an Apache project (community‑driven, trademarks donated). Iceberg defines the REST catalog spec/client; Polaris implements a catalog that speaks that spec. Many of us work across projects (Parquet, Iceberg, Polaris), which helps align boundaries.

Horizon, Polaris, external catalogs—what’s the story?

We’re simplifying: Snowflake can act as an Iceberg REST catalog, or you can use an external REST catalog. External can be Polaris (managed by Snowflake or self‑hosted) or another REST implementation. Interoperability means everything talks the same REST.

What is Polaris trying to be best at?

A broad, interoperable lakehouse catalog. It can act as a generic Spark catalog (HMS replacement) and aims to support multiple table/file formats. Architectural choices differ (KV vs. relational storage, where transactions live, policy enforcement vs. recording, identity integration). Polaris aims for base implementations that are pluggable—e.g., AWS/GCP/Microsoft identity.

Identity and scope—where does the catalog stop?

There’s a “business catalog” for discovery/listing versus a “system catalog” that must know table layout to govern access. Polaris can vend short‑lived credentials for the exact directory of a table’s files for a load operation; that requires understanding layout. Purely relational metadata often needs to delegate that decision.

Will identity/grants slow broad adoption?

Possibly. But many once‑complex things become default—compressed files, columnar formats, soon encryption. With collaboration (like Variant), we’ll land broadly accepted patterns.

Chapters

00:01:30 — Guest welcome and interview start

00:02:00 — Russell’s path: DataStax Cassandra, Spark connector, interoperability

00:05:20 — Joining Apple’s Iceberg team and early Iceberg momentum

00:06:20 — Why migrations resonated: replacing bespoke Hive/HDFS compaction/locking

00:09:10 — Apache governance 101: PMCs, consensus, and corporate influence

00:15:40 — How decisions land without votes; when vetoes apply

00:18:30 — Who needs Iceberg and where it fits

00:22:20 — Lake → lakehouse and warehouse → lakehouse in the cloud era

00:25:20 — Iceberg versions: v1 transactions, v2 row‑level ops (GDPR), v3 types

00:28:10 — Standardizing Variant across vendors and Parquet

00:31:10 — Iceberg v4 goals: streaming commit/retry improvements and AI use cases

00:33:40 — Commit latency and server‑side conflict resolution

00:37:20 — Polaris as an Apache incubating project (PPMC)

00:39:30 — Iceberg REST catalog spec and Polaris implementation

00:42:30 — Clarifying Snowflake Horizon, Polaris, and external REST catalogs

00:45:10 — What Polaris aims to be best at; pluggable identity providers

00:48:00 — Identity scope: business vs. system catalogs and credential vending

00:51:00 — Will identity/grants slow mass adoption?

00:52:50 — Wrap‑up

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Demo on-demand

In this episode of The Analytics Engineering Podcast, Tristan talks with Lauren Anderson, who leads the enterprise data platform at identity company Okta. Lauren discusses how identity sits at the center of two seismic shifts in data—AI agents and the open data lake—and why central governance and a shared semantic layer are critical. She lays out how analytics engineers and data engineers should divide responsibilities as agents begin to write a growing share of analytical queries.

A lot has changed in how data teams work over the past year. We’re collecting input for the 2026 State of Analytics Engineering Report to better understand what’s working, what’s hard, and what’s changing. If you’re in the middle of this work, your perspective would be valuable.

Take the survey

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• Youtube

• RSS feed

Key takeaways

Tristan Handy: Before we dive into the current day, can you share a little bit about your background and how you came to the role that you’re in today.

Lauren Anderson: I’ve had a 20‑something year career at this point. I have basically spent my entire career in analytics some way, but my first data job was at a big bank. I won’t name it. There’s only a few big banks you could probably guess. I worked for the finance org and I did compensation planning and administration, with a side of sales tracking and analytics. I was part database analyst, part customer support for people that made a lot more money than I did.

I was there for seven, seven and a half, eight years. Towards the end of it, I became the owner and creator and almost business architect for our brand‑new sales tracking data warehouse. At a very young age, I got to think about how relational databases should come together for the outcome of both analytics and reporting—dashboards and whatnot—but also operations, which was paying compensation every month. It got me super excited about this world of data and being able to architect pipelines and the end‑to‑end flow for real‑world outcomes.

What do you think allowed you to be successful in that era? I often think the things that enabled success then aren’t the same as what make data folks successful today.

When I took it over, we ran compensation out of an Access database. I was new, the person who designed it left, and there wasn’t much documentation. It worked the first month, then broke the second—right before a payroll deadline. I rebuilt it as a long series of SQL queries with inline comments and step‑by‑step checks that produced a clean file. That willingness to throw away the brittle thing and rebuild with clarity and documentation gave me early success. The meta‑skills:ability to learn, take chances, and figure out the best path—still apply, but the technology is completely different now.

You’ve split time at Okta into two stints. How would you characterize the work?

Okta was my first truly B2B company. I realized quickly B2B data is my sweet spot. I love thinking about customers as businesses and how business users interact with our products and features. Okta data is complex—many products, features, and highly configurable use cases—especially with large customers. That variety is exciting. In simpler retail flows you see a lot of the same patterns; in B2B, the variety is the appeal.

What’s your current role?

I lead our enterprise data platform, engineering, and architecture function. For enterprise data used to make business decisions, we own ingestion into the warehouse, transformations, and delivery—dashboards, reverse ETL to third‑party applications, other data stores, and internal apps.

How big is the central function and how do you engage with the business?

We’re about 50 people across data engineering and analytics/data science in a company south of 7,000 employees. We support every business unit. Engagement spans a maturity curve. One end is platform self‑service: teams land data via approved connectors, build transformations in dbt on our implementation, and build dashboards in Tableau we administer. Governance and roles are defined centrally, and teams assign people to those roles. The other end is a white‑glove model where we partner through the full lifecycle—question, discover existing assets, requirements, data work, build, interpretation, validation, and end‑of‑life of the data product. Our sweet spot is the middle: we own enterprise “gold” pipelines for company‑level metrics—monitored and governed—while domains build and later graduate via a path‑to‑production under stronger governance.

Okta is known for identity and security. How does security‑first actually work in practice?

Reinventing controls every time slows you down. We invest in repeatable frameworks. Any new source goes through third‑party risk review, classification, and decisions on masking or exclusions. We help teams through that; after a couple times, they can engage directly with risk while we stay in the loop and monitor. As our classifications and expectations got clearer, review cycles shrank from weeks to days. It’s not all roses—it takes time—but we all operate as security practitioners. That shared mindset builds trust and reduces corner‑cutting.

How much do users need to know?

We don’t expect everyone to know everything. We provide dbt frameworks and minimum testing standards, plus SMEs to guide teams. The culture is to ask when unsure.

Will agents write more analytical queries than humans in the next 12–24 months?

Macro, yes. For us, more like 24–36 months because we’re careful. The key is safe, ethical AI consistent with being a security company.

How are you thinking about agent access?

Central governance. Ideally, agents query centralized, agent‑ready stores. Run governance once: policies, roles for users and for data, tracking and logging on a central plane. The semantic layer is essential. Creating semantic views must get easier and more automated, and semantics should inform policy application.

Why are agents different from humans in access patterns?

Row‑level security to the extreme. Conversational intelligence data should be limited to what the requesting user can access. Aggregations could be broadly accessible with anonymization, but detailed content should remain constrained. You might also limit allowed functions on large unstructured objects. Identity for agents matters—Okta Secures AI looks at distinct identity patterns to secure agents across applications.

Where are you with MCP and agent building?

Early, building support and insight use cases. Progress is fast, but nothing broad in production yet.

How should analytics engineers and data engineers participate?

Analytics engineers should own semantics—tooling, vendor choices, onboarding use cases, and the shared business language. Data engineers should optimize for consistency and scale, notice overlap across agents, and provide a platform others can build on with confidence in governance and security.

Will you standardize an agent development platform?

Yes, in partnership with engineering and shared services. Our current pull skews to the business, so we’re leaning toward accessible, governed platforms that serve both business and engineering with central governance.

Any assumptions you’re rethinking?

Treating everything like a relational model. Many initial agent questions are intentionally simple, where speed and reasonable accuracy trump perfect sophistication. The important thing is to start, observe, and mature.

Chapters

00:02:28 — From bank analytics to owning a sales DW

00:05:00 — Rebuilding brittle Access → SQL with documented checks

00:08:30 — Ops accountability then vs. optimization today

00:11:00 — TripIt, marketing analytics, and moving into tech

00:13:14 — Why B2B data became Lauren’s sweet spot

00:16:00 — Current role: ingestion → transform → delivery at Okta

00:18:10 — Operating models across business units and the path to production

00:22:20 — Security-first in practice: repeatable frameworks over friction

00:24:23 — Third‑party risk, classification, and shrinking review cycles

00:28:00 — Policies, masking, and the need for a central governance plane

00:30:20 — Frameworks for dbt, testing, and SME guidance

00:32:11 — Will agents outwrite humans? Macro yes; Okta timeline nuance

00:33:48 — Central governance and agent access patterns

00:37:19 — Semantic layer as bridge and policy carrier

00:41:00 — Function limits on unstructured data and Okta Secures AI

00:42:35 — Early MCP experimentation and support use cases

00:43:03 — Roles: analytics engineers (semantics) and data engineers (scale)

00:46:10 — Enabling an org-wide agent platform with shared governance

00:47:43 — Solve governance once, serve business and engineering

00:49:30 — Simpler questions first; rethinking relational assumptions

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Demo on-demand

In this episode, Snowflake VP of Product Management Chris Child joins Tristan to unpack Snowflake’s AI roadmap and what it means for data teams. They discuss the evolution from Snowpark to Cortex and Snowflake Intelligence, how to govern agents with row- and column-level controls, and why Snowflake is investing in Apache Iceberg and the Open Semantic Interchange initiative. dbt Labs recently open sourced MetricsFlow, the technology that powers the dbt Semantic Layer, to align with the goals of OSI.

Chris also shares a vision for the next five years of data engineering: fewer bespoke pipelines, more standardization and semantics, and a bigger focus on business context and data products.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Check out the dbt VS Code extension

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• Youtube

• RSS feed

Key takeaways

Tristan Handy: Where have you spent your time professionally?

Chris Child: I didn’t end up in data on purpose. I found myself here through a series of hops. I was working at Redpoint Ventures and got excited by a company we invested in, RelateIQ. I left to join RelateIQ, building an intelligent CRM. We captured emails and meetings and built profiles of everyone you interacted with. We were acquired by Salesforce. Looking at what sales teams needed, I realized they also needed product usage data, marketing data, and campaign data, with a platform to pull it all together. That led me to Segment. I joined when it was about 50 people. Segment was mostly analytics.js then, loading different JavaScript on your webpage for tracking. We had just built the first warehouse connector to Redshift and got huge usage sending click and user data to Redshift.

The original Redshift connector was a nightmare to work with.

Like many startup things, one engineer built it in a week. Suddenly a ton of people used it, and enterprise customers depended on it. We had to rebuild it several times. You could see the future there. Folks I worked with went on to start companies like Census and Hightouch, thinking the CDP should be built on top of the warehouse, which Segment evolved toward. We also built a Snowflake connector because customers demanded it in addition to Redshift.

It’s funny to think back a decade to how small Snowflake was.

A couple customers demanded it; we built it, and we were sending a ton of data. That led to the realization that a customer data platform is one instance of a data warehouse, and there are others you need. Seeing how fast Snowflake was growing, I wanted to build the next layer of infrastructure.

I joined Snowflake seven and a half years ago. I’ve had three key roles. First, I built areas of the product: the UI, billing, product-led growth engines and free trial infrastructure, and application capabilities for connecting into and building on Snowflake. After Sridhar became CEO, he asked me to reconnect product and sales by leading solutions engineering, reporting to the CRO. Leading a global technical seller org was very different for a product person, but it helped align teams at scale.

About eight months ago, I returned to lead data engineering: how people bring data into Snowflake, how they transform it—spending a lot of time with dbt—and work around Iceberg and interoperability for worlds where not all data sits in Snowflake.

I didn’t realize the path started in investing. Are you a finance person way back?

My undergrad is in computer science. I started programming in fifth grade on an Apple IIe, learned C before high school, and followed that thread. In college I noticed business folks often made the decisions. I wanted to learn that side. After college I joined a consulting firm, then private equity, then an MBA. I realized I didn’t want to be a finance person. I moved to venture as a bridge to building products, but I wanted to build, so I jumped into operating roles.

Tell the story of Snowflake and AI. In the 2010s there was huge demand for easier, scalable, cloud-oriented data solutions. Then 2022 happened, ChatGPT launched, and the world changed. How did Snowflake respond, and where are you today?

Even pre‑2022 we saw customers putting their most important business data into Snowflake, then pulling data out for things they couldn’t do inside: training ML models and other analyses that SQL wasn’t a great fit for. Customers told us they didn’t like losing governance and lineage when data left. We invested in ways to bring more of that work to Snowflake.

Snowpark was the first big step: a runtime for non‑SQL code (Python, Java, Scala) with APIs inspired by Spark, plus capabilities like forecasting. It’s great for some workloads, but most customers don’t train most ML models inside Snowflake yet. We also acquired Applica for document extraction using early LLM techniques, and Neeva for web search based on LLM approaches.

When ChatGPT arrived, we saw two major influences. First, people wanted to chat with data they’d brought into Snowflake and transformed with dbt. That’s hard because LLMs are great with unstructured data and less great at turning business questions into correct SQL. Second, LLMs are very good at writing code, including Python and even dbt code. They’re not perfect for data engineering code yet, but they help.

Our goal is to help customers activate important enterprise data safely in AI models, deploy agents at scale under existing governance, and keep up with exploding data volumes without 10x headcount.

What are the key product pieces—Cortex, Snowflake Intelligence, etc.—in the Snowflake AI stack?

First, you need a great data foundation. That isn’t new: get the data in one place, apply good governance and permissions, know your data, tag PII, and raise the standard of care.

AI raises the bar because agents can expose sensitive data faster than dashboards. OSI (Open Semantic Interchange) work is part of this; LLMs need explicit semantics and cataloging they can consume, not tacit knowledge hidden in downstream tools.

Companies with strong hygiene move faster with AI. Roles matter; if a product manager role has access to certain rows and columns, an agent acting within that role can safely answer questions. Agents can run inside or outside Snowflake, but should assume appropriate roles when querying.

On the AI stack, after the data foundation, Cortex provides higher‑level APIs for unstructured processing, RAG, and structured processing. You can choose models (OpenAI, Anthropic, Mistral, Gemini, Llama, etc.), but most folks don’t want to manage prompts and GPUs. Cortex AI SQL lets you express intent like sentiment filters or fuzzy joins. It’s powerful for exploration but non‑deterministic, so you need care in production. Costs map to tokens at higher abstractions, with budgets and guardrails similar to variable compute in the cloud.

At the top, Snowflake Intelligence is a UI and agent framework. You define agents with access to specific datasets and semantic models, plus gold queries and usage guidance. It looks like a chat interface over your governed data. Inside Snowflake, we’ve deployed a GTM assistant that blends product usage, Salesforce, notes, docs, and content—structured and unstructured—respecting row‑level security for every seller while giving leaders broader access.

Let’s talk open formats and Iceberg. Why lean in when it opens up the data?

Our aim isn’t to lock up data, it’s to help customers get value. Snowflake began as a reaction to Hadoop—betting on SQL at cloud scale with our own formats and catalog because they didn’t exist then. Those proprietary pieces let us evolve quickly. Iceberg is now almost as good, and we’re contributing to make it better.

Openness is a win for customers and expands the universe of data Snowflake can query, run Cortex on, and power Intelligence with. The tradeoff is standards move slower. Variant type support is a good example—we contributed our approach and shepherded it into the v3 spec.

Next up, the community is wrestling with fine‑grained access control beyond table‑level policies. It’s hard and will take time, but the outcome should be better for everyone.

Give us your view on the future of data engineering.

Data volume is exploding, including unstructured data that’s now usable. You can’t hand‑build every pipeline. Demand is also exploding as agents query more things in more ways. Teams must operate at a higher level: automate, standardize, and reduce bespoke pipelines.

Expect more shared semantic models across consumers and packaged semantics coming from systems like SAP. You’ll also build data‑engineering agents to do work and monitor pipelines. The role looks more like architect and manager, allocating budgets, deduplicating work, and—most importantly—deeply understanding the business. The best data engineers shift from code output to data products, with clear semantics and context.

Talk more about context.

The day‑to‑day activity shifts, but the output is still data products. Great data products come with instructions, definitions, lineage, quality expectations, and how to get correct answers to common questions.

We need that context captured where work happens—models, visualization, quality systems—and made available everywhere: catalogs, agents, and UIs. As you build, you should also document, and those semantics should flow consistently into tools like Snowflake Intelligence so agents can reason correctly.

A big part of the challenge is selecting just‑enough context per question.

Chapters

• 00:01:50 — Chris’s path: RelateIQ, Segment, Snowflake

• 00:05:40 — Roles at Snowflake: product, solutions engineering, data engineering

• 00:09:00 — Snowflake and AI: foundations before ChatGPT

• 00:11:40 — Why keep ML and non-SQL work closer to governed data

• 00:13:40 — Applica and Neeva acquisitions, enterprise search context

• 00:14:50 — Two big AI influences: chat with data and code generation

• 00:16:50 — Scaling agents while preserving governance and cost controls

• 00:18:40 — Why governance must live at the data layer (roles, rows, columns)

• 00:22:00 — Inside vs. outside Snowflake: how agents assume roles

• 00:23:02 — Cortex: higher-level APIs over many LLMs

• 00:24:06 — AI SQL: joins/where by intent and the non-determinism tradeoff

• 00:27:40 — Cost models, tokens, and guardrails

• 00:29:10 — Snowflake Intelligence: agents over a governed foundation

• 00:32:10 — Open formats and Iceberg: Why Snowflake leaned in

• 00:36:00 — Standards tradeoffs: variant type and community progress

• 00:38:40 — Fine-grained access control for Iceberg: thorny but necessary

• 00:40:40 — The future of data engineering: scale, unstructured data, agents

• 00:43:20 — No more bespoke pipelines; standardized models, and semantics

• 00:44:50 — Data engineers as architects and business partners

• 00:50:00 — Code vs. context: data products and shared semantics

• 00:53:10 — Capturing context where work happens (models, viz, quality)

• 00:55:00 — Selecting just enough context for agent reasoning

• 00:56:30 — Closing

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Book a demo

In this episode, Tristan Handy sits down with Chang She—a co-creator of Pandas and now CEO of LanceDB—to explore the convergence of analytics and AI engineering.

The team at LanceDB is rebuilding the data lake from the ground up with AI as a first principle, starting with a new AI-native file format called Lance and building upward from there.

Tristan traces Chang’s journey as one of the original contributors to the pandas library to building a new infrastructure layer for AI-native data. Learn why vector databases alone aren’t enough, why agents require new architecture, and how LanceDB is building a AI lakehouse for the future.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Check out the dbt VS Code extension

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• Youtube

• RSS feed

Key takeaways

Tristan Handy: You’re the founder and creator of the Lance file format and LanceDB. Before diving into vector search and vector databases, tell us about your background.

Chang She: I love talking to analytics engineers because that’s my background. I started about 20 years ago in quantitative finance. As a junior analyst, you do a lot of data engineering and analytics, which got me into open-source Python. I became one of the co-authors of the pandas library—initially to solve my own problem of not wanting to do analytics engineering in Java or VBScript.

You worked for a hedge fund?

Yes, AQR.

Did they know you were contributing to pandas? Hedge funds aren’t known for open source.

My roommate and colleague at the time was Wes McKinney. He showed me a proprietary Python library he was working on. It was life-changing. I started using and contributing. He spent about six months convincing the fund to open-source it. This was around 2010, and they were ahead of the industry in that respect.

I didn’t know pandas started at AQR. That’s fascinating. So much of your circa-2010 analytics work was done in early pandas?

Exactly. We went through several iterations, even debated the name. Because it was a hedge fund, there was a lot of econometrics and “panel data,” so Wes named it “pandas” for panel data analysis.

That origin story isn’t widely known. You then founded two companies, sold one to Cloudera, and were there during an interesting time.

Wes and I created DataPad—cloud BI before cloud BI really took off—and sold it to Cloudera. I spent about four and a half years in the Hadoop “big data” world, where I met my co-founder. He worked on HDFS at Cloudera, and several ex-Cloudera folks are at LanceDB today. After that I moved into machine learning at Tubi TV, working on recommender systems, ML serving, and experimentation/AB testing. That exposed me to embeddings. We dealt with videos, poster art images, and synopses—data that doesn’t fit neatly into pandas or even Spark data frames. That inspired me to build better infrastructure for these data types—what we now call “classical” machine learning—which led to LanceDB.

So that’s our bridge to vectors. You experienced these problems at Tubi, then founded the company. And Tubi used dbt?

Heavily. Thank you for creating it—it was critical to our stack.

Give us a non-technical intro: what are vectors used for?

Many people focus on the latest models and techniques. My perspective: everyone has access to similar models—your differentiation comes from your data and how effectively you connect data to AI. Vectors are a way to represent any kind of data in a form models understand: high-dimensional arrays of floating-point numbers—1,500, 3,000 dimensions, etc. Early statistical models might have a few interpretable dimensions; now you can have thousands where individual dimensions aren’t necessarily interpretable, but the space captures semantics.

Beyond RAG, vectors power internal model representations, recommender systems, and personalization—the original mainstream use case.

Search is also a good use case. How is vector search different from full-text search or Command-F?

Full-text search (e.g., Elasticsearch) returns documents containing the exact terms you searched. If you search for “customer,” it finds “customer/customers,” but might miss “user,” “adopter,” “organization,” etc. Vector search uses dense representations where semantically similar words and documents live near each other in high-dimensional space. Search for “customer,” and you get results that include semantically related terms.

Would you combine vector and full-text search?

Yes—hybrid search. Early RAG demos often used pure vector search for speed. Now enterprises need production-grade relevance. Many combine keyword and vector search with a re-ranking step to reach higher precision/recall.

Early RAG pipelines often chunk text, embed, and call it done. But more thoughtful pipelines do something closer to feature engineering, right?

Absolutely. Thought goes into what you feed the embedding model. For example: add a document- or section-level summary alongside each chunk before embedding; include multimodal features—artistic descriptions, literal captions, tags; create multiple embedding columns (e.g., different prompts/modalities) and search across them with re-ranking. High-quality retrieval requires feature-engineering-like decisions before embedding.

Let’s talk vector file formats (Lance) and vector databases (LanceDB). My crude belief: a vector database is a standard database with additional indexes. True?

Not wrong, but my hot take: with Lance and LanceDB, we’re building a lakehouse for multimodal data that includes vectors. Many “vector databases” are optimized only for vectors and struggle with other data types and workloads. The category needs to evolve—either toward new-generation search engines or new-generation lakehouses. We set out from day one to build the broader lakehouse, not just a vector index.

Outline your AI-enabled data lake vision. I’m familiar with Snowflake and Databricks’ lakehouse. How do you see the world differently?

We assumed everyone would use Parquet and tried for months to support AI workloads—search, training, preprocessing—on it. We couldn’t make it work well. Talking to computer-vision and ML practitioners, no one had something effective. That gave us confidence to build a new format.

In AI you manage vectors, long documents, images, and videos. The first problem is storage. With Parquet, mixing wide blob columns with narrow metadata columns leads to out-of-memory issues due to row-group design. If you shrink row groups to fit blobs, read performance tanks.

Even once data is in Parquet, AI needs random access and secondary indexes. Parquet doesn’t support efficient random row access: retrieving scattered rows forces reading entire row groups. With media, that’s prohibitively expensive—both for search and for training (e.g., global shuffle). Data evolution is also hard: with table formats like Iceberg, backfills often mean copying entire datasets. Copying petabytes of media is a non-starter. These issues motivated Lance.

I have a good mental model of Parquet with structured data. With images or video, do you put them in blob columns?

Yes. We use Apache Arrow types. Images/audio/video are large binary columns. Vectors are fixed-width list columns (e.g., 1,536-dimensional). But Parquet’s row-group mechanics and lack of random access make these workloads painful.

So Lance was the first thing you built. It has solid traction on GitHub. Who uses a file format—users or vendors?

Both. Frontier labs use Lance to store training data—e.g., for image/video generation—replacing stacks like TFRecords, WebDataset, Parquet, and BigQuery. Large tech companies and vendors also build on Lance: Databricks, Tencent, Alibaba, Netflix, NVIDIA, Uber, among others.

Databricks uses Lance?

For parts of their AI-specific offerings.

You’ve raised several rounds—the format is Apache-2 licensed. How do you commercialize?

Our commercial offering is a data platform for large-scale AI production: vector search, data preprocessing, training/serving cache, and an analytics engine for curation and exploration. It supports ML training workflows and AI application development, solving the hard distributed-systems problems along the path. We partner closely with big vendors; we’re generally not competitive because goals and customer bases differ. Cloud providers seek platform consumption; we focus on an AI-optimized data platform for specific workloads and users.

The commercial product is called LanceDB, but you prefer to position it not just as a database.

Right—we’re an AI-native data platform/lakehouse for multimodal data, with Lance as the common format.

How does this space play out over the next two to three years?

Two big predictions. First, multimodal will be 100× bigger—more usage and more data. Audio is exploding; video generation is resurging; robotics is next. Second, our data infrastructure isn’t ready for agents driving search and retrieval.

Let’s unpack both. On multimodal: unlike structured analytics, where every company needs it, multimodal workloads seem concentrated. Do all enterprises really need this?

I think every enterprise becomes multimodal. Take insurance: tons of documents to digitize, extract, search, and analyze; drones capturing images/video to assess risk and improvements over time. Existing businesses become more efficient; AI-native entrants gain structural advantages. Multimodal data underpins both.

It’s a heavy lift. Will every Fortune 500 insurer build these capabilities in-house, or will vendors package them?

Likely both—just like analytics engineering emerged as a role, with adjacent talent re-skilling. We see the same with AI engineering.

What titles are hands-on with your product?

AI researchers and AI engineers. Many app developers building AI features now carry the “AI engineer” title.

On agents: how do their access patterns change platform requirements?

RAG was one-shot: ask, retrieve, answer. Agents iterate: they decompose problems into sub-questions, refine queries and results, and run many steps in parallel. Load skyrockets—humans type slowly; agents can issue hundreds of queries simultaneously. Queries are more varied and selective, and agents are creative in combining modalities and sources: schemas, SQL over structured data, prior analyses and charts, document stores, image/video metadata, etc.

Traditional vector databases aren’t designed for this breadth and scale. If you bolt together multiple specialized systems, your “agent stack” balloons into a maintenance nightmare. Our approach: put all data in one place with a single system that supports vector search, keyword search, filters, key-value lookups, re-ranking, analytics, and efficient random access—on top of an AI-native file format (Lance).

For listeners whose curiosity is piqued, any resources you recommend?

Chang She: Yes—our blog series by Weston Pace, the tech lead for Lance format. It dives into encodings, I/O, and has great reads for analytics engineers: lancedb.com/blog .

Chapters

• 00:00 – Intro: Analytics meets AI

• 03:20 – Chang’s background and how Pandas began

• 06:40 – Lessons from Cloudera and metadata

• 08:30 – Multimodal data and LanceDB’s origin story

• 10:00 – Why vector search matters (beyond RAG)

• 12:00 – What are vectors and why do we use them?

• 15:00 – Full-text vs vector search

• 18:00 – Feature engineering in AI use cases

• 21:15 – Lance format

• 28:00 – Storage, scale, and the problem with Parquet

• 35:30 – Building a business on open source

• 41:00 – Two big bets: multimodal data and agents

• 46:00 – Every company will become multimodal

• 50:00 – Agent access patterns will redefine data

• 54:00 – Why dbt-style workflows matter now more than ever

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Book a demo

What does agentic coding look like in analytics engineering? Mikkel Dengsøe, co-founder at SYNQ, recently wrote a series of posts on his experiences as an analytics engineer with agentic coding tools. In this episode of The Analytics Engineering Podcast, he walks through a hands-on project using Cursor, the dbt Fusion engine, the dbt MCP server, Omni’s AI assistant, and Snowflake.

Tristan and Mikkel cover where agents shine (staging, unit tests, lineage-aware checks), where they’re risky (BI chat for non-experts), and how observability is shifting from dashboards to root-cause explanations delivered to the right person at the right time. Along the way: practical prompts, why “one model at a time” keeps you in control, and a testing philosophy that avoids alert fatigue while catching what matters.

To see real-world use cases of agentic coding and to learn directly from data and AI leaders, join us at Coalesce 2025 in Las Vegas, Oct. 13-16.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• RSS feed

Key takeaways

Can you talk a little bit about your background?

Mikkel Dengsøe: Yeah, so I can start from the beginning. I've been in data for, I think it's coming up to 15 years now, and started my career in data at a Danish shipping company, which was very much zero to one. When I came in, there was no data warehouse, and the only way we could know how many containers were shipped was by an IT guy pulling that out of the system every six months. I then spent two years there building up their data warehouse on SQL Server, which was super fun. After that, I spent five years at Google, which was a very different gear.

That's a natural transition. Just global shipping company straight to Google.

Exactly. And that was very much a hundred-to-end where, in my case, I worked with the ads data and you get a perfectly curated data table that you can work with and everything kind of works. Then after that I joined a company called Monzo. For those who are not familiar, it's a scaling fintech out of the UK and that was very much the one to a hundred. When I joined we were 30 data people, but scaled to a hundred over two years. We had 10,000 dbt models and we built every internal tool under the sun for dbt. Super interesting. And then three and a half years ago I went on to found SYNQ alongside Peter and Steve, which is a data observability platform.

Tell us a little bit more about SYNQ.

We are a data platform that primarily works with companies using tools like dbt already, but have issues going from important data to business-critical data. That might be customer-facing dashboards, machine learning models, or something else. They want better monitoring—we often deploy anomaly monitors—and they also want workflows such as incident management for when things go wrong. We were founded in 2022, so now we're in early stages of working with scale-ups and startups, and now also onboarding enterprises and larger companies. It's been a fun journey.

In your series of blog posts, you went through the modern data stack and said, “What's the most current version of this tool and how effectively can I AI-ify that?” Whether that's using Cursor to build dbt models or using the agent experience inside of Omni—what made you decide to get into this and write about it?

The first part of it is just: it's super fun to tinker with these tools and try them out. It's magic. And we were also building an MCP server at SYNQ, so I had a lot of interest in seeing how it works with others and what we can learn. It was also driven by being able to have conversations with our customers. When they ask about it, being able to speak from the point of view of having actually tried this and seen what works and what doesn't.

The early days of using Redshift were such a visceral experience relative to what came before. If I hadn't interacted with it directly, I wouldn't have understood how big a state change cloud data was. This feels like another one of those moments: if you don't have hands-on experience, you're not going to really get it. Fair?

Spot on. And I think pretty much every data team should be doing this unless they have a very good reason not to. The risk and the stakes can be pretty low if you use it for internal workflows like data modeling and writing tests. You're still in control. I recommend everybody do it.

What tasks did you try to accomplish?

It's three different blog posts: the data modeling part, the testing part, and then exposing it in Omni's AI agent where people can ask questions about the data. There's a fourth post: once the data is live, how can you use the SYNQ MCP to do things like root-cause analysis and planning changes. I started with data modeling. I had raw data from different JSON sources, some XMLs, some profiles—extracted and put into Snowflake—and then did the data model.

So the data was already loaded into Snowflake?

Yeah, exactly. For the data modeling, I started from the sources and then worked through staging, marts, and finally metrics using the semantic layer. Each step looks a little different when you use AI tools because the behavior differs. In terms of tooling, I used Cursor with the dbt-MCP plugged in. If you're not familiar, dbt-MCP lets you, via prompt, interact with dbt tools—execute dbt build, get models, or get everything upstream of a given model—so you can chain work without explicitly doing it.

Cursor + dbt-MCP. What model did you use?

I just used the default in Cursor, which I believe is Claude. There's an important distinction: Cursor is really good at writing code, but it can't execute queries on your behalf. If you want to extract raw data and query Snowflake to get rows out, you have to do that in Claude Desktop. That became key. Early on, as I built models, the first thing I did was get a snapshot of sample data from Snowflake—10,000 rows of a source. I fed that into Cursor and said, “These are examples of what this data looks like.” Using that data, Cursor could model in a clever way. For example, a column called quarter like “2025 Q1”—Cursor understood to translate it into a datetime and do the transformations.

I've used the dbt MCP server a decent amount—less in Cursor, more in Claude Desktop. Your stack was Cursor + Claude models + Claude Desktop. And Cursor cannot directly execute queries in Snowflake, but Claude Desktop can. Is that because there’s tool use Claude has that Cursor doesn't?

I believe so. In Claude Desktop, if you write queries against dbt-MCP, Claude can visualize a graph, show outputs of a SQL statement, etc. Cursor, as far as I know, couldn't. My middle ground was to take sample data out of Snowflake, put it into a CSV, and feed that back into Cursor so it could look at raw data.

As part of its own context window?

Exactly. That was key for my workflow. Then when I wanted to write unit tests, I could use real data examples from the sample. Or when automatically documenting the data, I asked Cursor to specify examples in the docs based on the most common occurrences within a column. Letting Cursor peek at raw data was a core pillar.

It's a little hacky, right? Cursor should really be able to interact directly with Snowflake or Databricks to investigate the shape of the data. Agents should be empowered to do that.

I would say so. There might be a way I didn’t know about, but I patched the gaps by uploading into the context window.

So that's the state of the art today.

Seems so. To be clear, I think the limitation is IDE differences—Cursor vs. Claude Desktop—rather than dbt-MCP itself.

Once you had sample data in context, did you have to suggest conversions, or did it naturally do them?

It got the defaults pretty right, but I guided it on what I wanted from the source data. I wanted control over everything, so I asked it to do one model at a time rather than auto-generate a whole stack. That way I could review each step and stay in control.

Your prompt workflow was “Build me a model with this name that stages the data from this table,” basically?

Yeah. When it proposed code I didn't like, upstream it was usually simple (regex to parse dates, etc.). Downstream, in marts and metrics, I started describing my ideal data product: user jobs-to-be-done and the final output. That’s when Cursor got creative and invented metrics I hadn’t anticipated—like “apartment price relative to time on market.” I pruned ones I didn’t want, but some were good surprises.

Which layer did it help most?

Testing. Modeling was good—especially staging—but testing accelerated significantly. SQL is a bit like English; for simple datasets you can express intent easily. Testing can be much harder and more verbose.

Roughly how much more effective did you feel?

Modeling: multiples faster. It nailed the tedious parts—regex, casting, pass-throughs—so staging/intermediate layers flew. In marts/semantic metrics, the benefit was brainstorming. It helped me think of metrics I wouldn't have.

Did the dbt Fusion engine help?

Yes. Fusion shows lineage and whether a column is pass-through. For example, if a column is pass-through with no transforms, don't add another not_null or unique if there's one upstream. I bounced between the IDE to check this and codified it as a testing strategy. That's already top-10% testing hygiene.

Any MCP feature requests surface?

The more context and tools the agent has, the more it can do. In the fourth post, for root cause analysis, we used the SYNQ MCP. We collect all your Git commits and have history, so the agent could correlate recent code changes with incidents. Requests depend on the job at hand.

Let's move to testing—why was it the most additive?

Testing is hard; many teams don't know how to do it and alert fatigue is common. A huge share of tests we see are not_null/unique, which doesn't reflect real data risks. First thing I did in Cursor for testing was provide our internal testing philosophy as guidelines: test heavily at the source, don't retest pass-through columns, focus on business and metric anomalies in marts. That worked really well. For sources and staging, it generated relevant tests. Then for marts, I asked for unit tests and gave it a thousand sample rows from Snowflake. It wrote very relevant unit tests I’d otherwise spend a lot of time on.

Examples?

Simple ones like: when you pass a string value in the date column, does it transform correctly to datetime and match the expected format? These just worked. Then at the metric level, it looked at raw data and proposed assumptions—like square-meter price should be between X and Y—sometimes segmenting by postcode. Very thoughtful, though I'd replace static thresholds with anomaly monitors so they don't go stale as prices move.

So at least 5× on testing?

At least. Apart from swapping static thresholds for anomaly detection, it nailed testing and did so in a lineage-aware, layer-appropriate way.

Tell me about the BI layer.

Many teams start at the BI layer with a chat interface. I think that's risky because it's used by business users and you only get so many chances before trust drops. I moved into Omni. You create a “topic” (a data model you can join with others) and then specify an AI context: instructions for how the LLM should behave. For example: if a user asks about price, always return square-meter price; never make up fields not present in the mart; if asked about provenance, mention the source. Writing AI context is a new skill for our industry.

Were you using Omni’s AI assistant to create assets faster, or to let users self-serve?

The latter—so users could ask questions instead of going to a dashboard. It could have been any BI tool with similar functionality; we just use Omni internally.

And how was the experience as a consumer?

Amazing when it works, but I'd hesitate to give my VP of Marketing access. It gets things wrong maybe one in five times, and it's not obvious why if you're not a data person. For analysts doing exploratory work, it's great—they can inspect and dig in. I wouldn't replace company-wide dashboards with a chat bot yet. Omni does log freeform queries and feedback, so there's a path to iterate the AI context over time.

The last thing you did was use AI plus SYNQ to monitor production infrastructure. What does observability look like in the future? Historically it's looked like dashboards—Datadog for data pipelines. Is it just more effective monitors, or fundamentally different?

Fundamentally different. We’re heading to a place where observability tools can tell you what's wrong at the right time, with just the right context, delivered to the right person—inside or outside the data team. Done well, there may be few dashboards; instead you get an LLM-summarized root cause delivered from a monitor that might be auto-created. Less “active tool you poke at,” more “proactive explanation.”

Still technical observability (pipelines/data issues), or business observability?

More the former. Teams at the edges—Sales Ops managing Salesforce, engineering teams creating web events—often need to be notified about data issues. Business KPI movements require a different experience for marketers, etc.

Automated remediation?

Gradual. You can imagine an issue occurs without a dedicated test; the system proposes a new test. But 80% of issues come from root systems elsewhere (someone typing in Salesforce), and closing that loop is still hard. In the article’s fourth part, we had a data issue and I asked the SYNQ MCP through Claude Desktop to do root cause analysis. It walked the same steps a data person would: inspect the model, check errors, examine lineage and upstreams, review recent commits, and documented each step to the root cause. That works now.

At the beginning you said there’s no good reason not to use these tools today. What reasons do you hear for not trying?

People are busy. But if you look at a risk curve, lowest risk is modeling and testing—you're in the driver's seat and it boosts productivity. Higher risk is replacing your BI tool with a chat bot; higher still is customer-facing experiences. The first two are hard to argue against.

Enterprise IT approvals might be one blocker—approved models, data access, etc.

True. For example, our MCP can query raw data to detect if an issue happens in a segment, and enterprises might hesitate there. Also, “MCP” as a term can be confusing. But it's actually simple and explainable, not a black box. Setting up dbt-MCP can still feel hacky in enterprises; if it lived natively in cloud environments, it’d be easier to adopt.

You can set it up locally—no permissions/procurement—and just play. We also shipped the MCP server as a remote MCP in cloud, though that introduces auth/permissions considerations.

If I had to pick a persona, it's the analyst. Analysts have had a tough decade: more tools, harder workflows, less time to tinker. MCPs and AI workflows are a turning point. At Monzo, we had a philosophy that you should be able to have an idea on your commute and have it implemented by midday. As we grew to 10,000 dbt models and long CI checks, that faded. I can see a world where this returns. MCPs can help. I'm excited.

I love that. Analytics engineers think “infrastructure, correctness.” Analysts think “idea to validation fast.” Excel was always the analyst’s best friend because it's fast and flexible. MCPs make it easy to plug tools together and get answers quickly again.

One company we work with—Voi, a scooter company out of Sweden—has a strong data leader, Magnus, who is very bought into metrics. Their data team doesn't produce dashboards; they produce metrics. In an AI world with MCPs, flows, and curves, that's a clear decision.

I believe there's no such thing as the wrong BI tool—different tools have different trade-offs. Probably true for models/IDEs too: Claude Desktop vs. Claude Code vs. Cursor—no single “right answer” as long as the underlying context and metric definitions are shared.

Agreed. What really matters across workflows: consistent metric definitions, documentation for columns and fields, and high-quality data. Those foundations matter even more when an LLM is in the loop; you may not have a human sanity-checking every result.

Chapters

• 00:00 — Tristan’s intro

• 01:10 — Mikkel’s background: shipping → Google → Monzo → SYNQ

• 03:08 — What SYNQ does (data observability for business-critical data)

• 04:15 — Running the experiment

• 06:23 — Scope: modeling, testing, BI agent, observability

• 07:17 — Tooling: Cursor + dbt MCP server + Snowflake + Omni

• 09:38 — Sampling real data into the agent’s context

• 13:14 — Modeling workflow: one model at a time

• 15:14 — Where agents help most: testing > modeling

• 18:10 — dbt Fusion engine: lineage-aware checks, fewer redundant tests

• 19:50 — Feature requests and root-cause via commit history

• 20:57 — Testing philosophy: source-heavy, pass-through aware, metric-level

• 22:49 — Unit tests from samples; thresholds vs anomaly monitors

• 25:10 — BI agents: great for analysts, risky for broad rollout

• 31:54 — The future of observability: explain first, dashboards second

• 36:10 — Adoption curve: safe places to start

• 40:49 — Analyst superpowers return

• 42:04 — Metrics over dashboards

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Book a demo

If you're a data practitioner, you likely understand Iceberg as a user, why it's important, and how it's changing the way that we build data systems. But you may not know a lot about what going on beneath the surface.

There are multiple ways to interface with Iceberg catalogs, multiple versions of the Iceberg REST spec. There's several leading catalogs that implement that spec. All this in an ecosystem that includes companies of all sizes, in proprietary and open-source code, and in academic and commercial contexts.

In a few years, all this ambiguity will be behind us, but right now it's very much evolving in real-time. To get an update on the status of the Iceberg ecosystem and to walk through all the developments, Tristan talks with Christian Thiel. Christian is one of the lead architects of Lakekeeper, of one of the most widely used Iceberg catalogs.

To learn more from some of the leaders in the Iceberg ecosystem, join us at Coalesce 2025 in Las Vegas, Oct. 13-16.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• RSS feed

Key takeaways

Walk us through your background

Christian Thiel: I started in natural language processing, then moved into machine learning applications in manufacturing. Like many people, I realized that the biggest barrier wasn’t the algorithms but the data—its availability, quality, and accessibility. That led me deeper into data architecture and engineering, eventually to building Lakekeeper.

What is Lakekeeper, and what are you building now?

Lakekeeper is an Iceberg catalog implementation—a technical requirement for building distributed, composable analytic systems based on Apache Iceberg. But our vision goes beyond that. We see the future in data collaboration and reliable sharing of data, supported by clear contracts.

For listeners new to Iceberg, what makes it so important?

Iceberg allows organizations to store data once, in an open format, and then use the compute engine best suited for each workload. It’s a foundation for building modern, composable data platforms while avoiding vendor lock-in. If there’s one thing that should be open, it’s the data at the center of your platform.

Some folks might say this sounds like Hadoop all over again—lots of open standards that are hard to integrate. Why is this time different?

The ecosystem has matured. Even big vendors like Snowflake and Databricks are embracing Iceberg, which shows there’s a strong shift toward openness. Plus, the tooling and infrastructure are much easier to deploy today. A modern Iceberg setup is far less complex than a Hadoop environment used to be.

Let’s talk about what’s happening under the hood. How does Iceberg work?

Iceberg organizes data using a metadata hierarchy. At the top, there’s a JSON file that stores high-level table information: snapshots, schema, and locations. Below that are manifests and other layers that keep track of files. This hierarchy is what makes things like time travel, atomic transactions, and schema evolution possible.

What about ongoing maintenance?

There are two key tasks. First, expiring old snapshots so you don’t accumulate unnecessary files. Second, compaction—combining many small files into larger ones

Catalogs are another critical piece. What role do they play?

Catalogs manage the top layer of metadata and coordinate transactions. They make atomic updates possible, allow multiple writers, and handle governance—things like access control and multi-table transactions.

How enterprise-ready is Iceberg today?

Very ready. A year ago, there were still gaps, but today, performance and feature parity with native tables on platforms like Snowflake and BigQuery are strong. Governance and authorization models are still evolving, and different catalogs implement them differently, but the core functionality is there.

Speaking of catalogs, how should someone pick between options like Lakekeeper, Polaris, Unity, AWS Glue, or Gravitino?

Christian Thiel: It depends on priorities. Lakekeeper focuses on performance, extensibility, and ease of use. Polaris is developer-focused but less user-friendly. Unity is tightly integrated into Databricks. Glue now supports the Iceberg REST spec, which makes it more interoperable than before. Gravitino is another option aimed at enterprise-scale environments.

Recently, DuckDB announced DuckLake. What’s your take on that?

It’s interesting, but there are two concerns. First, it uses a database schema directly for the catalog, which creates interoperability issues—similar to the early JDBC catalog in Iceberg that the community eventually moved away from. Second, it was built without community involvement, and openness without adoption isn’t really openness.

That said, for heavy DuckDB users, it could offer optimizations that make queries extremely fast, and if the broader ecosystem adopts it, it could become a viable open format.

What’s next for Lakekeeper?

We’re continuing to invest in table optimization, enterprise features, and data collaboration tools. Our vision is what we call the “unbreakable lakehouse,” where contracts and collaboration guardrails make shared data more reliable. Long-term, we see Lakekeeper as enabling truly collaborative, open data ecosystems.

Chapters

• 00:00 – Introduction

  Tristan Handy introduces the episode and the focus on Apache Iceberg.

• 01:40 – Christian Thiel’s background

  From natural language processing to data engineering.

• 04:30 – Introduction to Lakekeeper

  What Lakekeeper is and its role in the Iceberg ecosystem.

• 06:00 – Why Iceberg matters

  How open table formats enable flexibility and reduce vendor lock-in.

• 11:40 – How Iceberg works under the hood

  Metadata hierarchy, catalogs, and how state is managed.

• 21:30 – Maintenance and optimization

  Snapshot expiration, compaction, and keeping tables performant.

• 24:20 – Catalogs and governance

  Access control, multi-table transactions, and security.

• 31:40 – Enterprise readiness

  How Iceberg is evolving for production use in large organizations.

• 42:10 – Choosing the right catalog

  Overview of Lakekeeper, Polaris, Unity, Glue, and Gravitt.

• 47:20 – DuckLake discussion

  Pros, cons, and ecosystem adoption challenges.

• 52:00 – The future of Lakekeeper

  Data contracts, collaboration, and building the “unbreakable lakehouse.”

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Book a demo

In this episode of The Analytics Engineering Podcast, Tristan Handy talks to Sean Falconer, senior director of AI strategy at Confluent, about AI agents. They discuss what truly makes software "agentic," where agents are successfully being deployed, and how to conceptualize and build agents within enterprise infrastructure.

Sean shares practical ideas about the changing trends in AI, the role of basic models, and why agents may be better for businesses than for consumers. This episode will give you a clear, practical idea of how AI agents can change businesses, instead of being a vague marketing buzzword.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• RSS feed

Key takeaways

Sean, can you give us the TLDR on your career and what you're working on today?

Sean Falconer: I've always worked at the intersection of data, engineering, and AI. From academia studying computer science, into industry as a founder, then to Google, I worked on conversational systems and privacy/security in AI. Currently, at Confluent, I'm leading our AI product strategy, balancing both technical and go-to-market roles.

You moved from being deeply technical into marketing and sales. What drove that transition?

I was forced into it as a founder. Initially uncomfortable, but it taught me huge respect for marketing and sales. I had to learn by making many mistakes, eventually building out entire marketing and sales functions. I realized how challenging and critical these roles are.

You were at Google before ChatGPT launched. Did you foresee the transformative nature of these technologies?

Honestly, no. Having seen earlier disappointments in conversational AI (like Microsoft's Alice), I was skeptical initially, even as ChatGPT emerged. It wasn’t obvious we'd soon experience this revolution.

You’ve written about three waves of AI. Can you describe these?

Yes. Wave one was predictive AI, traditional ML models trained for specific tasks like fraud or spam detection—effective but rigid. Wave two introduced generative AI, or foundation models, trained on vast general datasets, flexible but lacking specific business context. The third wave, agentic AI, involves AI systems that can reason, dynamically choose tasks, gather information, and perform actions as a more complete software system.

Do foundation models replace traditional ML methods?

Sometimes they can, but it doesn’t always make sense. An LLM might do sentiment analysis well enough, but a traditional model may be more efficient and cheaper. Think of using an LLM as cutting steak with a chainsaw—possible, but unnecessary.

Let's clarify "agents." What makes software truly agentic?

It’s software that can dynamically decide its own control flow: choosing tasks, workflows, and gathering context as needed. Realistically, current enterprise agents have limited agency to ensure reliability. They're mostly workflow automations rather than fully autonomous systems.

You mentioned a spectrum of agency. Is this similar to autonomy in self-driving cars?

Exactly. Highly autonomous agents are appealing but not practical yet. Most enterprise success stories involve structured workflows with clearly defined boundaries.

Why have agents taken off more in enterprises than consumer apps?

Enterprises have many well-defined, high-value tasks perfect for automation. Consumer scenarios demanding high agency—like planning complex trips—are still too unreliable. Enterprises can benefit significantly even from limited agentic capability.

Is an agent just a microservice?

In many ways, yes. An agent functions like a microservice with extra capabilities (using LLMs for decisions). Deployment considerations like state management and long-running tasks differ slightly, but fundamentally it’s similar.

What tools and frameworks help build effective agents?

Start with frontier models like GPT-4 or Claude. Frameworks include LangChain, Microsoft Autogen, and CrewAI. But for real-world deployment, treat it as rigorous software engineering with observability, scalability, and robustness in mind.

Are organizational barriers bigger than technical challenges?

Yes. AI efforts are often mistakenly tasked to data science teams rather than cross-functional software teams. Successful companies create dedicated teams blending software engineering skills and data expertise to build reliable agentic systems.

What pitfalls should teams avoid?

Avoid building monolithic agents. Break systems into smaller, well-defined units in a multi-agent architecture. Use event-driven frameworks to avoid rigid, hard-to-maintain dependencies.

Chapters

• [00:00] Introduction: What's all the hype about agents?

• [01:10] Meet Sean Falconer: A journey from engineer to AI strategist

• [04:10] Learning marketing as an engineer-founder

• [05:50] Inside Google's AI efforts before ChatGPT

• [09:00] What does it mean to run AI strategy?

• [10:45] Three waves of AI: Predictive, Generative, and Agentic

• [16:30] Will foundation models replace traditional ML?

• [18:30] Defining agents clearly: Beyond the buzzword

• [22:00] The spectrum of agency: From controlled workflows to open-ended tasks

• [25:30] Why agents fit better in enterprises than consumer apps

• [28:00] Agents as microservices: A practical view

• [35:00] What tech stack is needed to build effective agents?

• [37:50] Organizational challenges in adopting agents

• [39:30] Models that are favorites for developers

• [43:30] Why software engineers are best placed to build agents

• [46:00] The technical stumbling blocks in building agents

• [48:00] Concluding thoughts: Beyond POCs to production agents

This newsletter is sponsored by dbt Labs. Discover why more than 60,000 companies use dbt to accelerate their data development.

Book a demo

In this episode, Tristan talks with Andy Warfield, VP and senior principal engineer at AWS, where he focuses primarily on storage. They go deep on S3, how it works, and what it unlocks. They close out talking about Iceberg, S3 table buckets, and what this all suggests about the outlines of the S3 product roadmap moving forward.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• RSS feed

Key takeaways

Operating systems, garage sales, and Xen

Tristan Handy: You’ve done a lot over the last 20 years. Before we get into specifics, can you just share a little about your journey as a software engineer?

Andy Warfield: I just like playing with computers. I studied computer science in Ontario for undergrad, then moved to Vancouver for grad school, then to the UK for a PhD. I worked on operating systems, low-level stuff. I got to work on a hypervisor called Xen, which ended up being used by a lot of cloud providers, including Amazon.

After that, I did a couple of startups, one around Xen. Then I became a professor at UBC, teaching operating systems, networking, and security. Later, I did another startup in storage, and eventually I joined Amazon.

Now I have this highfalutin role—VP and engineer—working across S3, other storage services, and now a bunch of analytics services too. I get to cause trouble in lots of different parts of the cloud.

VP slash distinguished engineer—does that mean you just get to march around telling people how to improve their stuff?

People love that! I’d say about half the time I’m causing trouble—starting things and encouraging new ideas—and the other half I’m helping teams dig out from those ideas. Sometimes I take over a team if we’re doing something especially interesting or innovative, just so I can be closer to the action.

That sounds like a pretty good gig if you can get it.

It’s amazing. I’ve been here nearly eight years, and I still love this job.

The rise of virtualization and the origin of Xen

I want to talk about Xen. You said you were always interested in operating systems, which is kind of a niche fascination. What drew you in?

When I was a kid, we didn’t have much money, so I built computers from garage sale parts in Ottawa. In high school, I found this federal government warehouse that sold off old equipment. I started a little business buying pallets of hardware for cheap, fixing them up, and reselling.

It was chaotic—but I learned a lot. I dealt with machines like IBM DisplayWriters with 8-inch floppy disks and massive dot-matrix printers. Getting them working meant diving into their software and systems.

Eventually I played with Linux, hacked on the kernel, and that all led me into OS research and development.

Tristan: So what is a hypervisor, and why did virtualization become so important in the 2000s?

Andy: There were two big drivers: server utilization and isolation.

Companies had racks full of 1U servers, most of which sat idle most of the time. But they couldn’t share workloads because apps weren’t isolated well—config conflicts, shared resources, etc.

Virtualization allowed multiple operating systems to run on the same hardware, with isolation. It also let you consolidate servers, which had big cost and efficiency benefits.

There was also a technical challenge: x86 processors weren’t designed to be virtualized. That made it a really interesting research problem. We wanted to see if it could even be done—and done efficiently.

Tristan: And Intel eventually started building virtualization support into the hardware?

Andy: Exactly. Our work on Xen and similar projects showed it was possible. That pushed Intel and AMD to add features like VT-x, which made it easier and more performant to run hypervisors.

Tristan: How did AWS end up using Xen?

Andy: I wasn’t part of those internal conversations, but the story goes that a small startup in Cape Town, South Africa, was building a control plane for Xen. That team got picked up by AWS and became the basis for EC2.

Understanding Amazon S3

Tristan: Let’s switch to S3. I think a common mental model is that S3 is just a big pool of SSDs. But that’s clearly not the whole story. How do you explain what S3 actually is?

Andy: That’s one of my favorite questions.

Early on, S3 was like a storage locker. You’d rent space to stash things you didn’t need right away—backups, static files, CDN origins. Latency wasn’t great, but durability and availability were.

Things really changed when the Hadoop community built S3A—an adapter to let Hadoop use S3 instead of HDFS. Suddenly, we had people doing real analytics on S3. The system had enough drives to support massive parallel reads.

Today, workloads are way more demanding. Performance, consistency, and latency matter. We’ve been evolving the system constantly to meet those needs.

Tristan: Are we talking about billions of hard drives?

Andy: I can’t share exact numbers, but yes—it's a lot of hard drives. Some of our largest customers have data spread across millions of drives. And most drives are shared across multiple customers.

Tristan: And these aren’t SSDs?

Andy: Mostly spinning disks, actually. Hard drives are terrible at latency, but they’re cheap and good for bursty workloads. Spreading your data across many disks lets you take advantage of parallelism.

S3’s durability, performance, and scale

Tristan: Let’s talk about S3’s durability promise: 11 nines. How do you achieve that?

Andy: We use erasure coding—a form of RAID-like redundancy that lets you split data into parts and parity blocks. Then we store those shards across different availability zones.

We constantly monitor for failures. Disks die all the time, so we have fleets of processes repairing and maintaining durability. It’s not static. It’s a living system.

Tristan: You must have incredibly precise failure models.

Andy: We do. We track failure rates, temperature sensitivity, vendor behavior—everything. That allows us to be proactive and surgical in how we manage risk.

From Parquet to Iceberg to S3 table buckets

Tristan: I want to talk about table formats. Parquet is everywhere now. And then we got Hive Metastore, then Iceberg. Why did S3 launch table buckets?

Parquet is great, but it’s just files. Customers kept asking for more structured semantics: schema evolution, upserts, ACID transactions.

We saw Iceberg adoption grow rapidly—especially among our largest analytics customers. But they were struggling with operational complexity: too many small files, custom compactors, brittle catalogs.

So we launched S3 table buckets to bring native Iceberg support to S3. That includes:

• Automatic compaction

• A REST catalog

• High-performance access

We wanted to make it easier to treat Iceberg as a storage primitive, not just an analytics backend.

So this is a shift in philosophy—S3 isn’t just object storage, it’s now table-aware?

Exactly. Historically, S3 was just where you stored objects. Now, we’re thinking more about what those objects mean.

We also launched S3 object metadata tables—a way to semantically describe and query your object store, especially useful for AI workloads using retrieval-augmented generation (RAG).

The future of open data and S3

What does the future of S3 look like? Where’s this going?

We’re headed toward more structure, more semantics, and more performance.

Inference workloads are scaling fast. AI models are hitting S3 hundreds of thousands of times per second to do vector lookups. That’s changing how we think about indexing, metadata, and latency.

We want to make S3 the best place to do open, flexible, high-scale data work—from tables to training data to retrieval.

Chapters

[01:42] Meet Andy Warfield

Andy shares his background, including startups, professorship, and his current role as VP & Senior Principal Engineer at AWS.

[05:10] From garage sales to hypervisors

Andy describes his early passion for hardware, OS development, and the origin story behind the Xen hypervisor.

[08:50] Why virtualization took off in the 2000s

Exploring why isolation, utilization, and technical curiosity fueled the rise of hypervisors.

[14:30] Xen vs. VMware and the road to AWS

How Xen became the default for EC2 and the technical differences between virtualization approaches.

[17:35] The origin of EC2 and S3

How a team from Cape Town helped launch AWS compute—and the early days of cloud services.

[20:00] What is S3, really?

Andy breaks down the mental model behind S3: not just object storage, but a scalable data platform.

[22:49] How many drives? More than you think

Why S3 storage spans millions of drives—and how AWS uses scale to deliver performance.

[28:10] The 11 nines durability model

Inside S3’s approach to reliability, failure tolerance, and background repairs using erasure coding.

[32:00] Tail latency and engineering for bursty workloads

Why slow requests matter, and how S3 teams optimize for streaming, AI, and analytics use cases.

[35:20] Iceberg, metadata, and table buckets

The emergence of Apache Iceberg as a table format—and AWS’s new structured storage approach.

[38:00] Why S3 added a REST catalog and compaction

How AWS is simplifying the operational burden of working with Iceberg at scale.

[40:00] A new mental model for object storage

S3 is no longer just about storing files—it’s about managing semantics, lineage, and trust.

[44:00] Looking ahead: S3, RAG, and semantic metadata

How S3 is preparing for the next wave of AI, inference, and context-aware applications.

[47:20] Is Iceberg ready for enterprise?

Andy shares thoughts on enterprise readiness, performance tradeoffs, and real-world adoption of table formats.

[49:05] Wrap-up and reflections

Tristan and Andy reflect on the conversation and where data infrastructure is headed next.

This newsletter is sponsored by dbt Labs. Discover why more than 50,000 companies use dbt to accelerate their data development.

Book a demo

In this episode, Tristan talks to Solomon Hykes, the founder and creator of Docker. They trace Docker’s rise from startup obscurity to becoming foundational infrastructure in modern software development. Solomon explains the technical underpinnings of containerization, the pivotal shift from platform-as-a-service to open-source engine, and why Docker’s developer experience was so revolutionary.

The conversation also dives into his next venture Dagger, and how it aims to solve the messy, overlooked workflows of software delivery. Bonus: Solomon shares how AI agents are reshaping how CI/CD gets done and why the next revolution in DevOps might already be here.

Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.

Listen & subscribe from:

• Spotify

• Apple Podcasts

• Amazon Music

• TuneIn

• RSS feed

Key takeaways

Tristan Handy: I want to get you to give a little background on yourself, where you've been, what you've been up to for the last couple decades. I think many people will know you as the person who kicked off an avalanche that changed how we interact with compute environments by inventing Docker?

Solomon Hykes: Docker is the thing I'm known for. Pre-Docker, I grew up in France. I studied programming in a French school called EpiTech. It was a brand-new, unconventional school where you learned through nonstop programming, which I loved.

Eventually, I got exposed to startups, despite being a complete outsider. I met someone who told me about them, and it stuck in my mind. Still in France at the time, I moved into my mom's house in the suburbs of Paris and worked out of the basement.

By complete luck, I got into an early version of Y Combinator in 2010. That got us on the path to what would become Docker three years later. In 2013, we pivoted to Docker from our previous company, dotCloud.

Tristan Handy: The original thing was called dotCloud, right?

Solomon Hykes: Yep. It was about container technology and its potential, but we didn't quite know how to take it to market. DotCloud was about deploying and hosting people's apps—platform as a service—competing with Heroku and many clones.

Tristan Handy: When did Heroku become a thing?

Solomon Hykes: I became aware of it in 2009. Just as I was struggling in France with container tech. When we joined YC in 2010, we packaged that tech into dotCloud, our hosting platform. Our differentiator was using containers under the hood when others didn’t. That let us support many language stacks and even run databases in containers—which was unheard of at the time.

Platform as a service was a tough business. Most startups went out of business or got acquired early. Eventually, we pivoted from selling the car to building an ecosystem around the engine—that became Docker.

Tristan Handy: Did you pivot because selling the car wasn't working? Or because people kept pointing at the engine saying, “Give me that”?

Solomon Hykes: Both. It was hard to market platforms. Developers expected free hosting, and hosting costs money. Margins were tight because of AWS. It always felt like pushing a boulder uphill. Meanwhile, people wanted to run things locally. There was no good ecosystem for that. Docker provided transparency, flexibility, and portability.

Tristan Handy: Can you define Docker and containerization, and how it differs from virtualization?

Solomon Hykes: Sure. Virtualization splits a physical machine into virtual ones using VMs—each with its own memory, compute, and storage. It gives flexibility, but with overhead.

Containerization does something similar but at the operating system level. Instead of virtualizing the machine, you split the OS itself. It’s mostly done with Linux, which can subdivide itself into isolated units. Containers are more lightweight, letting you run hundreds or thousands, unlike VMs where you might manage a handful before hitting limits.

Docker didn’t invent this, but we solved new problems with it.

Tristan Handy: I remember creating my first Docker container around 2015. I expected a slow boot-up like a VM, but it was instantaneous. Where is the OS in that setup?

Solomon Hykes: Great question. Docker relies on Linux. When you're on a Mac, it runs Linux behind the scenes—today via virtualization. Back then, we used lots of early, rough tools and kernel patches to make Linux containers work. Docker put all the pieces together in a coherent way.

Tristan Handy: So containerization wasn’t new, but Docker made it accessible?

Solomon Hykes:
Exactly. The Linux kernel had features like namespaces and cgroups—building blocks for containers. But they weren’t user-friendly. We made a developer-centric abstraction on top of those tools.

And Linux provided a massive compatibility layer. Unlike Java, which required writing your app in Java, Docker containers could wrap apps written in any language, as long as they ran on Linux.

Tristan Handy: So Docker is like infrastructure as code—a primitive that enables the whole concept?

Solomon Hykes: Yes! And because we wanted ubiquity, we avoided pushing too many opinions. We let developers build on top of it in many different ways. That’s what helped Docker become a de facto standard.

Tristan Handy: How fragmented is the Linux world under the hood? Did you have to do much abstraction work?

Solomon Hykes: We were lucky. The Linux kernel is extremely stable and consistent. But everything above it—distros, package managers, tooling—was chaotic. That chaos created the opportunity for Docker to provide a consistent experience.

Tristan Handy: Were there any drawbacks? Like “Docker sprawl” the way VMware saw VM sprawl?

Solomon Hykes: Definitely. With power comes chaos. Teams would run dozens of Docker containers, each configured differently. Docker doesn’t enforce opinions—by design.

Tristan Handy: And what happened when you left Docker in 2018?

Solomon Hykes: I took time off, became a full-time dad. But I also realized how many unsolved problems remained. Especially around CI/CD pipelines and software delivery—what we now call the software factory.

That led me to start Dagger.

Tristan Handy: So Dagger is like “containers for pipelines”?

Solomon Hykes: Yes. Just as Docker standardized app deployment, Dagger aims to standardize and containerize software delivery. CI/CD pipelines today are often duct-taped together with YAML and bash scripts. We’re bringing consistency and modularity to that space.

Tristan Handy: Will there be a “Daggerfile” like there’s a Dockerfile?

Solomon Hykes: Sort of. But this time, we’re opinionated. Dagger is narrowly focused on CI/CD. That lets us provide APIs, SDKs, and a deeper abstraction stack. We give platform engineers a DAG-based system to define repeatable, containerized steps.

Tristan Handy: And what’s the role of AI and agents in all this?

Solomon Hykes: Great question. We didn’t plan for it, but our community showed us the way. People started building AI agents that run in Dagger pipelines—automating things like writing tests, submitting PRs, and optimizing builds.

That blew our minds. Agents blur the line between development and delivery. They need programmable environments. Dagger is becoming an ideal platform for that.

Chapters

01:30 – Early Days: From France to dotCloud

Solomon shares how his early programming experience and startup journey led to the creation of dotCloud.

04:00 – The PaaS Struggle and Birth of Docker

The team pivots from platform-as-a-service to focusing on the container engine itself—what would become Docker.

07:00 – What Is a Container, Really?

Solomon explains containerization vs. virtualization in plain terms and why it changed the game for developers.

11:00 – The Developer Experience That Won the World

The magic of fast, lightweight Docker containers—and how that first “wow” moment felt.

14:00 – Building a Ubiquitous Standard

Why Docker stayed narrow by design, resisting feature bloat to maximize compatibility.

18:00 – DevOps Before DevOps

How Docker avoided language tribalism and achieved mass developer adoption by choosing Go and CLI-first tooling.

21:00 – Complexity and Container Sprawl

Docker made infrastructure easy—but created new operational challenges at scale.

24:30 – Why CI/CD Pipelines Are Still Broken

Solomon outlines the gap Docker never got to fix: modern software delivery remains brittle and ad hoc.

27:00 – Enter Dagger: DevOps for the Modern Age

How Solomon’s new company is treating pipelines as composable software, not brittle scripts.

30:00 – Building an OS for the Software Factory

Dagger helps platform teams manage the complexity of software delivery with reusable, testable components.

33:00 – Agent-Native Workflows: A Surprise Use Case

AI agents begin using Dagger to reason about pipelines, generate code, and submit pull requests autonomously.

37:00 – Reimagining the Dev Loop with AI

Why the boundary between development and CI/CD is collapsing—and how Dagger fits the agent-powered future.

41:00 – Scaling Trust in Delivery

Tristan and Solomon reflect on how developer tooling evolves and what a stable, fast delivery layer enables.

45:00 – Final Thoughts: What’s Next for DevOps

The conversation closes with predictions on intelligent automation, composability, and the future of platform engineering.

This newsletter is sponsored by dbt Labs. Discover why more than 50,000 companies use dbt to accelerate their data development.

Book a demo