Let the Agent Cook — with Trevor Manz

Trevor Manz went from measuring plant apertures by hand in a wet lab to building the notebook that lets coding agents take the wheel. The creator of anywidget and founding engineer at marimo (marimo.io/pair) popped into The Test Set to spill on reactive notebooks, why marimo pair threw out every MCP tool but one, and what agents really want out of a data environment. This conversation also features a jacket bouncer, a hidden Python API, and Michael's slow-motion war with the word "marimo."

What's inside:

• Cell order doesn't matter in a reactive Python notebook
• Wet-lab pipettes and Harvard's visualization group, via Raspberry Pi
• The problem with building beautiful tools nobody actually uses
• The reason marimo pair deleted every agent tool but one
• Code mode: the hidden API humans aren't supposed to touch
• What happens when you ship the API your LLM hallucinated

Transcript

0:02

Welcome to The Test Set. Here we talk with some of the brightest thinkers and tinkerers in statistical analysis, scientific computing, and machine learning, digging into what makes them tick, plus the insights, experiments, and OMG moments that shape the field. In this episode, we talk with Trevor Manz. Trevor started out in chemistry and computational biology before moving into visualization research, where he ran into a problem. Researchers could build these sophisticated tools, but getting them into the hands of people analyzing data was another story. That frustration eventually led him towards Python notebooks and to creating anywidget, which makes it easier to build interactive tools that work across the computational notebook ecosystem. Today, he's a founding engineer at marimo, where he's pushing that idea in a new direction. If notebooks are such a useful place for humans to explore data, could they also be a better place for AI agents to do it? And what would AI agents need to use notebooks effectively? We're joined by self proclaimed notebook skeptic Hadley Wickham, which I think makes for a fun discussion. So with that, Trevor Manz. Trevor, welcome to The Test Set. So you're Trevor Manz, scientist, programmer, and as you say, Wisconsinite, which I'm excited to dig into. You created anywidget, and you're a founding engineer at marimo. Yeah. Thank thanks so for coming on. So happy to have you. Yeah. Thanks so much for having me. And by way of introduction, I guess I'm I'm Michael Chow, the host of The Test Set, and this is Hadley Wickham, cohost and chief scientist at Posit. Yeah. True. I'm so excited. I know you've been doing a lot with marimo and notebooks, and especially with marimo pair. I'm I think yeah. I I'm so curious to talk a bit more about marimo notebooks. Maybe just to kick it off, you could explain a little bit about what marimo is and kind of, like, who uses it and what what excites you about it? Yeah. So marimo is, like, a new kind of so sorry. Yeah. My bad. So marimo is a new kind of Python notebook, and I like to describe them as a delightful reactive Python notebook. And the first piece is that we're a delightful notebook insofar as that we've been able to look a lot at how notebooks are used in practice and then really think about creating a very built in user experience for many different ways that notebooks are used, like traditional notebooks are being used. And then the second piece there is that we are a reactive notebook. So similar to observable notebooks or Pluto, which are sort of from the Julia ecosystem, marimo does not marimo understands the relationships between your cells, based off of the ordering that you wrote the cells, but the actual data flow. So where your variables are declared and how they're used to find the execution order of your notebook. And that leads to eliminating this kind of hidden state that can come from having sort of a traditional Python REPL or, like, a traditional Python notebook. And then the third piece is that we are a Python notebook. So we're, like, only focused on Python, and that is all the way from a lot of the user interfaces oriented around data structures that are in the Python ecosystem. We have things like a built in package manager. So for when you're trying to, you know, work on your data, we can sell packages for you, all the way down to the file format itself. It's not like a JSON file. It's actually a Python script. So, yeah, those are the three three things I think that sort of characterize marimo in contrast to other sort of computational notebooks. Yeah. So and I appreciate you helping me with the pronunciation. I feel like this also came up at PyCon when I saw y'all that this is the perfect chance that I'm gonna work marimo in and marimo out forever. So I'm glad that we have this to practice. But Happy to help out there. Yeah. It's interesting to hear too you you mentioned, like, as a package manager and some of that, like, maybe the surprising scope of things that kind of enter in to a notebook. Like, if if you wanna be delightful and and useful, that even it sounds like package management kind of becomes an important piece. So we like to say that marimo is like a, know, we're an open source computational notebook that's used across, like, industry research and and education. And then beyond that, I think as well, from being able to look at the different ways that people are trying to use traditional notebooks, we've we've also thought a lot about, you know, you build up a notebook, but, like, what are the directions that you might wanna take it? So some some notebooks look more like doing, like, data pipelines, and those you can run as as Python scripts and maybe have very few visual elements. There's some that maybe are more in this, you know, world of, like, literate programming where it's both like your code your code is very forward and then you have prose explaining and contextualizing the code. And then we have you know, because we're a reactive Python notebook, the cells can react to user interactions. And so there there's a mode within marimo that we call, like, app mode that you can just hide all of your code and then you just have the outputs. And so for that set of users, it's more like presentational or, you know, showing people almost these like data apps, but without having to to show the code. And I think that's so it's it's quite hard to, like, generalize, like, what that user group is, but I think if I could generalize it, it would be, you know, individuals that are not professional software engineers, but have traditionally learned a little bit of code to do some thing with data. And do you think is it mostly data people broadly construed, or are there people doing non data stuff? With them as well? I'm sure there are I'm sure there are people doing non data stuff, but is that like a is that like a user base you think about? Yeah. I guess one thing I've maybe I've noticed by introducing, like, a reactive experience to an ecosystem like Python, we we do have users that are, you know, trying to build like, they sort of maybe learned a little bit of Python in in their education, and now they have sort of a toolkit or that background with that coding language and now a toolkit that allows them to make, like, programs a bit more interactive. So we do see things like games, I guess, being built inside of marimo. But say in terms of, like, the scope of where we are taking the project, it's definitely oriented around, you know, generally folks have some unstructured data. They're going to, like, load it into memory and, like, yeah, do something with that data. Either that be, you know, perform some kind of analysis or maybe do some sort of, like, presentational scaffolding into, like, an application. Yeah. I guess, like, more, more concrete. That just reminded me of do you know processing? It was like an art, really, like a framework for doing art explorations, and it feels like you could definitely drive a reactive notebook in that direction as well for doing computational art. That would be a cool of application. Have a community member. I'm forgetting his name. I I can share a link. But he he's generate he's a mathematics teacher who has all these really cool generative, like, art displays that he would normally, I think, historically in the past, would write these, like, really these scripts in Matplotlib that, you know, demonstrate some sort of, like a lot with, like, fractals and now, like, being able to, you know, grab that plotting library, add a slider, and now you can, like, play around with that fractal. Yeah. So we definitely have, like like, art that's being generated, but often to, like, demonstrate something some sort of, like, mathematical concept or something that is sort of, I guess, like, coming from more, like, the education side. Yeah. I think hearing your response made me think that, you know, surprisingly, a lot of problems are data problems, you know, whether it's like music or art or different things. So I could say I wouldn't be surprised if marimo is used in kinds of all kinds of use cases that aren't like a data scientist analyze crunching numbers, like for their company. I will say I I love the app mode. I feel like app mode is really killer to be able to go from a notebook where you're analyzing to this kind of like display more dashboard setup has been super cool. And that that kind of made me think of one question. Hadley, do you use much notebooks? I know, like, in our, it's a bit less common. I I'd be curious maybe just for context to hear some of your experience. I think, like, I've never really gotten notebooks. I I and I kinda feel like there's this like, when you you start learning, like, either learn a tool like R with, like, a REPL, and you learn something like, R Markdown, where you, like, kind of render a document, or you go down the notebook path where this kind of, like, intermixed things that you run and text. And it it feels like once you go down one of the those paths, like, the other path just feels, like, weird and unnatural. And, like, it's not like, it obviously, like, people can be successful on either path, but I I don't know if I've met anyone who's like, oh, yeah. Like, I really like R Markdown, and I really like notebooks, and somehow I've, like, synthesized them in in my in my head. So yeah. So, like, when I yeah. Like, I've I've played a bit with marimo, and it just felt, like, really strange, especially the fact that the order of the chunks in the document does not matter. It's only the order of dependencies between them, which it did that did feel a lot more like this literate programming, which, to be honest, I mostly have, like, negative feelings about based on LaTeX documentation manuals for LaTeX packages, which have either of you used LaTeX? Oh, not for so long. Yeah. I think, like, the the documentation packages for LaTeX and the because I've written this this literate programming style which explains how the whole thing works, and you're like, like, there's now a four hundred page PDF that explains how this tool works, and you're like, I don't care. I just wanna know which option do I need to set to do the thing that I want. So I was like, I don't know. I felt like I got burned by literate programming on LaTeX LaTeX package documentation. Yeah. I would say, like, the the extension of or having, like, the that's like, having reactivity and that the cell order does not matter, like, introduces its own set of, like, new sort of, like, trade offs and problems. But but those have been things that we've tried to address more through, like, having different debugging tools inside of the notebooks. If you're, like, focusing on a cell, we have this thing, like, actually inspired from observable that's like a mini map that allows you to sort of jump around and and trace back to, like, where, like, the dependencies of that cells are. So you can kind of, like, focus locally, I guess, on, like, the the step of your analysis that you're working on. But there certainly are trade offs to having, yeah, like, an envy you know, a document that you can read top down. We don't we don't force you to move around your cells, so you could write your notebooks in that way. But we also think that it provides us freedom for when you want to do something in maybe take your notebook in a direction that's more like an app mode. Now you can move around those cells, and you haven't had to, like, switch tools. I think prior to working on a reactive Python notebook, when I had some sort of, like, data task and I didn't wanna make, like, a website and I didn't wanna do, like, a script and maybe it was gonna be, like, presentational, prior to, like, starting on that problem, I'd have to choose, like, think about the tool that I would want to use to, like, start that. So it'd be like, oh, maybe I this will be a Streamlit app or maybe this will be a Jupyter Notebook. Or I'm gonna start working on this library, and I'm gonna, like, prototype that in a notebook. But as I'm working in a Jupyter Notebook, I've I, like, started to get this itch where I'm like, I gotta move this code out of this notebook like, I'm not gonna be able to, like, use this from other files. And I think marimo provides a really nice on ramp for, like, starting with data problems and then a lot of different off ramps depending on, like, what direction you want to take those. Yeah. What direction you wanna take the work that you've done inside that notebook and let's sort of, like, package it up for someone else. I guess what one thing Hadley said that y'all reminded me of is that, I guess, our users do have the problem. Trevor, you mentioned, like, having to switch or choose the right thing for your problem. Like, I have noticed one thing I've because I I've demoed marimo oh, marimo. Alright. We got this to, people at the company because I'm a huge marimo fan. And it is funny. Like, our users sometimes there's this funny switch of, like, you're analyzing data. So you're using a tool like R Markdown or you're you're producing plots. But then when you want a dashboard, you kinda have to, like, copy your code into a dashboarding tool like Shiny. And so there's kind of this funny moment, like, when will I turn that dashboard knob? And I feel like marimo, one thing that it has been really nice is it's the same thing. Like, you're in the notebook, you can interact with the data, you can plot it, but then you could switch to app mode and actually now it is like a reactive dashboard. Yeah. It's a really interesting framing because I think we have tried to do that at various points, like, through R Markdown. Like, you can do dashboards in R Markdown, and we experimented with a way of doing, like, Shiny apps inside R Markdown, but they just never really felt quite right. Like, it it's an interesting trade off, though, because it's like, there there is some yeah. Like, it's it's nice to be able to, like, not have to decide what the final output is gonna be at the beginning, but it is sometimes, like, sometimes your final output, like, shapes the way you think about the problem so much that you do wanna, like, kinda commit to something out which I I mean, obviously, you can do that with marimo. Like, it's not like you you you can't commit to one thing, but it's just that's an interesting it's an interesting problem to tackle. Yeah. And I think I mean, again, there are, like, certainly trade offs as well of, like, deferring that choice, like, upfront, like, in because of what you said in terms of the way that, you know, your tools and approaches, like, shape the way that you think about the problem. But I think what I found increasingly was, you know, I'm biased because I started working working at marimo, but, like, prior to that even, was that a lot more problems felt like well suited for a notebook compared to, like, what I'd been using them for before. And so I find a lot more things now where I'm like, oh, that could just be a notebook. And maybe one day I'll come back to it and and start and pick up where I left off there. And it could be a hybrid of, like, almost like an app or, like, you know, I I work on this project called anywidget. There could be, like, an anywidget that I've thrown in there that I'm playing around with some data, and it doesn't have to be, like, stringing together a lot of different files or projects, and it can kind of just all, like, live in this, like, this thing that resembles something closer to, like, traditional software than, like, a notebook, but isn't also not, like, a a proper, like, program or it isn't, you know, just a clean Python module. Like, it has, like, this runtime and everything as well. So I mean, what I think one thing we should say, like, to be explicit is, like, like, traditional Jupyter notebooks are, like, a JSON file, whereas marimo notebooks are just a Python file with some, like, special annotations. Right? So you can just you can just execute them like a regular like, they're they're an executable thing, not like this weird kinda, like, mix of of a bunch of different things, which makes them, like, very different traditional notebooks. I'm actually so curious to hear a bit maybe going back to your maybe to take a step back and go to your, like, journey into marimo. And and I don't know if being a Wisconsinite has something to do with it, but I actually, like I I was so curious because I noticed you mentioned you're, like, from Wisconsin. Because I understand you went to Kenyon College in Ohio, and then you jumped to Cambridge, in the UK, and then back to the other Cambridge in the US to do a PhD at Harvard. I'm so curious to hear a little bit about your like, the places you've been and and some of that, because you've been so many different places, starting with Wisconsin. Tell us a little bit about the places you've been and and how you've liked them. Yeah. Okay. Yeah. So I'm I mean, I'm yeah. I grew up in the Midwest. I'm from Eau Claire, Wisconsin. Town. Like, it's now I feel like as I'm zooming in on a map or if I'm flying over Wisconsin, you'll, like, see Eau Claire now. So we're big enough that, like, that, like, it'll be one of the few the few cities that, like, pop ups. But it felt very small, like, growing up there. And then I went to like, Kenyon College was in Ohio. It's, like, very small liberal arts college where I studied chemistry and I swam competitively. So I was, like, definitely in like the natural sciences, but did not really, yeah, work with computers that much. I mean, I I use computers. I made websites for fun, but I didn't for my own, like, research. I was very much in a wet lab doing like organic synthesis. So it was felt very distant from the type of work that I ended up doing for my research. Oh, is there a lot around it, like, in Kenyon College? Yeah. So Kenyon College, it's in it's about an hour outside of Columbus, Ohio. So there are about two thousand students. Yeah. Being a liberal arts college, like, I got a bachelor of arts in chemistry. So I studied, like, humanities and things outside of, like, the the the natural sciences as well. And I think it was just a really nice place to have faculty that were, like, very hands on with, like, learning. So, like, you know, in contrast to going to some of the places where I ended up for graduate school, like, the priority at that universe or at Kenyon College was, like, having faculty that were very, like, engaged and, like, trying to get folks into research. So I I had I think it was my academic adviser had a lab, and he was like, hey. If you wanna, like, do some research, you should you should try it out. And I didn't I it sounded interesting. So that's sort of where I started my research career, I guess. Yeah. And then from there, you went to Cambridge. Is that right? Yeah. I tell you, it was like a bit of a journey, I guess. Like, because it was such a small school, I would, like, apply for various, like, summer research internships. And I end up taking, like, a an internship at in Saint Louis, Missouri at this at the Danforth Plant Science Center. And I was doing a lot of, like, wet lab kind of, like, molecular biology stuff, but they ran this workshop with computer vision. And that was, like, the first time that I used, like I think it was a Python program called, like, OpenCV. They gave us, a Raspberry Pi. And I I remember I was, like that summer, I was imaging a lot of, like, Arabidopsis, which is this model organism. And I was measuring all the apertures by hand. And then, like, we ran this, like, computer vision program that, like, I saw, like, kind of automate a lot of that. And I think it was, like, kind of this, like, revelation of, like, oh my gosh. Like, I should figure out how to use this stuff. But, also, it was, like, kinda interesting because we like, it was a very visual, like, output. Like, you could kinda see where it measured things on the actual images and being able to, like, as a human, like, look and observe that, you could kinda see where the algorithms would, like, fail being able to actually, like, highlight a region. And so I think that's I mean, in retrospect, it's easy to, like, construct some narrative of when I started down this path into, like, visualization. But, like, that was probably somewhere where having the somewhat, like, web background and, like, also this, like, science background and seeing, like, how the ways that, you know, visualizations can sort of surprise you or, like, confirm, like, some something that you suspected in the data. It became kind of this interest of mine to see, like, yeah, if if, you know, if I am applying algorithms or using computers to, like, assist my under help myself automate some of this stuff that was really tedious. Like, are there ways that I can bring myself in the loop to make sure I'm, like, pretty confident about, like, the application of those tools? Had you done a lot of computer programming up to that point? Not really. Yeah. I'd I'd mostly, like, web HTML, CSS, JavaScript kind of stuff. And then after that summer, I think when I went back to doing more research, I I got I started, like, trying to use actually, R was the first programming language that I, like, really sat down with to learn for data analysis. Never heard of it. Yeah. Yeah. Yeah. And then I think I just got really interested in, yeah, like, software generally for, like, for doing data analysis. And that sort of led to, I guess, not really like a total pivot, but switching into, like looking more into doing, like, computational research rather than, like, sitting under the hood with a pipette was sort of the the direction that things went. And then from there, you went to Cambridge to do a master's. Were you, yeah, were were you thinking of going, like, the academic route, or kind of where were you at that point? Yeah. I think at that point, I was interested in doing a PhD maybe at some point, but I I had but because because of my background, like, I really wanted to spend a little bit of time, like, doing some software stuff or, like like, data or spending time improving my maths and sort of, like, becoming more of a data person maybe. So that that was an interesting, yeah, like, avenue, I guess. It was sort of like a one year master's. And then after that, I joined into, like, a bioinformatics computational biology program for the PhD. How'd you like Cambridge? Yeah. It was it was really interesting. I mean, like, coming from a very small liberal arts college and then also just being, like, in in the UK, like, there are a lot of differences. Also, like, a lot more European in terms of, like, the the population that was, like, at the school and also in the program. So that was I mean, probably the best part of that experience was making a we had a very small cohort and just making, like, very close friends that now are sprinkled kinda, like, throughout Europe. But, yeah, I think it was it was a much different type of institution than, like, where I went to undergrad. So I think I it also, like, taught me a lot about, you know, priorities in terms of research or, like like, academic priorities for faculty at at different universities. There's something interesting about, I feel like, just all the places kinda you you bounce between. It seems like a big cut of both, like, American Midwest and, like, the UK. So it's interesting to hear about I mean, I had to wear it, a gown sometimes to, like, a dinners at, Cambridge, and that was very like, I remember not even like, thinking I didn't need, like, a suit or something, and then I'm was really happy that I brought one because we oddly were wearing it a good amount. So That actually reminded me. Like, my my dad did his PhD at Cornell, and he had, like, this part time job, like, checking that people were wearing their jackets to dinner. He was like jacket police. Is that Yeah. Like the jacket bouncer. Yeah. And then I guess you mentioned so you you did your PhD at Harvard in the what was the lab called again? Yeah. It's called the we're called the HIDIVE Group now. When I joined the the lead of the lab is Nils Gehlenborg. We we we rebranded at some point, I think, to like a but we're like a a visualization group. So we the way that the the the research that we worked on where we have a lot of close collaborations with, like, experimental biologists in the department or outside of the department at Harvard. And then we kind of work with them to understand, like, their data problems and see if, like, visualization like, yeah, visualizations could help or, like, really connect folks to their data. I think a nice thing with a field like biology is that a lot of the data are very abstract. So there and, like, new types of experiments come out in which you, like, acquire and, like, new information. And so it's, like, kind of this nice interesting pairing for folks that are really interested in developing new visual representations because you have this really abstract data type that you're trying to, you know, come up with new ways to represent that are effective for helping understand information. Yeah. I see. So it's less it might be less about tools necessarily. Like, rather than tools or visualization, you could focus on, like, what visualizations would kinda, like, help people work on these problems or, like, visualize the space well? Yeah. I'd say, like, a pretty, like, classic example example would be something like a genome browser. Like, that's like a very like, the types of visual representations in a genome browser are, like, well known. Like, it's a lot of bars and, you know, like dots. But then the type of data behind it and, like, the idea of, like, overlaying all these different tracks and it being, like, zoomable and, like, pannable and, like, also just laying out the genome, like, linearly, like, that's, like, a chosen representation for that information. Although what I will say is, like, from the the the visualization community, like, when I joined, I was super excited about you know, I'd gotten into working on interested in visualization. Some of my first, like, open source contributions were in sort of, like, visualization libraries. And I think I was just motivated to have something that, like, kind of fit my background, but where I could study visualization and work on it. And and seem like the focus of that community is really on these, like, novel representations or because that is where, like, interesting I don't know. Like, that's kind of like where the field was. And so the types of, like, applications that we or the types of software that we would work on would resemble, like, a lot more, like like, monolithic, like, software applications. Like, it's, hey. We built this, like, viewer for this. And what I found over time was that, like, we ran into all these practical barriers where, like, that might make a really interesting, like, visualization paper, but, like, the field is sort of interested in these, like, new representations, but things that were, like, are kind of, like, boring to the field now, like, still are not being used by, like, practitioners that, like, have their hands on data. And I think that that's where I really started to think, like or I took for granted, like, the cost of the tools that we use. Like, if you are like I use this tool and I work on my data in it every day, and then I come to you and I say, I made another tool for you. It's like, okay. Does that complement my workflow? Are you asking me to, like, throw out my previous thing? Like, how do I get my data into that? Like, these are all just questions that you start to have to either answer with software in that application or, like, workflows to get data in there. And I think I just got kind of frustrated in this feeling that we a community that felt like it had solutions and, like, there was, like, kind of this disconnect back to, like, the folks that would actually benefit from from using them and and understanding their workflows in real ways. I remember going to an IEEE VIS conference a while ago and having this just, like, really strong feeling. Like, these people were like, this is like haute couture. Like, they deliver they're creating these amazing kind of bespoke pieces of art that's tailored to one person. And I was coming in, and I'm like I'm like a buyer at Target. Like, if I can't get this on the back of a million people, like, who cares? Like, it's just such an interesting, like, difference in in perspective. But it just it feels like that like that that there's much more emphasis these days on, like, actually shipping stuff that people like, more than one more than, like, the one research group you're carefully collaborating with can can use. I I think I started to think about it a lot more too is like, I think the reason why it's not like that community set off to, like, build these, like, only specialized applications, but, like, you know, in writing my PhD thesis in the end, I I thought I tried to think a lot about, like, why visualization software is kind of different from, like, other software. And I think a part of it is just that it it touches so many pieces of the software stack. Like, it, like, has like a back end or and it has like this the actual UI layer. So, like, you know, you can you can shell out to different commands from a lot of different applications, but it's really hard to take like this visual thing that was built one way and stuff it in another one if they're built with like totally different technologies. So, yeah, I started to I think I just started to focus maybe there are ways that we could improve our software practices in such a way that, like, we could try to standardize a little bit more how we're building these visual representations such that we don't need to one, we don't need to build, like, the all encompassing tool that does everything, but, like, maybe we can layer on, like, just the visualization layer into an environment where someone already knows what they're doing with their data. And that led me to, you know, looking at notebooks because that was something that I used a lot for working with data, and also our closest collaborators use Python notebooks. And then, yeah, also, there's a a way of extending Jupyter Notebooks with something called Jupyter widgets, and that was sort of how I, yeah, started playing around with this idea of taking, you know, web based visualizations and embedding them inside of the environment where people, you know, people had their hands on data rather than saying, hey. Here's a new application. And sort of giving that feeling of, hey. If there's this library, pip install it and get going rather than like, oh, go to this website, download the software, like, you know, run this script to export into a particular file format and then ingest it. The I mean, the other thing that did change is, like, you could create like, now you can create high performance visualizations in a web browser. And ten years ago, that required, like, you know, C++, Go, twenty years ago. Like, that is another like, that's one of the reasons that it's much so much easier today to, like, distribute this stuff. Yeah. That's that's fair. I guess to the notebook point to yeah. It's interesting because I Trevor, you mentioned, like, all of these applications had to worry about how does data come in. And I guess if you look at it from the notebook side, it's like this kind of substrate can handle that across everyone. And it sounds like you're saying if you then you if you just focus on the visualization part, the notebook can kinda take care of all these activities that every single bespoke app repeats, essentially. Yeah. The the concrete example I like to give is, like, imagine that you have an application that, like, renders points, like a scatterplot application, and someone's like it's like, okay. How do I get my data into that? It's like, oh, okay. We take a CSV as input. Okay. What are the columns of that CSV? And then it's like, but what if I had a TSV, or what if I had, like, a Parquet file? Or, like starts to be that now that you're putting stress on that application to solve that layer of, like, how do I get my data into memory such that I can put it into this visual representation versus in an environment like a notebook, you can kinda just say my data visualization takes a data frame as input, and it should have these columns. And then there's other libraries that the that, you know, someone is interested or that, you know, works in notebooks, knows how to get their data into a data frame. And so you can really focus on, like, the data types, like tabular versus maybe, like, multidimensional arrays or I feel like are kinda, like, the core data types in the data science ecosystem. And then if we just build the visualization layers on top of that, you you sort of reduce the requirement of the front end of having to, like, understand or do that massaging of the data. And instead, you can sort of have a much, like, thinner, like, actual visual representation that you are contributing. Yeah. And then the bit that makes that work is you can now rely on the like, you you can just expect that the end user can, like, program so they can, like, stitch together the one package that does import with another package that does visualization, which again is yeah. Like, it's not always been the case for visualization tools. Yeah. And I think, like, the same way that you could you know, like, the libraries like scikit-learn don't necessarily import or I don't actually know if they do, but, like, have IO primitives in them. It's more like algorithms that you apply to data structures. And, you know, how do you do that for visualizations? It's like, maybe we assume similar data structures, but we just do the visualization side and not so much of, like, the preprocessing. And in marimo, just just to tie it up with a bow too. In marimo, this is a widget. Is that is that right? Yeah. Exactly. So, you know, to complete this, I guess, this thread with, like, Jupyter widgets, I started working on them because they seem like this useful primitive for, you know, extending notebooks with these interactive elements. And just to be concrete, a widget is like a little bit of front end code. So something that runs in your web browser that can embed directly into the output area inside of a notebook. So if you have a cell that runs some code, now you can have, like, some user defined front end code that sits there. But the the really important bit is that also that code has a way of, like, communicating back to your actual where your Python objects live. And so it provides this really rich interface for actually like, I can move a slider, and that changes the value that actually lives in Python, not just, like, in the front end. Like, that state isn't trapped. And so, yeah, Jupyter widgets are the mechanism by which Jupyter defined, like, here's how you sort of coordinate these two worlds. And what ended up happening was at the you know, when widgets first came out, you had this fragmentation of different front ends for Jupyter where you had, like, Google Colab or VS Code or JupyterLab or even classic Jupyter. And because the web browser didn't have, like, a standard module system, they all kind of rolled their own system for, like, how you load third party JavaScript code. And so what that meant was now every widget author, like, had to become an expert in, like, web bundlers and package managers to be able to, like, create something that could be used universally. So I started working on a couple of Jupyter widgets. I'd been working on building, like, you know, web applications because that's how we built a lot of the visualization tools. It just felt like a lot different type of development. Like, it it felt like it was, like, years before what I was familiar with with kind of with modern web development. So anywidget was which is the project that came out of this was originally just a way for me to be able to iterate very quickly on, like, building, like, more of these and make it a little bit more fun where I didn't have to, like, restart my browser and, like, refresh everything to, like, see the updates. It was trying to come up with unifying, like, the way that you wrote that front end code more around how modern browsers talk today and then, like, ingesting that in a bunch of different environments. So I could sort of solve the platform compatibility problem once and then, like, just author this thing that's more a little bit more portable. Just for some context too, I think people like, we'll a lot of people think of anywidget today, but, yeah, having lived through the shift to anywidget, yeah, I I can't overstate how convenient it is to have something run across all these different platforms that I I do feel like that juggling was real of figuring out, like, I can run-in the Jupyter Notebook. Now I've done the work to figure it out for Colette Google Colab. But, like, to have it in one place and not even have to worry about that is so so convenient, seems like. Yeah. And I think also, like and, you know, when you're when I've used pro Notebooks for prototyping, like, Python code, like, I or I maybe to speak more concretely, like, I use notebooks to prototype code because it's a way that I can run little snippets of code and try them out. But in order previously to, like, even just experiment with the idea of, like, a visual output, like a widget, you'd have to, like, create a new Python project and, like, kind of, like, link and, like, start this, like, build process in Bundler. And so, like, you couldn't just, like, play around with, hey. Maybe it'd be fun to, like, draw these things in the web and and put them there. And that was that was probably the the most, like, exciting thing to me originally with any widget was just the fact that inside of a notebook, could, like, start playing with both front end and, like, Python code together and then kind of get these proof of concepts very quickly without having to, like, start a whole new project. So does does marimo, like, extend the Jupyter widget protocol in some way, or is it just much better because it's not reactive? So when one widget changes, the others can update automatically. Yeah. That's a great question. So part of this is that anywidget itself defines a specification not only for, like, the end the people that author widgets, but also, like, what a host platform has to implement in terms of APIs to support widgets. So if you're using anywidget in a traditional Jupyter notebook, that protocol layer is like the host platform, anywidget, the library, like, plugs that in so that you can just load them and, like, run-in those environments. But inside of marimo, we actually, like, natively implement an anywidget API to, like, support the anywidget protocol. So there is no, like, Jupyter machinery inside of marimo, but they do support anywidget. So this thing that sort of started originally as a way for me to be able to author, like, traditional Jupyter widgets and now is is, like, if you author them there, there are even more platforms beyond Jupyter because if they can implement sort of the host side of that front end code. Now you could now you have this contract where basically something's going to load this and render these these arguments, and then you can expect these APIs to exist is basically the the the runtime contract. It's been interesting to see too that a lot of tools, like, used to have these, like, catches. Like, if I'm in Jupyter, do this. If I'm in Colab, do this. It's been interesting to see, like, a lot of big tools switch to just using any widget like that from that kinda, like, if else block of, like, what environment am I in? But from from what you're saying, marimo also uses anywidget's kind of its native, like, widget implementation. Is that Yeah. If you wanna make custom interactive elements, any marimo has special machinery to host anywidgets. And then, like, the widgets themselves sort of have this internal state on the Python side that is currently, like, based off of this library called Traitlets. That's just the the Python side is, like, the anywidget or the machinery. And what you can do is, like, pluck off individual pieces of state from those widgets to observe as reactive values inside of your notebook. So I'll declare my widget. I can I can use a decorator that's called like it's like or a function that's called m o dot u I dot any widget and wrap my widget in that? And that will that will just listen to every single value on that that widget, or you can take individual pieces of state and lift them off of the widget as well. And now you basically are, like, taking that internal reactivity and pulling those into marimo's reactive graph. So now I can, like, reference a value in a different cell, and it it plays nicely by marimo's rules. I'm curious too. I know you mentioned you've been working more lately on marimo pair. Maybe tell us a little bit about marimo pair and the problem that solves. Yeah. I'd say, you know, increasingly, we've start I started using coding agents at work for for doing, like, traditional software development. And we had, like, some initial sort of integrations with, like, coding agents for marimo. But both from our users and, like, my own personal experience, like, there felt just kind of something off when you tried to, like, do something in notebooks. Like, it was like and I couldn't really put my thumb on it at the time, but it was just like, okay. I have this data idea. And, know, with my coding agent, I can just let it loose in like a a folder of a bunch of script or on my file system and just, like, let it rip on a problem. And I'll come back, and I'll I'll have a bunch of scripts and some outputs. But it would like, if I tried to use, like, integrations I'd tried with other types of notebooks or even with marimo at that time, you'd like the way that our integration worked then was sort of we'd edit the, like, the Python file on disk and try to, like, play the different changes back inside the UI. And what would happen is the you know, you let the agent go, and it would just kind of say like, okay. Good. I'm done. Like, it works. And, like, it it, like, wasn't working. There would be some, like, issue in the UI. And then you really felt like you're kind of, like, babysitting this agent, which is like a much different user experience to, like, working on traditional software where it's like, hey. Have these tests. Go run them till you, like, fix the problem. Right? Or, like, it's gonna encounter syntax errors and, like, keep going until it, like, finishes up. So, yeah, marimo pair kind of spawned out of, like, taking a step back at how we're approaching, like, trying to drive like, use notebooks with agents. And I really think our new framing of it is thinking about, like, notebooks, you know, notebooks and stateful environments for coding have been useful for humans to understand data. Is there a way that we can, like, actually make notebooks useful for agents as well for exploring data problems? And so it was not so much as, like, can we use, like, a notebook as nice context for the model, but, like, can the model actually just use a notebook to, like, reason and, like, work on a problem for a while? And that that changed that led to us, like, really changing how we went about, like, exposing our notebooks as a tool for agents. Yeah. I demoed marimo pair for the company at, like, a work week because the fact that in marimo, it can just the the agent seems to be able to do anything kind of like anything I could imagine clicking, it seems like the agent can do. There may be some limitations, but it's it's been so interesting to interact with. Yeah. I'd say, like, previously or the way that I'd read about using something like MCP is, like, it's, you know, model context protocol is this way of, like, taking an application and, like, exposing it to, like, your agent. And the way that we were using MCP before was kind of, like, allowing the agent to query the state of the notebook. So it'd be things like, you know, what are the cells? What are the contents of the cells? Edit you know, what are my variables that are inside of the notebook? But then what you what we realized was, like, you know, when the agent would take an action like writing or mute like doing something in the notebook, it was using its existing tools to edit a file on disk, but it never got feedback for, like, hey. Did something go wrong, like, in that same execution channel? So it was kind of so what the agent would have to get good at is, like, making a change and then querying the notebook of like, and making a bunch of serial queries to be like, did something go wrong? And what we changed inside of marimo pair is we basically got rid of, like, all of our tools, and we just have one tool that is, like, run Python code. And that just runs Python code in the marimo kernel, And there's a hidden, like, Python API in there where the agent is able to control the marimo notebook and ask about the marimo notebook itself. And so when it does something like hallucinate a value or, you know, redefine a variable or something that doesn't play nicely by marimo's rules or Python's rules, it just gets feedback in that same, like, turn that says, hey. You need to change that. Like, that's not working. There's an error, and then it can keep going. And that ability to, I think, have both that read only access and, like, see the effects of the mutations, like, very similar way to, like, when you edit files on disk and then run the scripts to see if they, you know, exit code one or zero. Now the agent can do that at the cell level, and that, I think, allows for this ability for you know, the the the usefulness of notebooks is that you can iterate very quickly. And pre and then when you try to, like, give agents to them previously, it started to feel like, okay. But the agent isn't being very productive in this environment. And I think that that was sort of the missing piece was, like, how do you give them feedback in that same execution channel to seeing, you know, what you're seeing so that you don't have to sit there and tell it that something went wrong. It is interesting that, like, data exploration is, like, so stateful. Like, when you think about, like, traditional software engineering, like, you run your unit tests, and those are all designed in such a way that you start from a fresh session, they run, and you get the results back. But, like, that just doesn't work for data analysis because it's so iterative. You want to be able to look at the state of the thing you just did and you don't have to rerun the whole thing from scratch every time or figure out some complicated caching mechanism. You want to have this long running persistent session that records, like, what have you done to the data. It's interesting. And one, like, interesting property, I think, of having a reactive kernel is that we don't allow for these sort of so we don't allow for things where you, like, can, you know, inside of if marimo pair, if the agent chooses to change a cell upstream, it will see the effects of, like, the downstream cells of making that change. So it it sort of adds this extra layer of guardrails beyond just a normal Python REPL where in order for the agent to, like, continue on a problem, it has to check cells into the notebook and define variables. And then each of those cells has to play by marimo's rules. So it's almost like, you know, yeah, traditional software development is very stateless, but your state is kind of like your file system. Right? So you, like, version that over time, and then it's running these, like, scripts on top of this state that you version over time. And I think very similarly, we wanted to provide a as experience like that in a stateful environment with these guardrails around, like, how you have to check those those cells in. So, you know, in marimo pair, you can't check-in a cell that redefines a variable or something. So it has to play nicely by marimo's rules. And so sort of as a side effect of the agent exploring a problem using marimo, you get, like, a reproducible kind of, like, execution flow. There's a downside to that, though, too, though. Right? Like like, what what what happens if, like, the thing at the end of your at the very end of the reactive graph takes, like, a minute to run? Like, how do you like, I assume marimo most have, like, tools to, like when you don't want things to run all the time to, like, opt out of opt out of that. Yeah. So the contract at in in marimo is that what you see on the screen is a representation of the state in the kernel. And so you can turn off reactivity or disable individual cells, and they will just show as being stale. And then you have to, like, manually execute them. So if I turned on, like, lazy mode, then the agent would get feedback saying you need to rerun these cells, but then it would it could go back and run those cells. It's interesting. Is and what you're describing, I think, for the agent, as I understand, is, marimo code mode. Is that right? The sort of secret backdoor into marimo that an agent can use to basically, like, create cells or edit them. And I I think another thing you mentioned is, like, the connection to marimo that, like, is it right if if the agent, like, deletes a cell that defined a variable, it's like the variable itself is removed? Is that that's kind of part of the maintaining, like, a fresh state. So it's like, in a way, it kind of, like, locks in the agent into having, like, an up to date environment. And I don't know. I thought that was really intuitive that, like, if I as a human also deleted a cell that defined the variable, I would also kind of want it to go away. Like, that's a really classic human blunder to, like, delete the ref delete the code that made it, but still have it, like, floating around in the environment. That seemed like kind of a neat contract to enforce that if the code's gone, that that variable is gone as well. Yeah. It like, it's it's it's a hidden Python API that the agent like, if you read the docs inside of it's like, do not use this like yourself. If you're a human being. If you're a human being. And part of that is that we, you know, we don't to other APIs that we have inside of marimo that we want people to, like, depend on. Like, code mode was something that we've, like, refined over time and we're still, like, changing. And that's part of that is because, like, because it's used within these sessions, the agent learns about, like, what APIs it has available and how to call those in that session versus and that's a much different contract between, like, a model and, like, software versus, like, two pieces of software where you have, like, versioning problems and, like, you really have to make sure that they yeah. Like, if someone was building around code mode that was outside of using agents, they would get very annoyed with us when we made breaking changes versus the model basically gets a new version of marimo, and it has new capabilities or maybe we fix bugs, and it just calls those APIs and can sort of chug along inside the notebook. Presumably code mode is what the marimo UI uses behind the scenes? So most of marimo's UI is driven through, like, the front end, which is, like, JavaScript code. So we've had a lot of, like you know, it's this message I mean, to get technical, it's like this message patch leading system of, like, edits going back to the kernel. You have some piece of state that you're you're updating. But, really, we had to introduce, like, a Python API for driving marimo notebooks because which we didn't really have before, and that made us changing a little bit about how our document model worked. So now you can, like, drive it from Python or you can drive it from the front end, and they can all, like, sort of share that state. But, you know, really the the reason we were able to do that originally was just because our kernel is in Python. Like, so when I first worked on marimo pair, I the first thing introduced was just the ability for the model to, like, run Python code in the kernel, and that let it do basically everything that was, like, read only inside of marimo. So it's like, you know, we have this big set of MCP tools that were like, list my data frame, list my variables. And now it's like, okay. Get rid of all those. You just write the Python code you want to, like, cat out a table, like, print the columns. Like, you can discover APIs. Like, just just call Python the same way if you're running an agent and you see it using Python from the command line, it's like running scripts, like, very quickly. But then and then I think the first thing I did was like, okay. So show me a notification in the UI. And I saw it, like like, try a bunch of different things. And then finally, it found, like, one API where it, like, toasted me a notification. I was like, woah. Okay. Like, how'd you do that? And then, like, we kinda, like, looked back through the code. And so we started to then think about, like, what types of things would you wanna drive from the kernel? And then we hardened those behind, like, a Python API that we could test and such that, you know, you can have high confidence when the agent doesn't have to, like, get the right sequencing of notifications. It just calls an API, and then we we, replay those notifications to the the front end and also make sure the kernel stays up to date. Yeah. It's such an interesting approach. And, also, I do think it's interesting to hear it in contrast to, like, the MCP or tools. There's, a lot of ways to kinda carve this up. Right. I think we have, like, broad like, in the early phases of, like, MCP being a thing, everyone was like, let's make a bajillion MCP tools and then kind of discovered, like, oh, actually, LLMs are, like, way better at writing code in an existing language than trying to figure out some, like, bizarre novel set of tools that you have created. And now, like, I think I mean, MCP still has a has a plays a role, but it's so much more powerful just to give it a few, like, tools that let it write code and do stuff. Like, that's really, really powerful. Like, we basically allow it to do like, we still have a way of running marimo pair through MCP, but there's only one tool, and it's, like, executing Python code. And and I think the other thing that was non or, like, nontrivial to me that when we changed that way of having many tools to, like, one very sharp tool is that programming languages have this, you know, ability to, like, compose different primitives as well. So not like, you don't have a bunch of different tool calls. You could actually in one execute code. It could, like, look at the notebook state. It could, like, create multiple cells, delete cells. Like, you know, those don't have to be individual transactions that you replay, and instead it's like you can leave it up to the, you know, creativity of the model to figure out how to string these things together to accomplish the task that the user wants to do inside the notebook. Yeah. I see that a lot when using Claude to write data analysis code, like, or or write the R code to ask answer, like, three questions at once rather than having to, yeah, like ask us then yeah. I was like, what is the data what are the data frames? What are the variables in the data frame? What are their types? It just does that all at one one swoop and gives a bunch of intonation back to the model. And I feel like just to set the stage too for what like, when I used marimo pair that there's a skill. Like, essentially, it was so interesting to be like, okay. Just use this skill. I was using Claude Code from the command line. Just, like, plug it in. And that Claude code actually could I mean, and this isn't a surprise, install marimo, you know, essentially fire it up on my computer, tab opens in my browser, and then just starts driving marimo, I feel like that was such a kinda eye opening experience to realize, like, there's another world where marimo said, like, hey. Set us up. You know, run the agent from inside marimo, and it could do some stuff. But to watch it actually, like, run realize that we needed a blob on the outside, like, even running marimo, opening it, and orchestrating it was a really interesting experience to to see. And the other thing I'll flag in in correct me if I'm wrong, is that Claude Code is essentially using a CLI, like a bash tool. Is that right? To basically, like, ship this Python code in, this marimo code mode in to run-in the kernel. Is that is that right? Yeah. So if you install the skill from, like, GitHub, which is the way that we recommend doing it, you'll get a bash script that the agent can call that's called execute code. And behind the scenes, what that does is it pings an API endpoint on marimo that we have set up that then replays or kind of maps the that HTTP response back to your standard in, standard out, standard error, and then exit with an exit code of zero and one. And what's cool about that is if you know? So we have a cloud hosted version of marimo notebooks called MoLab that runs, like where you have a kernel that's running in the cloud. And because this is all done over HTTP, you could actually point marimo pair to, like, talk to a remote version of of your marimo that's running. And then you don't even need to have marimo installed locally. You just need curl and bash scripts. So then you can be using Claude and, like, you're driving a a remote notebook as well. So in terms of, like, the distribution ergonomics, that has been, like, really nice in that you you can sort of, like, reduce the system dependency based off of, like, where people want to be running the marimo instance. It's interesting because we I think we in some yeah. Because you can also do the opposite. Right? You can provide a CLI. Like you could have a marimo CLI and if you call marimo agent, then that produces the skill file that tells the agent how to use it. But you distribute the skill, and then it gets the kind of CLI from that as opposed to distributing the CLI, and that gives the agent the skill. Yeah. We've definitely found I mean, part of inside the marimo UI, if you're on any marimo page, you can click in the top corner, and then it says pair with an agent. And we give you this little snippet that you can run-in your terminal that, like, sets says use the marimo pair skill and, like, you know, toast a notification and, like, here's where the notebook is running kind of thing. And that that is kind of the nicest experience I found to to being able to launch it. It's just like you spin up marimo, then you click that, and you can sort of be confident you're connected and keep going. But does that like, how does that get the how does that get the skill and the Bash script onto your computer? Is that just like a curl command and then you SH it? It's a subcommand in the marimo CLI that, like, basically is like a prompt that says, like, check to see if the like, we check to see if you have the skill installed. If you don't, then we'll, like, prompt Claude to, like, go get the skill and, like, have you install it. But if you ever if you look at the marimo pair skill, it also is, like, very uncoupled to, like, the code mode internals. Like, it basically tries to orient the agent around, like, the things that Michael was talking about. Like, you know, if a user's trying to do something with marimo, like, what's a what's a nice path forward and, like, trying to help them, like, spin up marimo? And then the second piece is basically telling it, you have one tool, and then there's this thing that's called code mode. And, like, when you start a session, go look and see what how what code mode is in that instance of marimo that you have. And so because we can ship changes to code mode, baking in, like, those API invocations in the skill itself would kind of lead to this versioning problem. And instead, what we've been able to do is, like, version the two independently where we just say, here's the skill, and then we can ship upgrades to marimo, and we don't have to worry about the two drifting from one another. It is fascinating to me how agents gonna change the API ergonomics. You know, like what one thing I think it's kind of interesting and surprising is, like, I would say on average, like, agents are way better at reading error messages and actioning them than than humans. So, like, good error messages have always been important, but they're almost more important now because because you can assume that an agent will actually read it comprehensively and if you have a good suggestion it will follow it, and then that can make APIs way more discoverable on the fly. Because as long as the agent gets somewhere in the vicinity, it then gets, like, pointed to the to the right place. Yeah. I'd say we've even thought now about, you know, as like, when you're in a code mode execution, having ways of streaming, like, agent only logs or, like, suggestions. So, like, a code path that goes down that like, hey. You're probably, like, trying to do this thing that doesn't really work or, like, this is a better option. Like, that's something we could like, from marimo say, actually use this API and, like, that like, the agents do follow that really well. Because you can sort of do this, like, in context learning almost of yeah. Actually, do this instead. And as you were saying, they they follow it quite well. Because the the other interesting technique is to just implement the API that the LLM hallucinates, which I think is also, like, a fascinating experience the Like, the early development of code mode was was I had sort of this idea of what I wanted that API to be, and then we ended up introducing a skill. Or I wrote a second skill that I called retro pair. That would be if something was, like, really annoying or the agent stumbled a bunch, like, that skill basically looked at the logs and tried to, like, diagnose, like, some stuff that was, like, kind of annoying or, like, things that were hallucinated. And then we would have this, like, internal Slack where we just share around, like, hey. This happened. Hey. This happened. And then that was a nice starting point to refining the API for our team, prior to us having, like, better evals of, like, how code code vote is being used. Yeah. I I love it. I don't know. It's it's so silly. Like, I I think a lot of people won't understand this, but I'm obsessed with code mode. So I I really appreciate you. I I just feel like the design, there's something so reasonable and nice and composable. It's it's such a, like, small set of choices, I feel like, but it's really cool to see how they add up and basically, like, thread the needle between, like, what agents do well and and what people do well. Yeah. In fear of getting maybe, like, a little too technical on it, but it might be interesting to this audience. Part of the way that we implement code mode is within a async context manager inside of Python. So that's like if you ever use, like, with, you know, the the with context manager with some invocation of code as this other you know, you get back this value variable that then you can call with inside that block. And what we actually do is that as the agent's working, we don't actually perform any of those operations within the code mode block itself. They just are kind of, like, queued as a thing that the agent would like to do. And then when it exits code mode, we kind of see if we can redo like, simplify that invocation of code and replay it in such a way. Or we can do things like we can check the code that the agent's gonna run prior to actually running it so that we can have high confidence that each transaction is, like, okay prior to, like, actually playing it back in the UI. And so in terms of what Hadley was talking about of giving this in context feedback, you know, if the agent tries to do some sequence of API calls that were like, woah. You you shouldn't do that. We can actually just give it feedback that says you need to reverse or, like, change something about the API call. So we have this, like, little, like, level of indirection that allows us to inspect the thing that the agent's trying to do and, like, view it as a a holistic chunk and then try to give some sort of verifiable checks that tell the agent, like, oh, no. Don't do that or do this. You're like a SQL query planner, but for notebook updates, basically. Much more simple. Yeah. So you said a lot about code mode and how, like, humans and agents can work together or even agents can work really effectively with marimo notebooks. I'm really curious about the from the other side. Like, I saw that you all, for a conference, wrote Beyond the Shell. Like, this pitch for essentially, like, why should an agent go beyond the shell? Like, a lot of us are using Claude Code on the command line, and a question might be from the other side, like, why should Claude Code choose marimo to do data analysis rather than running, like, bash commands or Python scripts. Could you say a little bit about that? Like, what what do agents get out of marimo, would you say? Yeah. That's a very fair and, like, good question. So and something we've been thinking about a lot, working on notebooks. Right? Like, almost putting the this existential question of, like, should we work on notebooks? And I think similar to how, you know, we've got got like, humans have reached for tools. Like, clearly, notebooks or some sort of, like, live programming environment has been useful for humans to work on data problems. And I think we're we're sort of continuing the pursuit that if we get the right ergonomics, these can also be useful tools for agents to work on problems. And part of that just comes from this, like, ability to iterate on the problem. Right? Like, being able to a lot of, like, data tasks involve this, I think, greater interplay at times between, like, you know, the code you write and the inspection of the outputs and then deciding what to do next. Like, it can be a little bit more hands on in the type of work that you're doing. And giving the agent the ability to the environment that it's doing that work in, bring in the human with, like, a very rich canvas. Right? Like like you you marimo or Notebook itself has the ability to embed these interactive outputs or just even just plot, like static plots, right, where different steps of that pipeline, the agent could say, like, hey. Take a look at, like, the data frame here, or I wanna pause here and, like, go before I go on to the next step. So for for one extent, I think it's a a really interesting substrate for human like, notebook itself is a really interesting substrate for the humans and agents to sort of, like, discuss together. And the other is, I think, is really this idea of, like, you're sort of pushing the model's thinking into in into, like, code and having this, like, artifact that comes out of that, like, session that you're working that resembles, like, what happened in that discussion. So, yeah, I was talking to the colleague about this recently, but, you know, if you let's say I have like a a problem at work and I'm working with some data and, you know, it's I have like an an instance of this problem where I open up my chat and I, like, start working on my I don't have any extra tools. It's just the file system and maybe some Python and stuff. I might solve that instance of that problem with, like, a directory of some scripts and some outputs and a set of logs that describe, like, what that conversation was. But the next instance of that problem, the starting point is maybe, like, I point at that folder or I point at, like, in that conversation history from before. And by, like, sort of forcing some standardization of, like, what that reasoning was and that artifact that, like, came out of that session into something like a notebook, I think that can be a really powerful way to, like, bootstrap, like, solving instances of those problems in the future such that maybe you actually you know, the next time you work on that type of data task, you start in a notebook, and maybe you you work really ****** a notebook that solves, like, a general version of that problem such that in the future, if you're picking up sessions and it's just editing a couple cells to, like, get back to, like, a very, like, similar type of output. So it I think by having this, you know, like, artifact from, like, these interactive sessions with talking about data that do have the properties of code because it is code. Like, that is a really interesting property of, like, yeah, doing data work that is, like, more reusable or sort of, like, a better starting point for some future work as well. I'm still trying to wrap my mind around Claude Code just picking up marimo on its own. Like, what do you well, do you think there's a world where something like Claude Code, even if the human didn't get involved, like, that that something like Cloud Code would benefit from marimo? Like and let's say I never read the output. Do you think that there's a world where it would benefit from marimo in that workflow? Yeah. Well, so one thing is that these models, they've also been fine tuned on, like, coding tasks on, like, the the using the file system. So they are really good at, like, grepping around and, like, looking for things. But, like, that can kind of pollute context or, like, you can kind of, like, get context built very quickly if it needs to, like, scrub around to find, like, different values and things. So I have some hunch that, you know, I there's been some work previously in, like, using Python REPLs with agents, but, like, you almost allow for the agent to put context in variables or in memory that then they can, like, choose to query back with code such that, you know, instead of having to look at all the values of my data frame or skim through a CSV, maybe, like, I'll just load that as a thing in memory that then I can query multiple times more efficiently and get back, like, specific context. So and then I think, again, like, if it's sort of like, what is the output of that work? Maybe if it's just for, like, working on a data task where it's like one off type of thing, just letting Claude Code rip, like, with Python and, like, the file system, I think, is gonna be totally fine. But, you know, if you know, we we do have users using marimo pair that, like, are lot like, deploying a lot of, like, headless versions of marimo, and that those all produce different marimo notebooks. And then because it is that artifact, you can, like, spin up marimo later and, like, look at what the agent produced and compare them. Or, like, you have this this sort of substrate that then is more portable or I can you know, I don't have to necessarily give someone my chat history and, like, a bunch of files and, like, a PDF. I could, like, just give them the notebook that, like, the agent produced and and pick up from there. I I added some another question related to very closely related, like, a different interpretation of Michael's question. And and that is, like, do you think at all about, like, how in the future, like, do you worry people are just gonna pop up in Claude and be, like, analyze this dataset? And in that scenario, like, how, like, how do people, learn about marimo? Like, do you start like, know, you keep like, previously, you go to conferences, we'd, post on social media, like, that's how humans learn about these tools. Like, do we need to start thinking about, like, how do we tell Claude about our tools so it uses them unprompted? Yeah. I think I've been thinking about that a lot. And I think also, like, marimo itself is a very, like, code first, like, user interface for, like, working with data. But, you know, in a happy future place, I would love it if somebody is popping up in, like, Claude Desktop or, you know, Codex Desktop. And, like, they're asking questions with data, and behind the scenes, it's like using something like marimo to, like, build up some sort of, like, understanding with that data such that, again, like, that user is a much different user from someone like me that had like, knows how to write some code. But, like, we're all sort of collaborating on a very similar, like, artifact. Because I do know folks, like like, have friends that are us technical users, but have gotten interested or feel very empowered in using, like, coding agents and coding tools. And some of them will take, like, a PDF or something and, like, ask to you know, have some hunch about that data and wanna ask a data question. And then maybe it comes out with, like, a table, a markdown table in that chat that says, like, here's, like, some answer. Right? And if you are presenting that to someone, the the thing that you want to be able to answer is that follow-up question of, like, how did you get to that number or where did that number come from? And I don't think a very, like or I'm I'm nervous about there being some world that we get into where it's like, well, here was my chat history that got me there, or, like, here is, like, the set of scripts that ran. And rather than, like, here's the code that made that cell or, you know, it something like marimo, you could actually if if you ask a question of, you know, where did that label for that axis come from? If you started that whole process in a marimo notebook, you could actually trace that graph all the way back to the beginning of, like, where that value changed and, like, change that value there. So I think having these artifacts that preserve that sort of, like, providence of that conversation, but in code, whether or not you're looking at that code first or maybe you're somebody that's more a data practitioner that yeah. That that is it, like, not a code like, is it writing code in their day to day? But then the the real quest existential question that you're asking, Hadley, is, like, how do you get these these tools into those environments? And I don't know. Is that buy in from, like, the like, if it if it's something in enterprise where, like, they're just equipped with these, right, like like, sort of coding tools out of the box. Yeah. And then how do you make sure, like, all of the, like, monetary benefits that don't accrue to, like, Anthropic and ChatGPT and, like, all of this open source support. All this open source work just goes unsupported. Yeah. Like, the yeah, how do we kinda complete that loop, like, that feedback loop? It's an interesting one. Both both asking, yeah, what what will the tools use? And like, yeah, how how will, like, open source software kind of be preserved and supported? And also, I think, Joe, to your point, like, how yeah. Well, how will organizations decide? And we do kind of live in a world where someone could, like, vibe code a whole dashboard in a myriad of ways. Like, will there be benefits to building our dashboards in the same way, say, in marimo so you can kind of crack it open and and start from, like, a cell or go back and look at the code and kind of see how things were made? No. I'm I'm a huge marimo fan. I feel like this style of notebook agents really I I liked notebooks before, but I I was open to the more R way of doing it, which is very text driven. But I do feel like tools like Claude Code and agents have really kind of reignited my love of notebooks, and I think in no small part due to, like, marimo Code's interface. So, yeah, re really appreciate you coming on. I think it's so interesting to hear about the design. Like like, just the human part, you know, the design of the notebook, but also everything being done for this kind of, like, agent human collaboration. Yeah. Super interesting stuff. Really appreciate you coming on. Any last any last notes or things you want people to know? Try out marimo pair. Yeah. I don't know. I think It's just a skill away. Right? Yeah. It is just one skill away. I do think about the you know, for a certain audience, like, a skill is something that someone understands and can install. But, like, how do you, like, more broadly, as Hatley was saying, like, introduce the idea of that being, like, a way of shipping a piece of polished software as well? Yeah. I you know, when I started working at marimo and before that working at any working on anywidget, I think that my motivation around working on those tools was to try to eliminate this, like, distance between, like, people and their data. And I think that one thing I took for granted was that code writing code has also been like a a barrier at times of, like, getting to that decreasing that distance. And so it I'm, yeah, I'm personally very motivated to be in a place where my my colleague Vincent likes to say, like, we're not a a no code platform. We're like a yes code platform. And, like, you know, humans can write code. Agents can write code. And maybe this is like a really rich time to be playing around with, you know, the environment in which we get closer to data and help, make decisions with data. Yeah. That's awesome. You really appreciate you coming on. And, yeah, for everyone, definitely highly recommend marimo pair. And I I'll never say the old way again, marimo for life. So thanks. Cool. Thanks for having me on. Thanks, Trevor. The Test Set is a production of Posit PBC, an open source and enterprise tooling data science software company. This episode was produced in collaboration with creative studio, Adjy. For more episodes, visit The Test Set dot co or find us on your favorite podcast platform.