WEBVTT 00:00:00.020 --> 00:00:03.100 Coding agents have gotten really good at one kind of work. 00:00:03.440 --> 00:00:06.760 You scope a feature, edit some files, run the test, ship it. 00:00:07.260 --> 00:00:08.380 It all happens on disk. 00:00:08.920 --> 00:00:10.780 But that is not how data work feels. 00:00:11.100 --> 00:00:14.180 You load something, you look at it, you run a cell, you watch how it responds, 00:00:14.450 --> 00:00:17.580 you decide the next move from whatever is sitting in memory. 00:00:18.200 --> 00:00:20.760 And until now, your agent couldn't see any of that. 00:00:20.940 --> 00:00:23.380 They only saw files, never the live state. 00:00:24.000 --> 00:00:26.220 On this episode, that wall comes down. 00:00:26.580 --> 00:00:32.980 Marimo pair drops a coding agent right inside a running notebook with full access to every variable Python is holding in memory. 00:00:33.610 --> 00:00:35.500 The notebook becomes a shared canvas. 00:00:35.990 --> 00:00:37.720 You point, it runs the code. 00:00:38.100 --> 00:00:41.320 You tell it to zoom in on a graphic and the chart just updates. 00:00:41.920 --> 00:00:49.200 No MCP tools to wire up, no schema to describe, just Python and an agent that can finally see what you see. 00:00:49.880 --> 00:00:53.120 Trevor Manz from Marimo is back to walk us through it. 00:00:53.560 --> 00:00:59.360 This is Talk Python To Me, episode 555, recorded June 30th, 2026. 00:01:17.560 --> 00:01:22.140 Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists. 00:01:22.660 --> 00:01:24.040 This is your host, Michael Kennedy. 00:01:24.480 --> 00:01:27.960 I'm a PSF fellow who's been coding for over 25 years. 00:01:28.620 --> 00:01:29.720 Let's connect on social media. 00:01:30.040 --> 00:01:33.200 You'll find me and Talk Python on Mastodon, BlueSky, and X. 00:01:33.390 --> 00:01:35.320 The social links are all in your show notes. 00:01:36.080 --> 00:01:39.600 You can find over 10 years of past episodes at talkpython.fm. 00:01:39.780 --> 00:01:43.020 And if you want to be part of the show, you can join our recording live streams. 00:01:43.340 --> 00:01:43.800 That's right. 00:01:43.990 --> 00:01:47.260 We live stream the raw uncut version of each episode on YouTube. 00:01:47.660 --> 00:01:52.260 Just visit talkpython.fm/youtube to see the schedule of upcoming events. 00:01:52.520 --> 00:01:56.140 Be sure to subscribe there and press the bell so you'll get notified anytime we're recording. 00:01:56.880 --> 00:01:58.460 This episode is brought to you by Sentry. 00:01:59.220 --> 00:02:02.220 You know Sentry for the error monitoring, but they now have logs too. 00:02:02.460 --> 00:02:05.220 And with Sentry, your logs become way more usable, 00:02:05.740 --> 00:02:09.580 interleaving into your error reports to enhance debugging and understanding. 00:02:10.119 --> 00:02:13.280 Get started today at talkpython.fm/sentry. 00:02:14.660 --> 00:02:16.460 Trevor, welcome back to Talk Python. 00:02:16.680 --> 00:02:17.340 Great to have you back. 00:02:17.620 --> 00:02:18.660 Yeah, thanks for having me again. 00:02:19.040 --> 00:02:24.120 We'll probably talk about notebooks, data science, maybe a little bit of AI in the mix. 00:02:24.560 --> 00:02:29.520 Yeah, definitely. We've been doing a lot at Marimo and thinking about how agents can play nice with notebooks. 00:02:30.100 --> 00:02:35.140 I think it's a little bit of an extra challenge, so it's going to be fun to see what you all have in mind. 00:02:35.600 --> 00:02:39.800 Now, before we get into that, it's been a year since you've been on the show to talk about AnyWidget. 00:02:40.060 --> 00:02:43.740 Just give us a quick introduction for folks who maybe didn't listen to that episode. 00:02:43.960 --> 00:02:50.120 Yeah, AnyWidget is both a specification and a toolkit for making interactive UI elements 00:02:50.440 --> 00:02:53.740 that deeply integrate into your interactive programming environments, 00:02:54.080 --> 00:02:55.700 and specifically Python environments. 00:02:56.920 --> 00:02:59.720 It has deep integration into Marimo, which is the company that I work at now, 00:03:00.580 --> 00:03:02.960 where we build a new kind of reactive Python notebook. 00:03:03.360 --> 00:03:05.960 I'm a fan of Marimo. I don't do that much stuff in notebooks, 00:03:06.620 --> 00:03:09.380 but if I did, I would be using Marimo most of the time. 00:03:09.760 --> 00:03:10.880 It's kind of like that Dos Equis. 00:03:11.880 --> 00:03:12.500 Yeah, yeah. 00:03:13.090 --> 00:03:17.160 I like to, depending on the ilk of user that we have, 00:03:17.380 --> 00:03:19.260 I like to make the joke that there are often 00:03:19.520 --> 00:03:24.280 a certain group of folks that have plenty of notebook friends 00:03:24.480 --> 00:03:25.960 but don't really use notebooks themselves. 00:03:26.500 --> 00:03:29.400 And I'd like to at least pitch why I think Marimo 00:03:30.000 --> 00:03:31.820 scratches the itch of many more software developers 00:03:31.990 --> 00:03:34.060 and represents more traditional software 00:03:34.320 --> 00:03:36.740 than traditional computational notebooks. 00:03:37.280 --> 00:03:40.739 I think it also kind of is special for people 00:03:41.080 --> 00:03:47.640 We were more on the software development side because it's a little more Python focused instead of special tool focused in that. 00:03:47.800 --> 00:03:49.080 We'll talk about Marimo in a second. 00:03:49.280 --> 00:03:53.780 But like, for example, instead of having IPY and B files, it has just Python files. 00:03:54.180 --> 00:03:56.280 Yeah, we are hyper focused on Python. 00:03:56.640 --> 00:04:04.280 So we're from all the way from the, you know, our file format down to the way that we understand the relationships between yourselves. 00:04:04.640 --> 00:04:06.500 It's all oriented around the Python ecosystem. 00:04:07.120 --> 00:04:10.060 Yeah, that's probably going to pay off a little bit when we talk about this project here. 00:04:10.140 --> 00:04:11.400 Yeah, definitely. 00:04:12.380 --> 00:04:12.700 Definitely. 00:04:13.500 --> 00:04:18.660 All right, well, actually, let's do a quick refresher on just what Marimo is. 00:04:19.060 --> 00:04:19.579 Am I saying that right? 00:04:19.700 --> 00:04:19.980 Marimo? 00:04:20.140 --> 00:04:21.459 Sorry, I should be saying Marimo, right? 00:04:21.760 --> 00:04:22.440 Yep, it's Marimo. 00:04:22.820 --> 00:04:22.880 Yep. 00:04:23.400 --> 00:04:23.580 Okay. 00:04:24.080 --> 00:04:26.140 Give us a quick refresher for people who don't know. 00:04:26.360 --> 00:04:30.060 You know, it's sort of in the realm of JupyterLab, but also different. 00:04:30.560 --> 00:04:30.780 Yeah. 00:04:31.440 --> 00:04:36.780 Marimo is spiritually a computational notebook, much similar to something like Jupyter or Google 00:04:36.920 --> 00:04:38.180 Colab, if folks have used that before. 00:04:38.800 --> 00:04:43.160 But as we just mentioned earlier in the show, we're hyper-focused on the Python ecosystem. 00:04:43.700 --> 00:04:49.180 And we are also a special kind of notebook in that we are a reactive Python notebook. 00:04:49.560 --> 00:04:55.400 So what that means is that the order in which Marimo understands your notebook is not in the 00:04:55.500 --> 00:04:58.620 order that you wrote the cells, but the actual data flow between the cells. 00:04:58.960 --> 00:05:03.060 And so we understand the relationships between your cells based off of the variables they 00:05:03.100 --> 00:05:04.780 declare and where those variables are used. 00:05:05.120 --> 00:05:11.500 And then we know how to automatically re-execute the notebook to ensure that you don't get to some sort of inconsistent state in your notebook. 00:05:11.890 --> 00:05:19.320 So you can really think of Marimo as you are incrementally building a Python program rather than sort of a scratch pad or a set of logs of like some code that ran. 00:05:19.600 --> 00:05:24.440 It sounds like a minor feature, this reactive bit, but it's not so minor. 00:05:24.740 --> 00:05:33.460 I'll tell you what, like I'm sure people who've done a lot of work with notebooks have had the experience where they're iterating, iterating, going back, editing, making changes. 00:05:33.580 --> 00:05:37.460 and maybe go back three cells, edit something, rerun that cell, 00:05:37.880 --> 00:05:39.620 go down back to where they were and continue. 00:05:39.840 --> 00:05:40.740 Like, why is this? 00:05:40.930 --> 00:05:42.500 It doesn't seem to do anything. 00:05:43.100 --> 00:05:45.180 Or this is not what I expected or whatever. 00:05:45.700 --> 00:05:48.660 And then you realize, oh, because I didn't run the two cells 00:05:49.200 --> 00:05:52.420 or the one cell in the middle that actually used that value, 00:05:52.530 --> 00:05:54.580 which then flowed on to the next, right? 00:05:54.960 --> 00:05:56.960 And basically what you're saying with this Reactive Notebooks 00:05:57.030 --> 00:05:58.940 is unless you overwrite it or something, 00:05:59.440 --> 00:06:01.020 that can't happen with Marimo. 00:06:01.440 --> 00:06:03.560 Yeah, it's essentially when you're working 00:06:03.580 --> 00:06:04.660 something like a Jupyter notebook, 00:06:05.460 --> 00:06:07.500 you, the user, have to do a form of bookkeeping 00:06:07.660 --> 00:06:11.020 to make sure that whatever state exists in the kernel 00:06:11.600 --> 00:06:14.160 is representative of whatever cells you have on the screen. 00:06:14.720 --> 00:06:17.740 And discipline doesn't really scale necessarily, 00:06:17.920 --> 00:06:19.680 or it becomes hard to do that bookkeeping yourself. 00:06:20.100 --> 00:06:22.440 Come on, I don't buy it because look, 00:06:22.680 --> 00:06:30.040 when you go into Jupyter, it says like 27, 34, 57, 58, and then 90. 00:06:30.280 --> 00:06:31.140 And if you see one of those, 00:06:31.300 --> 00:06:32.840 if you're not doing your bubble sorting, 00:06:32.960 --> 00:06:37.060 that's out of order. You know you've got to go back and run it. I mean, we all keep track of this. 00:06:37.880 --> 00:06:42.880 Yeah, but essentially the moment that you get to some sort of complex notebook and state, 00:06:43.280 --> 00:06:48.440 that becomes a lot of cognitive overhead that you as the user sort of have to keep in mind in order 00:06:48.600 --> 00:06:52.660 to ensure that what you're doing is representative, such that when you hand off your notebook to 00:06:52.790 --> 00:06:57.100 someone else, they're able to confidently reproduce that execution that you had in front of you and get 00:06:57.110 --> 00:06:59.740 back to that state. And so with Maremo, we offload that. 00:06:59.840 --> 00:07:00.740 It's just about that, right? 00:07:00.820 --> 00:07:02.080 Like that's obviously a problem. 00:07:02.800 --> 00:07:02.900 Yeah. 00:07:03.320 --> 00:07:07.360 And so at Marimo, you essentially offload that bookkeeping to a system, 00:07:07.820 --> 00:07:10.460 which we do this dependency tracking of your variables 00:07:10.720 --> 00:07:12.280 and where they're declared and where they're used. 00:07:13.240 --> 00:07:16.360 And essentially we can provide guarantees that if you try to do something like 00:07:16.960 --> 00:07:20.000 rerun a cell, we will rerun all descendant cells of that cell. 00:07:20.140 --> 00:07:22.320 Or if you try to redeclare a variable, we'll tell you, 00:07:22.360 --> 00:07:26.840 hey, you already declared this variable and eliminate this problem of hidden state. 00:07:27.160 --> 00:07:29.660 such that when you do end up working on a team 00:07:29.690 --> 00:07:30.640 with more than one individual 00:07:30.730 --> 00:07:32.780 and you want to hand off that artifact to someone, 00:07:33.130 --> 00:07:34.400 they can confidently run the notebook 00:07:34.660 --> 00:07:36.940 and reproduce the execution results 00:07:37.680 --> 00:07:38.660 that you were looking at 00:07:38.670 --> 00:07:39.800 when you ran that notebook earlier. 00:07:40.100 --> 00:07:41.940 Yeah, it pretty much guarantees ordering. 00:07:42.320 --> 00:07:42.440 Yep. 00:07:42.790 --> 00:07:42.900 Okay. 00:07:43.560 --> 00:07:47.820 Also, it's got a really nice modern UI feel, I think. 00:07:49.040 --> 00:07:50.100 It looks good. 00:07:50.270 --> 00:07:51.040 It feels fresh. 00:07:51.419 --> 00:07:52.780 And I don't know, for some people, 00:07:52.960 --> 00:07:54.080 maybe that doesn't matter. 00:07:54.540 --> 00:07:56.200 But to me, I'm working on stuff. 00:07:56.440 --> 00:08:01.360 I just feel better if it's a nice UI and it looks polished instead of old school. 00:08:01.900 --> 00:08:05.400 Yeah, and because we are hyper-focused on the Python ecosystem, 00:08:05.740 --> 00:08:10.000 we've been able to think about common data structures and objects that are in the Python ecosystem 00:08:10.180 --> 00:08:14.260 and then really have polished user experiences for inspecting and understanding those objects. 00:08:14.400 --> 00:08:18.760 So inside of a Marimo notebook, if you load a data frame, whether that's a Polars data frame 00:08:18.800 --> 00:08:23.820 or a Pandas data frame or an IBIS table or anything that implements this data frame protocol, 00:08:24.120 --> 00:08:25.880 which is a standard in the Python ecosystem, 00:08:26.400 --> 00:08:28.200 we can represent and render 00:08:28.260 --> 00:08:29.940 in a really nice interactive table. 00:08:30.380 --> 00:08:31.820 And so we're able to do that 00:08:32.039 --> 00:08:34.140 because we're tailored around this Python ecosystem 00:08:34.520 --> 00:08:36.760 and we're able to polish both the user experience 00:08:36.979 --> 00:08:38.580 on the front end side 00:08:38.760 --> 00:08:40.719 as well as all the way down to the kernel 00:08:41.099 --> 00:08:42.580 in terms of being able to share 00:08:42.640 --> 00:08:44.120 these reproducible notebook documents. 00:08:44.540 --> 00:08:46.040 Okay, yeah, I love it. 00:08:46.200 --> 00:08:47.480 All right, so that's Marimo. 00:08:47.960 --> 00:08:49.200 And what we're talking about today 00:08:49.380 --> 00:08:50.700 is not exactly Marimo, 00:08:51.120 --> 00:08:56.820 but more AI plus notebooks in a particular tool, agent skill. 00:08:56.870 --> 00:08:57.100 I don't know. 00:08:57.700 --> 00:08:59.240 We're going to get into that, what it is. 00:08:59.400 --> 00:09:03.340 But before we do, let's just talk about how do people, 00:09:03.980 --> 00:09:09.240 like what do people do with, say, either Marima or Jupyter or JupyterLab today 00:09:10.060 --> 00:09:11.620 without a tool like Marima pair? 00:09:12.100 --> 00:09:16.180 Yeah, I'd say that the software as I've known it over the past year 00:09:16.180 --> 00:09:18.840 has changed quite a bit for traditional software development. 00:09:19.580 --> 00:09:22.420 And as we started working more and more on Marimo, 00:09:22.920 --> 00:09:26.920 we were using agents to perform more of our traditional software development. 00:09:27.260 --> 00:09:28.780 And many of our users were asking, 00:09:29.680 --> 00:09:31.580 what's the best way to use Marimo with agents? 00:09:31.760 --> 00:09:32.860 Because they've been using Marimo. 00:09:33.380 --> 00:09:35.660 And I think that many different, 00:09:36.480 --> 00:09:40.520 if you'd ever tried out of the box to use one of these coding agents with notebooks, 00:09:40.740 --> 00:09:45.420 whether it be Marimo or JupyterLab or Jupyter or Google Colab, 00:09:46.340 --> 00:09:51.000 there kind of felt like this difference or like awkwardness in that user experience in terms of 00:09:51.750 --> 00:09:57.340 being able to drive that interactive environment in a way that I think was very sort of unsettling 00:09:57.450 --> 00:10:02.580 or unfulfilling compared to traditional software development because you're able to sort of like 00:10:02.720 --> 00:10:07.180 put off your agent on these long-lived software tasks and then come back and have it run the test 00:10:07.210 --> 00:10:13.220 and let it get in these type loops to be able to autocorrect and do this sort of like traditional 00:10:13.220 --> 00:10:14.580 programming and software development. 00:10:15.120 --> 00:10:17.280 But when you tried to apply it to a data problem, 00:10:18.400 --> 00:10:20.140 things would happen where you edit the file 00:10:20.360 --> 00:10:22.420 and then you could get to some inconsistent state 00:10:22.620 --> 00:10:23.200 inside the notebook, 00:10:24.180 --> 00:10:25.760 or the agent couldn't actually see the actions 00:10:25.840 --> 00:10:27.340 that it performed inside that notebook. 00:10:27.820 --> 00:10:30.640 And it wasn't really able to get inside those tight loops. 00:10:30.820 --> 00:10:33.380 And so we really started thinking from the bottom up, 00:10:33.420 --> 00:10:35.260 how can we open up Marimo in such a way 00:10:35.320 --> 00:10:36.620 that it's actually useful to an agent 00:10:36.820 --> 00:10:39.899 rather than just this data source that it can query 00:10:39.900 --> 00:10:45.880 and really try to extend that agent's working environment with notebooks the same way that, 00:10:45.930 --> 00:10:49.040 you know, humans have used notebooks for working on data tasks. 00:10:49.300 --> 00:10:55.940 I think notebooks are particularly tricky for AI to work with because many people know, 00:10:55.940 --> 00:10:56.880 but probably not everyone. 00:10:57.370 --> 00:11:03.120 When you look at a Jupyter notebook, the IPY in B file, you've got your cell definition 00:11:03.310 --> 00:11:05.580 with code or markdown or whatever's in there. 00:11:06.020 --> 00:11:11.340 But also, and this is the part that makes it tricky part of the part, is that all the output. 00:11:11.920 --> 00:11:21.280 So if you've got something that lists out a thousand rows, that's just embedded in the JSON that defines that notebook file, right? 00:11:21.500 --> 00:11:26.340 And so as a Claude Code or a codex or whatever that's going to go through and try to understand it, 00:11:26.480 --> 00:11:30.720 it's got to skim through all of that output, determine most of it is irrelevant to me. 00:11:31.060 --> 00:11:31.840 Some of it is relevant. 00:11:32.400 --> 00:11:33.780 Maybe it was run in the wrong order. 00:11:34.080 --> 00:11:37.860 So if it does try to look at the output, it's actually, right, there's no enforcement of an order. 00:11:37.960 --> 00:11:43.100 And so if it's run in the wrong order, the output might be present and they might want to use it, 00:11:43.140 --> 00:11:47.200 but it's actually wrong because it was run, it's stale from what's actually in there. 00:11:47.340 --> 00:11:51.160 There's a lot of issues, right, to just work directly on the file format. 00:11:51.520 --> 00:11:56.060 Yeah, I think, you know, as we started thinking about this problem, I think that we, you know, 00:11:56.440 --> 00:12:00.779 even ourselves at Marimo started to realize that for notebooks, these file formats are more the 00:12:00.800 --> 00:12:06.620 artifact of the work rather than the source necessarily of the code. And really, it's the 00:12:07.140 --> 00:12:12.200 editor combined with the state, which is how you are authoring these notebooks in this live, 00:12:12.440 --> 00:12:17.740 interactive environment. And that by just allowing agents to use their tools out of the box and edit 00:12:17.790 --> 00:12:23.860 those artifacts on disk, they're missing a lot of the context in which those files are actually 00:12:24.160 --> 00:12:28.459 authored. And they're also, in what you just mentioned, they are polluted with additional 00:12:28.460 --> 00:12:32.780 context that's not necessarily useful to like performing a coding task on behalf of the user. 00:12:33.520 --> 00:12:37.220 Yeah, it's like, hey, Claude, work on this. And by the way, here's 10,000 lines of stuff that may 00:12:37.280 --> 00:12:40.580 either help you or harm you depending on stuff you can't determine really. 00:12:41.280 --> 00:12:47.240 Yeah, exactly. So I think we started to think about this as more, you know, humans, like, 00:12:48.200 --> 00:12:52.160 you know, out of the box, these coding agents are equipped with sort of like the ability to read 00:12:52.160 --> 00:12:57.119 and write files and run bash scripts. And those tools really fit like the tasks of traditional 00:12:57.140 --> 00:13:01.860 software development because that type of like the way that our command line tools and work that we 00:13:01.960 --> 00:13:06.740 do for traditional software development work or that the file system is really the source of truth 00:13:07.040 --> 00:13:11.260 and then you like make changes to those files and then you run sort of these like stateless commands 00:13:11.640 --> 00:13:16.460 that like run your tests or basically take those changes and apply them and see if like what effect 00:13:16.460 --> 00:13:22.340 that those have had and humans you know for data tasks have have sort of gone beyond the tools of 00:13:22.380 --> 00:13:26.139 reading and writing and editing files and running batch scripts and instead we use these really like 00:13:27.120 --> 00:13:31.300 interactive repls or sort of live programming environments for working with data because they 00:13:31.310 --> 00:13:37.320 give us this ability to like iterate on intermediate results and values. So it's not like you run a 00:13:37.480 --> 00:13:40.820 script, maybe you made an error, you have to run that script again from scratch. Instead, we can 00:13:40.870 --> 00:13:45.720 like load a data set into memory and then sort of inspect those values and sort of iterate on them 00:13:45.770 --> 00:13:51.600 in memory. And so like the usefulness of those sort of interactive environments like Excel or 00:13:51.620 --> 00:13:58.760 Jupyter or Marimo or even something like RStudio is that they're stateful. And one problem is that 00:13:58.790 --> 00:14:04.860 these agents weren't really good at accessing those stateful environments. And so that's exactly what 00:14:05.200 --> 00:14:09.100 made it hard for us to open up those environments to agents. And I think there are many different 00:14:09.360 --> 00:14:14.360 approaches that folks have taken. And even we took originally to try to make Marimo a useful tool. 00:14:14.570 --> 00:14:18.380 And it took us a little while to figure out what were the ergonomics that work well for agents. 00:14:19.220 --> 00:14:25.220 Sure. So what you're saying is basically, instead of running on the file system, 00:14:25.780 --> 00:14:29.080 like the coding agents do now for, say, my code, I guess, 00:14:29.560 --> 00:14:32.100 what instead they need is they need to run in the kernel, 00:14:32.640 --> 00:14:35.980 kind of looking at the state of things in the kernel as it's working 00:14:36.560 --> 00:14:38.940 more than, say, regular programming code. 00:14:39.380 --> 00:14:43.240 Exactly. Yeah. Because, you know, when we, as humans have adopted these tools, 00:14:43.260 --> 00:14:45.620 the reason we adopt them is because it's not just the code, 00:14:45.720 --> 00:14:49.180 it's the values and the in-memory representations of those data 00:14:49.280 --> 00:14:54.840 So it's not just that I have this data frame on disk or this file on disk that has my data, 00:14:55.200 --> 00:14:59.080 it's that I want to look at the table and I want to see what those values are. And that may determine 00:14:59.200 --> 00:15:04.640 the next step that I'm going to take with that data of what plots I'm going to do or what validations 00:15:04.740 --> 00:15:09.180 I'm going to run on these data. And so really we had to sort of invert that thinking and think more 00:15:09.340 --> 00:15:15.420 about how do we extend these agents with a useful tool, which is a notebook for doing this sort of 00:15:15.440 --> 00:15:18.200 data work and iterating on those intermediate values. 00:15:20.000 --> 00:15:22.480 This portion of Talk Python To Me is brought to you by Sentry. 00:15:22.930 --> 00:15:26.460 You know Sentry for their great error monitoring, but let's talk about logs. 00:15:27.000 --> 00:15:27.800 Logs are messy. 00:15:28.380 --> 00:15:32.280 Trying to grep through them and line them up with traces and dashboards just to understand 00:15:32.460 --> 00:15:33.900 one issue isn't easy. 00:15:34.480 --> 00:15:36.520 Did you know that Sentry has logs too? 00:15:37.200 --> 00:15:39.160 And your logs just became way more usable. 00:15:39.700 --> 00:15:44.699 Sentry's logs are trace connected and structured, so you can follow the request flow and filter 00:15:44.720 --> 00:15:49.780 by what matters. And because Sentry surfaces the context right where you're debugging, the trace, 00:15:50.080 --> 00:15:55.600 relevant logs, the error, and even the session replay all land in one timeline. No timestamp 00:15:55.740 --> 00:15:59.640 matching, no tool hopping. From front end to mobile to back end, whatever you're debugging, 00:15:59.900 --> 00:16:05.200 Sentry gives you the context you need so you can fix the problem and move on. More than 4.5 million 00:16:05.440 --> 00:16:10.239 developers use Sentry, including teams at Anthropic and Disney+. Get started with Sentry 00:16:10.260 --> 00:16:16.880 logs and error monitoring today at talkpython.fm/sentry. Be sure to use our code talkpython26. 00:16:17.560 --> 00:16:21.120 The link is in your podcast player show notes. Thank you to Sentry for supporting the show. 00:16:22.740 --> 00:16:29.680 Maybe good time to introduce Marimo pair. What is this? Yeah, so Marimo pair is an agent skill 00:16:30.180 --> 00:16:36.459 that drops an agent inside of an active Marimo kernel. And it allows basically it's a single tool 00:16:36.540 --> 00:16:39.380 that allows the agent to run Python code inside of that kernel 00:16:39.620 --> 00:16:42.760 to inspect and perform any sort of understanding 00:16:42.880 --> 00:16:44.660 what sort of intermediate values you have 00:16:44.770 --> 00:16:46.000 inside of your kernel environment, 00:16:46.290 --> 00:16:48.800 but then also drive the authorship of the notebook itself 00:16:48.970 --> 00:16:50.300 and run and execute cells. 00:16:50.710 --> 00:16:52.620 So basically it allows the agent to do anything 00:16:52.690 --> 00:16:54.140 you could do in a Marimo notebook 00:16:55.339 --> 00:16:58.820 and extend your analysis with an agent 00:16:59.040 --> 00:17:01.720 by giving the agent the ability to drive the exploration 00:17:02.410 --> 00:17:03.200 of a Marimo notebook. 00:17:03.500 --> 00:17:03.860 Interesting. 00:17:04.339 --> 00:17:06.800 Okay, so how does it get inside the notebook? 00:17:07.290 --> 00:17:07.740 You know what I mean? 00:17:07.839 --> 00:17:10.540 Do you have to change your code or something like that? 00:17:11.140 --> 00:17:12.060 Do you have to include something? 00:17:13.040 --> 00:17:15.699 Yeah, so the setup is essentially an agent skill 00:17:15.810 --> 00:17:17.260 that you can install either from, 00:17:17.579 --> 00:17:18.819 if you're using something like Claude Code, 00:17:18.870 --> 00:17:20.420 you can install it from the Cloud Marketplace. 00:17:20.630 --> 00:17:23.199 You can install from Codex from a Marketplace as well. 00:17:23.510 --> 00:17:28.459 Or you can use an NPX command to install a skill from GitHub. 00:17:28.980 --> 00:17:31.620 And that skill teaches the agent how to use a single tool, 00:17:31.960 --> 00:17:33.580 which is essentially just run Python. 00:17:34.180 --> 00:17:39.700 And that single tool call allows the agent to run any kind of Python it wants to in the running Marimo kernel. 00:17:40.400 --> 00:17:44.100 So inside that kernel environment, it can do things like list variables that are in the notebook. 00:17:44.420 --> 00:17:48.120 It can inspect the cells of the notebook and look at the outputs of the notebook. 00:17:48.360 --> 00:17:55.920 But then it can also perform sort of user tasks in the notebook as well, like installing packages inside of Marimo or creating cells or running cells. 00:17:57.000 --> 00:18:03.960 But as it's performing those tasks using that tool, the agent gets instant feedback of what went wrong or what went right inside of that kernel. 00:18:04.340 --> 00:18:07.920 and is able to get back into these agentic loops for doing these tasks. 00:18:08.200 --> 00:18:11.720 But using Marimo as sort of the workspace for performing your data tasks 00:18:11.900 --> 00:18:13.680 rather than editing the file system. 00:18:14.060 --> 00:18:15.300 Yeah, okay, that makes sense. 00:18:15.580 --> 00:18:20.640 And I guess there's some kind of API or something that the agent can use to talk to the running notebook. 00:18:21.040 --> 00:18:26.980 Yeah, so we sort of hide an API within Marimo that's called code mode. 00:18:27.340 --> 00:18:30.499 And what code mode is essentially is this semi-private API 00:18:30.500 --> 00:18:34.080 that's just meant for agents that are running Python inside of that kernel. 00:18:34.740 --> 00:18:38.280 And with that API, the agent can grab the current notebook state 00:18:38.420 --> 00:18:40.120 and talk to Marimo directly. 00:18:40.460 --> 00:18:43.140 So it can do things like toast notifications in the UI that say, 00:18:43.340 --> 00:18:46.100 hey, I'm connected to your notebook session. 00:18:46.820 --> 00:18:48.600 It can do things like I mentioned before, 00:18:49.120 --> 00:18:53.420 like list out variables or inspect what cells declare different variables. 00:18:53.940 --> 00:18:56.360 But then also it has these sort of mutation APIs 00:18:56.720 --> 00:18:59.760 where I want to say create cell, edit cell, run cell. 00:19:00.100 --> 00:19:04.260 And because it's all Python and not individual something like MCP tools, 00:19:05.400 --> 00:19:07.100 the agent has the ability to write Python code 00:19:07.200 --> 00:19:11.560 that really does complex composition of those primitives as well. 00:19:11.610 --> 00:19:14.120 So it can create multiple cells at the same time 00:19:14.260 --> 00:19:17.600 just by calling create cell five times inside of some sort of loop. 00:19:18.560 --> 00:19:20.380 Because we're giving it Python as the tool 00:19:20.630 --> 00:19:22.180 rather than sort of a JSON API. 00:19:22.480 --> 00:19:26.199 I'll say, for me, it kind of boggles the mind 00:19:26.420 --> 00:19:30.640 how much Claude Code just relies on grep to understand projects. 00:19:30.880 --> 00:19:33.500 And it seems super inefficient to me. 00:19:33.740 --> 00:19:37.440 I mean, Claude Code was created in two weeks, something like that. 00:19:37.440 --> 00:19:40.640 It feels very much JavaScript-y in that regard. 00:19:40.880 --> 00:19:41.800 Like, look what you built. 00:19:42.200 --> 00:19:44.360 Also, look at the missing pieces a little bit. 00:19:44.780 --> 00:19:49.860 And as impressive as it is, it seems like if it could ask the question, 00:19:50.220 --> 00:19:52.380 where is this symbol used throughout my project? 00:19:53.100 --> 00:19:54.660 What is the value of this variable? 00:19:55.180 --> 00:19:55.720 Things like that. 00:19:55.840 --> 00:19:56.760 What is the type of it? 00:19:57.240 --> 00:20:03.140 Without reading and jumping around 100,000, a million lines of code all the time, it would 00:20:03.140 --> 00:20:03.880 be way more efficient. 00:20:04.000 --> 00:20:07.760 And it sounds a little bit like that's how it interacts with your notebook through Marimo 00:20:07.960 --> 00:20:08.140 Pair. 00:20:08.480 --> 00:20:08.740 Yeah. 00:20:08.980 --> 00:20:13.440 So within that code execution point where it can run Python code, the agent has the ability 00:20:13.500 --> 00:20:17.780 to look at the source of those cells, but then also can look at the in-memory values 00:20:18.400 --> 00:20:19.480 of those cells as well. 00:20:19.860 --> 00:20:24.080 And therefore, it can, like you were just saying, it can look at the type, it can look at the 00:20:24.400 --> 00:20:24.700 values. 00:20:25.880 --> 00:20:29.760 and this type of runtime inspection of values 00:20:30.060 --> 00:20:31.440 really does change model behavior 00:20:31.650 --> 00:20:33.880 in terms of, like I mentioned before, 00:20:34.260 --> 00:20:35.940 allowing them to get into these loops 00:20:36.680 --> 00:20:38.180 and efficiently get to some sort of problem, 00:20:38.960 --> 00:20:41.320 resolution to some task or problem inside the notebook 00:20:41.530 --> 00:20:43.240 because it's able to course correct 00:20:43.550 --> 00:20:46.040 and ask a lot richer information about your values. 00:20:46.960 --> 00:20:48.720 Because if you're looking at a source code on disk, 00:20:49.080 --> 00:20:51.240 maybe for a file that loads a data frame, 00:20:51.550 --> 00:20:52.880 you just have a single line that says, 00:20:53.680 --> 00:20:57.340 you know, load, Polars read CSV or pandas read CSV. 00:20:57.800 --> 00:21:01.640 And then the agent would actually have to go look at that CSV to understand what's in that CSV 00:21:02.300 --> 00:21:04.060 and combining that with the source code. 00:21:04.280 --> 00:21:07.040 But if you pair that with a live REPL like we have inside of Marimo, 00:21:07.560 --> 00:21:11.760 the agent could just say, you know, the agent now has a data frame that it can look at. 00:21:11.940 --> 00:21:15.140 And that's a much richer representation of that static file on disk. 00:21:15.440 --> 00:21:16.820 And then the agent can ask about the schema. 00:21:17.020 --> 00:21:20.800 It could ask about, yeah, the different columns, the data types of the columns. 00:21:20.900 --> 00:21:22.340 It could figure out the number of rows. 00:21:23.000 --> 00:21:35.420 So essentially when you ask a question of, you know, I want to plot the quantitative axes of these data in a pair plot, you no longer have to specify what those axes are because the agent can just go off and look at the schema to figure that out. 00:21:35.580 --> 00:21:50.200 And I think that that provides this really rich experience when you're trying to get something done with your data because you can be a little bit more declarative about like, I want to look at these subsets or these things without having to actually go down and figure out the APIs to plot those things out. 00:21:50.680 --> 00:21:53.200 What's the token economics of this? 00:21:54.120 --> 00:21:57.200 Is it more efficient on tokens because it doesn't have to search around so much? 00:21:57.240 --> 00:21:58.900 Or have you noticed a difference? 00:21:59.460 --> 00:22:00.500 Yeah, that's a great question. 00:22:00.740 --> 00:22:07.400 I think from the skill itself is a pretty slim markdown file that just teaches the agent 00:22:08.200 --> 00:22:12.560 what this tool is and how to use this tool, which is run Python in the running kernel. 00:22:13.180 --> 00:22:18.940 And then the agent is able to, maybe before the agent would read the entire notebook file 00:22:19.000 --> 00:22:20.500 to figure out what you want to do. 00:22:20.840 --> 00:22:24.580 but instead off of disk because it had to orient itself 00:22:24.740 --> 00:22:25.840 where you are inside the notebook. 00:22:26.460 --> 00:22:28.360 Versus if I asked the agent, 00:22:28.500 --> 00:22:30.920 we're focusing on this cell right now inside the notebook. 00:22:31.240 --> 00:22:34.320 The agent doesn't have to print off all the other cells into context. 00:22:34.460 --> 00:22:36.860 It can just focus on that one cell or that one variable 00:22:36.980 --> 00:22:38.760 that we're talking about in the kernel. 00:22:38.980 --> 00:22:41.720 So we haven't done anything formal to compare those things. 00:22:41.940 --> 00:22:44.740 But essentially when you're able to extend the environment 00:22:45.260 --> 00:22:46.700 with variables and values, 00:22:47.100 --> 00:22:50.540 then you give the agent the ability to offload context 00:22:50.560 --> 00:22:53.080 into Python rather than bringing that as extra context 00:22:53.240 --> 00:22:55.440 that fills up your context buffer. 00:22:55.720 --> 00:22:58.500 Yeah, my impression is that first estimate 00:22:58.640 --> 00:23:00.260 is it would be way more efficient, honestly. 00:23:00.820 --> 00:23:03.280 Like a lot of times I'll see Claude Code or something 00:23:03.280 --> 00:23:05.840 and go like, okay, I need to understand what this does. 00:23:06.000 --> 00:23:08.100 Let me write a little Python script 00:23:08.220 --> 00:23:10.920 and execute it with a dash C or what, 00:23:10.940 --> 00:23:12.820 you know, or I can just pass it as a string effectively. 00:23:13.080 --> 00:23:15.080 And it's recreating all these things 00:23:15.420 --> 00:23:16.800 instead of just like print X 00:23:17.160 --> 00:23:19.100 or just give me the value of X, right? 00:23:19.480 --> 00:23:19.820