Skip to content
Melo Podcasts Home
CategoriesLanguagesFollowing

Episode notes

Coding agents have gotten really good at one kind of work. You scope a feature, edit some files, run the tests, ship it. It all happens on disk. But that is not how data work feels. You load something, you look at it, you run a cell, you watch how it responds, and you decide the next move from whatever is sitting in memory. And until now, your agent couldn't see any of that. It only saw the files. Never the live state. This episode, that wall comes down. marimo pair drops a coding agent right inside a running notebook, with full access to every variable Python is holding in memory. The…

Transcript

Read the transcript · about 12,570 words, follows along as you listen

Michael Kennedy:Coding agents have gotten really good at one kind of work. You scope a feature, edit some files, run the test, ship it. It all happens on disk. But that is not how data work feels. You load something, you look at it, you run a cell, you watch how it responds, you decide the next move from whatever is sitting in memory. And until now, your agent couldn't see any of that. They only saw files, never the live state. On this episode, that wall comes down.

Michael Kennedy:Marimo pair drops a coding agent right inside a running notebook with full access to every variable Python is holding in memory. The notebook becomes a shared canvas. You point, it runs the code. You tell it to zoom in on a graphic and the chart just updates. No MCP tools to wire up, no schema to describe, just Python and an agent that can finally see what you see. Trevor Manz from Marimo is back to walk us through it. This is Talk Python To Me, episode 555, recorded June 30th, 2026.

Michael Kennedy:Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists. This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years. Let's connect on social media. You'll find me and Talk Python on Mastodon, BlueSky, and X. The social links are all in your show notes. You can find over 10 years of past episodes at talkpython.fm. And if you want to be part of the show, you can join our recording live streams.

Michael Kennedy:That's right. We live stream the raw uncut version of each episode on YouTube. Just visit talkpython.fm/youtube to see the schedule of upcoming events. Be sure to subscribe there and press the bell so you'll get notified anytime we're recording. This episode is brought to you by Sentry. You know Sentry for the error monitoring, but they now have logs too. And with Sentry, your logs become way more usable, interleaving into your error reports to enhance debugging and understanding.

Michael Kennedy:Get started today at talkpython.fm/sentry. Trevor, welcome back to Talk Python. Great to have you back. Yeah, thanks for having me again. We'll probably talk about notebooks, data science, maybe a little bit of AI in the mix.

Trevor Manz:Yeah, definitely. We've been doing a lot at Marimo and thinking about how agents can play nice with notebooks.

Michael Kennedy: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. Now, before we get into that, it's been a year since you've been on the show to talk about AnyWidget. Just give us a quick introduction for folks who maybe didn't listen to that episode.

Trevor Manz:Yeah, AnyWidget is both a specification and a toolkit for making interactive UI elements that deeply integrate into your interactive programming environments, and specifically Python environments. It has deep integration into Marimo, which is the company that I work at now, where we build a new kind of reactive Python notebook.

Michael Kennedy:I'm a fan of Marimo. I don't do that much stuff in notebooks, but if I did, I would be using Marimo most of the time. It's kind of like that Dos Equis. Yeah, yeah.

Trevor Manz:I like to, depending on the ilk of user that we have, I like to make the joke that there are often a certain group of folks that have plenty of notebook friends but don't really use notebooks themselves. And I'd like to at least pitch why I think Marimo scratches the itch of many more software developers and represents more traditional software than traditional computational notebooks.

Michael Kennedy:I think it also kind of is special for people We were more on the software development side because it's a little more Python focused instead of special tool focused in that. We'll talk about Marimo in a second. But like, for example, instead of having IPY and B files, it has just Python files.

Trevor Manz:Yeah, we are hyper focused on Python. 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. It's all oriented around the Python ecosystem.

Michael Kennedy:Yeah, that's probably going to pay off a little bit when we talk about this project here.

Trevor Manz:Yeah, definitely. Definitely.

Michael Kennedy:All right, well, actually, let's do a quick refresher on just what Marimo is. Am I saying that right? Marimo? Sorry, I should be saying Marimo, right?

Trevor Manz:Yep, it's Marimo. Yep.

Michael Kennedy:Okay. Give us a quick refresher for people who don't know. You know, it's sort of in the realm of JupyterLab, but also different.

Trevor Manz:Yeah. Marimo is spiritually a computational notebook, much similar to something like Jupyter or Google Colab, if folks have used that before. But as we just mentioned earlier in the show, we're hyper-focused on the Python ecosystem. And we are also a special kind of notebook in that we are a reactive Python notebook. So what that means is that the order in which Marimo understands your notebook is not in the order that you wrote the cells, but the actual data flow between the cells.

Trevor Manz:And so we understand the relationships between your cells based off of the variables they declare and where those variables are used. 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. 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.

Michael Kennedy:It sounds like a minor feature, this reactive bit, but it's not so minor. 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. and maybe go back three cells, edit something, rerun that cell, go down back to where they were and continue. Like, why is this? It doesn't seem to do anything. Or this is not what I expected or whatever.

Michael Kennedy:And then you realize, oh, because I didn't run the two cells or the one cell in the middle that actually used that value, which then flowed on to the next, right? And basically what you're saying with this Reactive Notebooks is unless you overwrite it or something, that can't happen with Marimo.

Trevor Manz:Yeah, it's essentially when you're working something like a Jupyter notebook, you, the user, have to do a form of bookkeeping to make sure that whatever state exists in the kernel is representative of whatever cells you have on the screen. And discipline doesn't really scale necessarily, or it becomes hard to do that bookkeeping yourself.

Michael Kennedy:Come on, I don't buy it because look, when you go into Jupyter, it says like 27, 34, 57, 58, and then 90. And if you see one of those, if you're not doing your bubble sorting, that's out of order. You know you've got to go back and run it. I mean, we all keep track of this.

Trevor Manz:Yeah, but essentially the moment that you get to some sort of complex notebook and state, that becomes a lot of cognitive overhead that you as the user sort of have to keep in mind in order to ensure that what you're doing is representative, such that when you hand off your notebook to someone else, they're able to confidently reproduce that execution that you had in front of you and get

Michael Kennedy:back to that state. And so with Maremo, we offload that. It's just about that, right? Like that's obviously a problem.

Trevor Manz:Yeah. And so at Marimo, you essentially offload that bookkeeping to a system, which we do this dependency tracking of your variables and where they're declared and where they're used. And essentially we can provide guarantees that if you try to do something like rerun a cell, we will rerun all descendant cells of that cell. Or if you try to redeclare a variable, we'll tell you, hey, you already declared this variable and eliminate this problem of hidden state.

Trevor Manz:such that when you do end up working on a team with more than one individual and you want to hand off that artifact to someone, they can confidently run the notebook and reproduce the execution results that you were looking at when you ran that notebook earlier.

Michael Kennedy:Yeah, it pretty much guarantees ordering. Yep. Okay. Also, it's got a really nice modern UI feel, I think. It looks good. It feels fresh. And I don't know, for some people, maybe that doesn't matter. But to me, I'm working on stuff. I just feel better if it's a nice UI and it looks polished instead of old school.

Trevor Manz:Yeah, and because we are hyper-focused on the Python ecosystem, we've been able to think about common data structures and objects that are in the Python ecosystem and then really have polished user experiences for inspecting and understanding those objects. So inside of a Marimo notebook, if you load a data frame, whether that's a Polars data frame or a Pandas data frame or an IBIS table or anything that implements this data frame protocol, which is a standard in the Python ecosystem, we can represent and render in a really nice interactive table.

Trevor Manz:And so we're able to do that because we're tailored around this Python ecosystem and we're able to polish both the user experience on the front end side as well as all the way down to the kernel in terms of being able to share these reproducible notebook documents.

Michael Kennedy:Okay, yeah, I love it. All right, so that's Marimo. And what we're talking about today is not exactly Marimo, but more AI plus notebooks in a particular tool, agent skill. I don't know. We're going to get into that, what it is. But before we do, let's just talk about how do people, like what do people do with, say, either Marima or Jupyter or JupyterLab today without a tool like Marima pair?

Trevor Manz:Yeah, I'd say that the software as I've known it over the past year has changed quite a bit for traditional software development. And as we started working more and more on Marimo, we were using agents to perform more of our traditional software development. And many of our users were asking, what's the best way to use Marimo with agents? Because they've been using Marimo. And I think that many different, if you'd ever tried out of the box to use one of these coding agents with notebooks, whether it be Marimo or JupyterLab or Jupyter or Google Colab, there kind of felt like this difference or like awkwardness in that user experience in terms of being able to drive that interactive environment in a way that I think was very sort of unsettling or unfulfilling compared to traditional software development because you're able to sort of like put off your agent on these long-lived software tasks and then come back and have it run the test and let it get in these type loops to be able to autocorrect and do this sort of like traditional programming and software development.

Trevor Manz:But when you tried to apply it to a data problem, things would happen where you edit the file and then you could get to some inconsistent state inside the notebook, or the agent couldn't actually see the actions that it performed inside that notebook. And it wasn't really able to get inside those tight loops. And so we really started thinking from the bottom up, how can we open up Marimo in such a way that it's actually useful to an agent rather than just this data source that it can query and really try to extend that agent's working environment with notebooks the same way that, you know, humans have used notebooks for working on data tasks.

Michael Kennedy:I think notebooks are particularly tricky for AI to work with because many people know, but probably not everyone. When you look at a Jupyter notebook, the IPY in B file, you've got your cell definition with code or markdown or whatever's in there. But also, and this is the part that makes it tricky part of the part, is that all the output. 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?

Michael Kennedy:And so as a Claude Code or a codex or whatever that's going to go through and try to understand it, it's got to skim through all of that output, determine most of it is irrelevant to me. Some of it is relevant. Maybe it was run in the wrong order. So if it does try to look at the output, it's actually, right, there's no enforcement of an order. And so if it's run in the wrong order, the output might be present and they might want to use it, but it's actually wrong because it was run, it's stale from what's actually in there.

Michael Kennedy:There's a lot of issues, right, to just work directly on the file format.

Trevor Manz:Yeah, I think, you know, as we started thinking about this problem, I think that we, you know, even ourselves at Marimo started to realize that for notebooks, these file formats are more the artifact of the work rather than the source necessarily of the code. And really, it's the editor combined with the state, which is how you are authoring these notebooks in this live, interactive environment. And that by just allowing agents to use their tools out of the box and edit those artifacts on disk, they're missing a lot of the context in which those files are actually authored. And they're also, in what you just mentioned, they are polluted with additional context that's not necessarily useful to like performing a coding task on behalf of the user.

Michael Kennedy:Yeah, it's like, hey, Claude, work on this. And by the way, here's 10,000 lines of stuff that may either help you or harm you depending on stuff you can't determine really.

Trevor Manz:Yeah, exactly. So I think we started to think about this as more, you know, humans, like, you know, out of the box, these coding agents are equipped with sort of like the ability to read and write files and run bash scripts. And those tools really fit like the tasks of traditional software development because that type of like the way that our command line tools and work that we do for traditional software development work or that the file system is really the source of truth and then you like make changes to those files and then you run sort of these like stateless commands that like run your tests or basically take those changes and apply them and see if like what effect that those have had and humans you know for data tasks have have sort of gone beyond the tools of reading and writing and editing files and running batch scripts and instead we use these really like interactive repls or sort of live programming environments for working with data because they give us this ability to like iterate on intermediate results and values. So it's not like you run a script, maybe you made an error, you have to run that script again from scratch. Instead, we can

Trevor Manz:like load a data set into memory and then sort of inspect those values and sort of iterate on them in memory. And so like the usefulness of those sort of interactive environments like Excel or Jupyter or Marimo or even something like RStudio is that they're stateful. And one problem is that these agents weren't really good at accessing those stateful environments. And so that's exactly what made it hard for us to open up those environments to agents. And I think there are many different approaches that folks have taken. And even we took originally to try to make Marimo a useful tool.

Trevor Manz:And it took us a little while to figure out what were the ergonomics that work well for agents.

Michael Kennedy:Sure. So what you're saying is basically, instead of running on the file system, like the coding agents do now for, say, my code, I guess, what instead they need is they need to run in the kernel, kind of looking at the state of things in the kernel as it's working more than, say, regular programming code.

Trevor Manz:Exactly. Yeah. Because, you know, when we, as humans have adopted these tools, the reason we adopt them is because it's not just the code, it's the values and the in-memory representations of those data So it's not just that I have this data frame on disk or this file on disk that has my data, it's that I want to look at the table and I want to see what those values are. And that may determine the next step that I'm going to take with that data of what plots I'm going to do or what validations I'm going to run on these data. And so really we had to sort of invert that thinking and think more about how do we extend these agents with a useful tool, which is a notebook for doing this sort of data work and iterating on those intermediate values.

Michael Kennedy:This portion of Talk Python To Me is brought to you by Sentry. You know Sentry for their great error monitoring, but let's talk about logs. Logs are messy. Trying to grep through them and line them up with traces and dashboards just to understand one issue isn't easy. Did you know that Sentry has logs too? And your logs just became way more usable. Sentry's logs are trace connected and structured, so you can follow the request flow and filter by what matters. And because Sentry surfaces the context right where you're debugging, the trace, relevant logs, the error, and even the session replay all land in one timeline. No timestamp matching, no tool hopping. From front end to mobile to back end, whatever you're debugging, Sentry gives you the context you need so you can fix the problem and move on. More than 4.5 million developers use Sentry, including teams at Anthropic and Disney+. Get started with Sentry logs and error monitoring today at talkpython.fm/sentry. Be sure to use our code talkpython26.

Michael Kennedy:The link is in your podcast player show notes. Thank you to Sentry for supporting the show. Maybe good time to introduce Marimo pair. What is this? Yeah, so Marimo pair is an agent skill

Trevor Manz:that drops an agent inside of an active Marimo kernel. And it allows basically it's a single tool that allows the agent to run Python code inside of that kernel to inspect and perform any sort of understanding what sort of intermediate values you have inside of your kernel environment, but then also drive the authorship of the notebook itself and run and execute cells. So basically it allows the agent to do anything you could do in a Marimo notebook and extend your analysis with an agent by giving the agent the ability to drive the exploration of a Marimo notebook.

Michael Kennedy:Interesting. Okay, so how does it get inside the notebook? You know what I mean? Do you have to change your code or something like that? Do you have to include something?

Trevor Manz:Yeah, so the setup is essentially an agent skill that you can install either from, if you're using something like Claude Code, you can install it from the Cloud Marketplace. You can install from Codex from a Marketplace as well. Or you can use an NPX command to install a skill from GitHub. And that skill teaches the agent how to use a single tool, which is essentially just run Python. And that single tool call allows the agent to run any kind of Python it wants to in the running Marimo kernel.

Trevor Manz:So inside that kernel environment, it can do things like list variables that are in the notebook. It can inspect the cells of the notebook and look at the outputs of the notebook. 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. 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.

Trevor Manz:and is able to get back into these agentic loops for doing these tasks. But using Marimo as sort of the workspace for performing your data tasks rather than editing the file system.

Michael Kennedy:Yeah, okay, that makes sense. And I guess there's some kind of API or something that the agent can use to talk to the running notebook.

Trevor Manz:Yeah, so we sort of hide an API within Marimo that's called code mode. And what code mode is essentially is this semi-private API that's just meant for agents that are running Python inside of that kernel. And with that API, the agent can grab the current notebook state and talk to Marimo directly. So it can do things like toast notifications in the UI that say, hey, I'm connected to your notebook session. It can do things like I mentioned before, like list out variables or inspect what cells declare different variables.

Trevor Manz:But then also it has these sort of mutation APIs where I want to say create cell, edit cell, run cell. And because it's all Python and not individual something like MCP tools, the agent has the ability to write Python code that really does complex composition of those primitives as well. So it can create multiple cells at the same time just by calling create cell five times inside of some sort of loop. Because we're giving it Python as the tool rather than sort of a JSON API.

Michael Kennedy:I'll say, for me, it kind of boggles the mind how much Claude Code just relies on grep to understand projects. And it seems super inefficient to me. I mean, Claude Code was created in two weeks, something like that. It feels very much JavaScript-y in that regard. Like, look what you built. Also, look at the missing pieces a little bit. And as impressive as it is, it seems like if it could ask the question, where is this symbol used throughout my project?

Michael Kennedy:What is the value of this variable? Things like that. What is the type of it? Without reading and jumping around 100,000, a million lines of code all the time, it would be way more efficient. And it sounds a little bit like that's how it interacts with your notebook through Marimo Pair.

Trevor Manz:Yeah. So within that code execution point where it can run Python code, the agent has the ability to look at the source of those cells, but then also can look at the in-memory values of those cells as well. And therefore, it can, like you were just saying, it can look at the type, it can look at the values. and this type of runtime inspection of values really does change model behavior in terms of, like I mentioned before, allowing them to get into these loops and efficiently get to some sort of problem, resolution to some task or problem inside the notebook because it's able to course correct and ask a lot richer information about your values.

Trevor Manz:Because if you're looking at a source code on disk, maybe for a file that loads a data frame, you just have a single line that says, you know, load, Polars read CSV or pandas read CSV. And then the agent would actually have to go look at that CSV to understand what's in that CSV and combining that with the source code. But if you pair that with a live REPL like we have inside of Marimo, the agent could just say, you know, the agent now has a data frame that it can look at.

Trevor Manz:And that's a much richer representation of that static file on disk. And then the agent can ask about the schema. It could ask about, yeah, the different columns, the data types of the columns. It could figure out the number of rows. 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.

Trevor Manz: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.

Michael Kennedy:What's the token economics of this? Is it more efficient on tokens because it doesn't have to search around so much? Or have you noticed a difference?

Trevor Manz:Yeah, that's a great question. I think from the skill itself is a pretty slim markdown file that just teaches the agent what this tool is and how to use this tool, which is run Python in the running kernel. And then the agent is able to, maybe before the agent would read the entire notebook file to figure out what you want to do. but instead off of disk because it had to orient itself where you are inside the notebook. Versus if I asked the agent, we're focusing on this cell right now inside the notebook.

Trevor Manz:The agent doesn't have to print off all the other cells into context. It can just focus on that one cell or that one variable that we're talking about in the kernel. So we haven't done anything formal to compare those things. But essentially when you're able to extend the environment with variables and values, then you give the agent the ability to offload context into Python rather than bringing that as extra context that fills up your context buffer.

Michael Kennedy:Yeah, my impression is that first estimate is it would be way more efficient, honestly. Like a lot of times I'll see Claude Code or something and go like, okay, I need to understand what this does. Let me write a little Python script and execute it with a dash C or what, you know, or I can just pass it as a string effectively. And it's recreating all these things instead of just like print X or just give me the value of X, right?

Trevor Manz:Yeah, exactly. And actually you can think of each invocation of the tool that we provide to the agent as essentially running Python-C, except picking up wherever you left off inside of your notebook. So it has the ability in that string that it passes to Python to just reference variables that you currently have in memory. And it doesn't have to perform something high up in that script that might be costly to reload a data set or mangle it to get to some later state to print it out.

Trevor Manz:Instead, it can kind of pick up where you are currently in your notebook session, you know, and tell me about my data frame. And it can run a bunch of queries on the thing that you currently have in memory to tell you about it.

Michael Kennedy:Sure. Okay. Super interesting. And let's talk just really quickly about this distributing as a skill. I mean, there've been other attempts for notebooks that I've seen that are kind of like, we're going to embed an LLM or at least an LLM integration in the notebook. And it's interesting to see you shipping this as a skill plus a capability that's just in Maremo. So on one hand, it's easy to think, well, that doesn't seem very useful. But then again, there's always the what is now well-known SaaSpocalypse because Claude shipped 13 markdown files, which wiped $285 billion off of the stock market, right?

Michael Kennedy:So there's something to these markdown files. I really think it's quite powerful. but how'd you come around to this distribution model?

Trevor Manz:Yeah, so Marimo, and I should be clear, Marimo today still has a chat integration that you can bring your own LLM and actually drive an agent interface from there. And even you can actually use the Marimo pair tools inside of that chat interface as well. But increasingly we had users that were asking about, how do I use Claude Code with Marimo? Or how do I use Codex with Marimo? And what we started to realize is that These coding agents, we're building a tool that we'd like our users to spend a lot of time in.

Trevor Manz:But these coding agents outside of Marimo have a lot of access to things that aren't ever going to be inside of the Marimo user interface, such as the different skills or MCPs or things that they've enabled for their main driver of doing development on their machine. And we want to make sure that Marimo is a useful tool in that context as well. And so increasingly, many of the folks on our team are using Claude Code for the actual development of Marimo.

Trevor Manz:and we started to feel this friction of when we wanted to work on a notebook that we couldn't just start up the notebook and get it running from Claude and then edit it. Instead, it felt like we were jumping between tools. At least initially, we were thinking how do we make Maremo notebooks a useful tool for agents? Then we started to look at best practices for doing that. Simply a bare bones MCP was one approach that you could go with. When we started to look at skills was I think around the fall slash December last year when these models started to get quite good, the skills started to become a very useful vector I think for packaging up reusable instructions for how to effectively use a particular command line tool or skill.

Trevor Manz:And so if you actually look at our skill today, it doesn't really tell you much about how the internals of Maremo works or how that tool works. And instead it just teaches the agent about where that tool exists and how to use that tool. But then if it wants to learn about how to invoke that tool and the different capabilities that it has within that active kernel, it actually uses the help command. We instruct it to use the help command to print off the doc strings for itself and then learn in that session how to effectively drive Marimo.

Trevor Manz:And so this actually has a sort of decoupling between our skill and Marimo's internals because we don't actually publish anything in the skill that talks about the API that it will be using. And instead we'd say, hey, go find that when you load the skill to figure out what capabilities that you actually have inside the active kernel.

Michael Kennedy:That's interesting. That way, if you want to change it, you don't have to get people to update the skill, which is always tricky.

Trevor Manz:Exactly. This was the thing that we became very conscious of quite early is that updating Marimo and updating the skill could get out of sync. And we just wanted to make sure that our users didn't get into the state where they're having a really poor experience using their agents because they upgraded Marimo and they hadn't upgraded their skill. And so the skill isn't so prescriptive about exactly what the agent should do, just more, hey, these are tools. And this is sort of the mental model of how you could drive Marimo. And then should you want to drive Marimo, here's where you go find how to do that inside of the active Marimo that you have in your session. Michael, I can't, I might have lost.

Michael Kennedy:Sorry. So skills have been changing over time about how they're structured and they used to be commands and then i don't know just the layout of these things is a little bit a little bit funky um i mean i guess you could manage it from marimo like have it say like hey skill update available push this button to reinstall it or something but it sounds pretty bare bones in terms of like just go talk here and then you'll figure it out when you get there sounds sounds good yeah exactly and

Trevor Manz:you know some of these like agents have the ability like for instance in Claude Code and codex If you have this marketplace.json file where you have your skill, you can subscribe for auto-updates of that skill so you don't have to re-sync that file. Or if you use one of these command-line tools for installing from GitHub, you can install the latest. If our users got out of sync, it's quite hard to figure out what version they have, and maybe we'd need to do some runtime inspection.

Trevor Manz:So by really trying to have this decoupling of the skill from the capabilities that we have inside of Marimo, we can ensure that there's sort of a baseline of user experience. And then should folks want to upgrade to latest skill or upgrade Marimo, hopefully both those things should, should, should improve that experience over time.

Michael Kennedy:Yeah, for sure. This portion of Talk Python is brought to you by us. I want to give you a quick bit of news about the courses side of Talk Python. Now, every single course at Talk Python training has full subtitles in German, Spanish, and Portuguese. That's all 283 hours completely translated, not just a couple of flagship courses. Just click the CC button in your player, pick your language, and you can even resize and reposition the captions so they don't cover the code.

Michael Kennedy:If Deutsch, Espanol, or Portuguese is your first language, this one's for you. Check it out at talkpython.fm. Just click courses in the nav bar, log in, or create an account. Even the free courses now come with subtitles in four different languages. Let's walk through installing this and maybe a quick start story. So first, installing it, how do we do?

Trevor Manz:Yeah, so whether or not you have a tool called... So first of all, a skill is a folder of some files, and there's a file called skill.md. This is like an official specification that you put somewhere on your file system for your agent to find. And then there are a handful of tools that exist in open source adding those files. And like I mentioned just a moment ago, being able to sort of upgrade those files easily, either based off of Git syncing or by installing with one of these marketplaces. So the way that we publish our skills, we have this repo, it's called marimoteam, marimopair.

Trevor Manz:The code that we publish there, we version over time. And you can either use, if you have the npm package manager, you can use npxskillsadd marimoteam slash marimopair. That will start up the command line tool to add those files to your file system. You can either install them locally in a folder, globally on your system. If you don't have npm installed, you can actually use UV and do uvx Dino A npm skills. And this will sort of shell out to Dino to actually install those for

Michael Kennedy:you, but you can drive it through uv. If you have pod code. I've seen this so much. I'm like, oh man, why are we stuck on NPM? I do have these things. So I'll put the uvx Dino dash A NPM I feel like that could be a sweet new alias, just UVNPM. I think that'd be nice. I'm going to find a way to do that.

Trevor Manz:Yeah, definitely. Short tangent, I actually got the Dino name for the Dino folks so we could transfer over that package. Being able to share packages between ecosystems without having to reinstall a new package manager I think is really important because both the Python ecosystem and the npm ecosystem are growing so much. But it's a lot to ask of users to make sure that they have both these things installed, especially if someone considers themselves a node person versus a Python person.

Trevor Manz:Let's just make sure that everyone has access.

Michael Kennedy:It could be an offense to have to install npm. I'm not just kidding. So you're responsible for getting Dino as a PyPI package?

Trevor Manz:Yes, yeah. I've collaborated a little bit with the Dino folks over the years. I went through a very formal process with PyPy to request that name and then turn it over to them.

Michael Kennedy:Oh, that's super cool. So tell people real quick about Dino because they're like, well, what does that have to do with Node?

Trevor Manz:Yeah, so the creator of Dino was the same creator of Node. And sort of the basis of Dino was, at least from the perspective of the Dino creators, was to fix some of the things that had happened in the Node ecosystem. And so Dino is a similar type of server-side JavaScript runtime, but brings over a lot of functions a lot more similarly to the way that the browser has. So it has a lot more fine-grained permissions baked into when you're trying to do something like read the file system or read variables, you have to actually explicitly opt into those capabilities while you're executing the script to allow that runtime to access those things.

Michael Kennedy:Okay, yeah, very nice. Now, do you have a preference here if I npx it or uvx it, or is it better to do the marketplace type of thing?

Trevor Manz:Yeah, so this starts to come down to your agent of choice. So the npx skills is a command line tool that's published. Skills is a package that's on the npm registry that installs skills on your system and sort of has a little CLI walkthrough where you can pick multiple agents, like if you use Codex or use Claude Code or maybe OpenCode, where it will install them to universal directories for those things. So if you are someone that likes to play with a lot of different agent harnesses, I'd probably recommend using NPX or uvx Dino.

Trevor Manz:Those are semantically equivalent. They just eventually will trigger the same CLI. It's just the package manager that's doing it is different.

Michael Kennedy:Right, it's more npm versus plugin, exactly.

Trevor Manz:Yeah, and then the plugin is more, that's a specific install instruction to Claude Code. And also I believe that Codex has something quite similar. And there you can register what's called a marketplace for our Marimo team, such that when we publish updates, when you boot up Claude Code one day, maybe it'll ask you if you'd like to upgrade our plugin. So that will sort of keep it in sync. So if you are a Claude Code user, I think I'd generally recommend, and mostly a Claude Code user, I'd generally recommend installing from the marketplace versus if you're someone that's flipping around between a lot of tools, the MPX skills does a good job and you can MPX skills upgrade the Marimo pair skill as well.

Michael Kennedy:Okay, that sounds really good. I guess, yeah, the one is general, right? And the one, the other, the plugin one is really Claude Code. Although I suspect if you put it into Codex, it might just give you a little bit of snark and install it.

Trevor Manz:Yeah, yeah, definitely. I've accidentally invoked the skill with the four, I think in Codex, it's the dollar sign to invoke skills and it's Claude, it's like this forward slash and it figures it out.

Michael Kennedy:Yeah, yeah, exactly. You must be confused. This doesn't even make sense. What you meant to type was such and such. Yeah, okay. So is there like a getting started example or something like that on one of your pages I can sort of point at?

Trevor Manz:Yeah, so if you have the skill installed, the best thing you can do is just spin up a Marimo session. So you could even prompt, starting from your agent of choice, say, start a Marimo notebook using the Marimo pair skill. And then everything needed to actually start you pairing with Marimo is baked into that skill. So after you've run that uvx command, you should be able to spin up a notebook and then connect to it with your agent and just start talking about some data or talking about a notebook that you already have.

Michael Kennedy:I guess, what are some of the use cases or whatever that you might go through with this. How do you find it to be useful? What are you all doing with it?

Trevor Manz:Yeah, I'd say Marimo pair is increasingly the main way that our users that prefer to author code with agents are starting to create and share Marimo notebooks. And so I think there are a lot of different use cases, but the way I like to think of it is that it really ranges from a more hands-on versus hands-off approach to authoring notebooks. So a more hands-on approach would be the workflow that I just described where you spin up a notebook session, maybe you have a data set and you want to be hands-on looking at that data, making plots, more exploratory data analysis or more iterative where you're hands-on working with the agent. But rather than writing the code, you're sort of prompting the code with the agent and looking at the outputs and deciding where to go next.

Trevor Manz:So that's more on the head, the interactive or hands-on approach. And then we also have a set of users that are driving Marimo, using Marimo pair and a more headless version as well, where they might spin off many different Marimo pair sessions to work on a similar problem. And at the end, they'll have these notebooks that are running that then they can connect to and sort of check and see what the agent was working on inside of that session. So essentially, when you want to start a task with data, you can open up your agent and spin up Marimo and then start prompting towards working on that problem.

Michael Kennedy:I see. So maybe this headless story, like I have this data and I know I want some kind of description, exploration summary of it. So, Hey, Claude, just create a notebook and just from scratch, just do what you want to do to build it up. And then I'll go look at it. Right. Yeah. And the other ones may be more like a coding, like a data coding sort of story. Yeah,

Trevor Manz:exactly. Yeah. And the, I think the nuance there of like why the more headless approach like works quite well with Mareem L'Apair is that if, if you've had any experience with trying to like one shot a program or one shot a notebook in the past, the agent doesn't really have a way of verifying what it's doing or that like that whole notebook that it created works well or maybe just at the end can like try to run the notebook and then we'll have to go back and fix cell by cell versus marimo pair driving from marimo pair sort of forces the agent to build up the notebooks a similar way that you would where you would actually go cell by cell so the first thing i have to do is like load my data the second thing i have to do is you know inspect look at my nulls and if there are errors in any of those steps the agent will correct them there rather than sort of generating the whole notebook and then running it from scratch. And so we found that you get much higher quality outputs when you are actually at the time of looking at the notebook, because the process in which the agent had to go to create the notebook sort of guarantees that it has to run

Trevor Manz:because it adheres to the Marimo's constraints versus just generating the artifact and then saying like, hey, I'm done and didn't really check the outputs at all. Right, exactly. It just could

Michael Kennedy:be some well-formed but meaningless notebook, right? Yeah. What if I'm now we're, we're pushing up to the limits of my Marimo knowledge. Cause I've not tried this, but what if I got a Marimo notebook and I say, open up that project and VS Code, like for example, maybe I have a regular programming project that's VS Code that has the Claude Code installed in it, like the extension or whatever. And inside there, part of it is a Marimo notebook. Can I say open up that notebook in Marimo, but then also have Marimo pair, but from within the VS Code, Claude Code, or do I have got to go to the terminal?

Michael Kennedy:What is this interoperability story?

Trevor Manz:Sure. At Marimo, I'm responsible for our VS Code extension, which is integrated. If you've ever tried to open up a Jupyter notebook inside of VS Code, VS Code or Cursor have a built-in UI for notebooks. We have a built-in UI for notebooks that reuses that sort of the VS Code native view, except replacing with Maremo outputs. And the latest thing I've been working on is getting the ability to have your agent inside of VS Code drive those notebook outputs as well.

Trevor Manz:So that's something we should ship in probably the next week or so.

Michael Kennedy:And there's, of course, I guess because of economics or lock-in or I don't know, whatever, there's always, in all these editors, yes, even in Cursor, There are like first class built-in ways to do agents. Say in VS Code, there's like the chat thing on the right. Those I think is probably what they intend you to do. But then you can get the VS Code Claude or Codex extension, which is a totally different UI, but still in VS Code. Or you could go to the terminal and you could type Claude or Codex.

Michael Kennedy:And that's a third sort of thing, which can sort of have links back in there. Do some of these work and some of them don't? Are they all the same? What's the story?

Trevor Manz:Yeah, so if you're launching from the terminal or the integrated VS Code, sorry, the Claude Code extension from VS Code today, that will likely start Marimo's command line tool and then open up a web view inside of VS Code, which is like our Marimo editor. If you use the chat, which is sort of the built-in agents panel inside of VS Code, that would drive the usage of the more integrated view inside of VS Code.

Michael Kennedy:But all three are possible, I guess, yeah?

Trevor Manz:Yeah, exactly. You can start a Marimo pair session from any of those panels. It's just a matter of what the visual that you're looking at is, if that's going to be the native VS Code editor for the notebook versus a web view of the Marimo notebook UI.

Michael Kennedy:Yeah, and my sort of huff at this before was like, This is only here because Claude Code won't allow you to use your subscription in the other one. It's got to be, you know, in certain circumstances, right? Like, oh, if you use the official extension, you can use your subscription. But if you use this other way, then you've like, say in Cursor, you use your Cursor credits, not your Claude Code subscription. And then PyCharm, you've got the sort of duality as well, where if you use the AI chat section that uses your JetBrains AI credits, whereas like if you use the terminal, it's clawed and just it's kind of a mess, honestly.

Trevor Manz:Yeah, I think there's a lot of fragmentation in the ability to, and who owns that interface for where you're typing into that box and driving these tools. And so from our perspective, we think there will likely be a continued amount of drift between these different tools. And we don't necessarily want Marimo to be a tool that people are kind of deciding whether or not they're going to use our chat bar. but we do think Marimo as an environment for working with your data should be accessible from whatever tool that you choose. And so on our side, we just want to make sure that you're able to connect to and drive a Marimo notebook from your agent harness and tool of choice.

Michael Kennedy:I think in maybe some kind of idealistic, non-realistic world where all the frontier foundation coding models, you could just tell it your subscription or tell it whatever, and it's the same billing everywhere, it might be better to have some kind of built-in panel into Marimo or little pop-ups or something. But given all the weird restrictions and stuff, it seems like a really good plan to just have Marimo good at talking to any agent through this way and however people want to run it, they can just talk to it, right?

Trevor Manz:Yeah. It's been challenging because we spend a lot of time on that UI and thinking about that UI that we own inside of Marimo how this should work with these agents. But the reality is that there's a lot of friction. And if we would have tried to build around Claude Max like a year ago, that would have been a lot of wasted effort because of the way that these platforms are changing. So as these tools become increasingly sticky and folks get entrenched into their agents of choice, I think from our perspective, making sure Marimo remains a useful tool to any agent is really our priority.

Trevor Manz:And if there is some sort of... yeah, future day where we can own that UI again, then I think we will certainly have a story there.

Michael Kennedy:Yeah, I think I totally agree with you, but I want to share a little graph with you from the Pragmatic Engineer newsletter. Yeah, I guess newsletter. So if you, there's this one that was AI tooling for software engineers in 2026. So you scroll down till we see a graph. There we go. If you look at what people are using, it's Claude Code. And then quite a ways back, we get Google Copilot, which I think is really, I don't know, maybe I live in some kind of sheltered world.

Michael Kennedy:But I feel like this is primarily used because companies have Microsoft 365 subscriptions and they've got 10,000 employees. And they're like, you can use Copilot because it's approved. I don't know that that's necessarily what people are seeking out as their top choice. I don't know, I could be wrong. Sorry if I got that wrong, Copilot folks. But, and then maybe about half is Cursor and that's kind of its own world and then it goes Codex. So like, I feel like if you're trying to, this is like Claude Code was way behind a year ago.

Michael Kennedy:It's crazy. So I feel like if you're building a tool, especially for developers that says, let's pretend you don't want this. Let us give you our version of something that's like it. I just don't think that that's a road for success. I think you're fighting against like, everyone's like, you know what, we're in Claude Code and it works really well. Why am I going to go put that away and use your thing? As opposed to what you guys built, which is like, well, here's how you use the top three of those things to talk to what you're already doing. I think that's a good

Trevor Manz:choice. Yeah, I think for us, it was the realization that the effectiveness of agents on a particular task is a combination of like, I think an agent is by definition is like a model, the tools that you equip that model with and then its environment or the loop that it runs in to perform that task. And so its effectiveness is going to be limited by whatever tools you give that agent. And so if we didn't make Marimo a useful tool for the agent, then if you give a data problem to the agents, it's going to use the tools that it has at hand, which are reading and writing files and running bash scripts. If you run that script a bunch of times or you ask the same data question using those tools, you might get a folder with a lot of different scripts and things and maybe a result. And so by giving agents, or really thinking of Marimo as a tool for agents, then we don't have to think so much about the interface for the agent, but rather just how to expose our environment to agents. And then when you ask for those data tasks, the thing that you generate at the end is this reproducible Python program that is a Marimo notebook, but you can

Trevor Manz:drive that for many of these UIs of choice. And I look at these bars here, there's going to be jumping back and forth between these, depending on what the providers dictate in terms of their

Michael Kennedy:Who gets blocked by the US government, who doesn't?

Trevor Manz:Exactly. For us at Marimo, as long as we can make sure that regardless of what agent you use, you will have notebooks as a useful tool. Then at the end of the day, you're still just generating Marimo notebooks. Even if you turn off your agent, you have this reproducible artifact that is useful for communicating your data results or something about what happened in that session while you're working with data. That's our goal at Marimo, to make sure that whether you knew how to write Python code or you don't know how to write Python code, you're able to produce this reproducible artifact for your data analysis.

Michael Kennedy:Okay. You also talked about open code AI. This is somewhat new to me. What is this open code thing?

Trevor Manz:Yeah, so open code is similar. I think Claude Code had the first form factor of being one of these terminal CLIs that you spin up. but just with the Anthropic models. And then OpenCode is a similar, like it feels very similar to using Claude Code, but it allows you to configure a lot of different models that have the ability to configure API endpoints. So for a while, I believe you can still configure all the different providers. It's just like the type of subscription models that you can use with OpenCode change quite a bit, similar to what you were just mentioning inside of VS Code.

Michael Kennedy:Yeah, for example, it looks like you can use your Codex subscription, but not your Claude subscription.

Trevor Manz:Yeah, exactly. So it should have a very similar form factor to when you type in Claude and you pop up that thing inside of your terminal. If you type in OpenCode, you'll get a window. You can start prompting. You can also install skills for OpenCode as well, the same way that you install for any of these harnesses. But we had some users that use OpenCode because of the open models. We have some users that are using Claude Code. We have some users that are using codex or VS Code.

Trevor Manz:And like I mentioned, we just want to make sure that anyone can drive a Marimo notebook.

Michael Kennedy:So it must be tough to be supporting AI stuff in this space, given how much flux it's under.

Trevor Manz:Yeah, I think by inverting the problem in so far is that we are no longer like, you know, by moving some of this ability to drive Marimo outside of the Marimo UI, we don't have to keep up as much with all the fluctuation in the new models. And instead, the thing that we can focus on is the skill and making sure that that interface for controlling Marimo is really good from any agent of choice. And then as these different UIs compete for sort of where the users are going to be in terms of driving their agents, again, we can just sort of sit there with Marimo and just make sure Marimo is a really good tool for any of these agents.

Michael Kennedy:Sure, sure, sure. So having this, how does this change how people use notebooks? I know how it's changed coding. It's changed it quite a bit in some ways and not at all in others. But how about for data?

Trevor Manz:That's a really good question. So I mentioned earlier that part of the value of these environments like a Marimo notebook or like a Jupyter or Excel is the statefulness of those environments. And so it's really like there's a lot of, you know, when you're using an agent, it's able to gather things and put it from your file system to bring that into context or from the web to be able to, when you ask a prompt, perform a task that hopefully fulfills that to some sufficient level.

Trevor Manz:And prior to having an integration like Marimo pair, that statefulness could be, basically the values that are in memory could be extra context to helping the agent answer some question, but you'd sort of have to babysit the model or tell it something like, oh, I copied this output, here's the output. And now when you say, what's in this data frame, it can look at those columns for you. Or for example, if I'm doing something like EDA type of analysis inside of Marimo, I can circle on a plot and make a selection.

Trevor Manz:And I can say, what did I just select here? And the agent can go take that indice selection that I made, compare it against the data frame, and come back to me with some answer. So I think these types of questions that maybe felt tedious to ask before, like, because you'd have to type out a lot of code to do that. Now you can really either use the agent to help you write code or actually ask you questions about the state inside that notebook. And you're really extending the agent's, you know, environment with the intermediate values that, you know, as a human might find interesting.

Trevor Manz:But now the agent can also use that as potential context.

Michael Kennedy:One of the things I think is super useful. A lot of times I feel like people maybe miss this and maybe, maybe more people than I realize know about it, but in VS Code or PyCharm or cursor, I think cursor might be best as I'm not entirely sure these days, but anyway, if I've got a file, maybe I've got hundreds of files in my project, but a particular file I'm interested in, if I have that file open and I ask questions, it's automatically included as context, just by virtue of having it be the last focused file.

Michael Kennedy:But even better is you can highlight parts of a line or three lines or whatever and go, what's wrong with this? It's all you got to say. And it goes, oh yeah, I see the function that you're talking about, the part that you've highlighted, like boom, off it goes. Is there some mechanism? It sounds a little bit like there is, but is there a mechanism in Marimo that it communicates back what's active, what you're working with?

Trevor Manz:Yeah, so we have, you know, as the agent is running things, we can communicate, you know, what cells have changed or like if there are values that have changed in the notebook and then the agent can go and ask questions about those things that have changed. We have some folks in our team that are working on creating these sort of, like I think to what you're mentioning, imagine you highlight a line of code and you want to feed that back as potential context of here's where I'm focusing.

Trevor Manz:Inside of a notebook, if you're using actually the integrated browser inside a VS Code or cursor, you can actually click on a plot and it'll take that screenshot and it'll add it as context to what you're going to ask. And so now you're having this interaction where it's not just the values but also the outputs and the visual outputs that you can say, hey, this is a little bit weird. I see this, this, and this. So we're definitely thinking that direction where, yeah, it's not just the line of code, but the value of the code and the representation of the code that could actually feed back to these multimodal models and help you sort of come to better understanding quickly with your data.

Michael Kennedy:Yeah, awesome. I love it. It's so nice because instead of trying to just like describe, okay, and the third function called this, there's a part where there's an if, you know, just like highlight and go this, right? It's great.

Trevor Manz:Exactly. There's a certain level of interactions or feeding back of... I think when I started to realize that these agents could be very powerful was when coding tasks started to feel a lot cheaper. Like maybe these what-if ideas of something I wanted to try with software, I could, rather than that taking up a whole weekend or several weeks to try out, it's like maybe an afternoon I could try that out. And I think the experience that we want to provide for our users inside of Marimo Notebooks is that these kind of what-if questions with your data also feel very cheap.

Trevor Manz:So you say, what is that? And now that like starts a conversation or starts a new part of your analysis that, you know, you maybe would have had to be very convinced to go down that route before. And now you can just like start to ask those questions and hopefully get to insight more quickly.

Michael Kennedy:I think another thing that that's really nice for is, you know, hat tip to the name here is like pair, like pair programming, right? If you were actually paired programming, you could just highlight something on the screen and go, what do you think about this? Right. Where's sort of the traditional, I don't know, Claude code just in the terminal. You've got to describe it a lot, talk about the file, right? Like you can't just have it sort of ambiently there.

Michael Kennedy:And if you're sitting there working with these tools, these agentic tools all day, especially if you're not doing a lot of programming with other people, like it's primarily the, you're sort of coding partner, you know, your paired programmer or whatever, the more you've kind of got to artificially step out and say, yeah, over on this file at dah, dah, dah, dah, try to find the file. And then you're talking about this, right? It breaks this flow and this idea of this thing is here to help me.

Michael Kennedy:It's like, I'm just sending stuff to this dumb machine that can't really figure out what's going on. So I really like it. This concept you're talking about.

Trevor Manz:I had this experience where I was actually trying to help my dad look at some data that he had in Excel. Notoriously, that's very annoying to load an Excel file in Python because you end up writing your own little parser to figure out the different subsets of the tables. At the end of the day, what I really wanted were a couple data frames plot inside of the notebook. And being able to just drag from my UI the Excel file over into Marimo pair and saying, hey, can you just load these three tables inside the notebook and let the agent chug away in the notebook at trying to figure out how to create those plots for me?

Trevor Manz:Maybe that would have taken me an hour to do on my hand from before. And it took a couple minutes for the agent or maybe even a minute for the agent. And then I got to focus on the exciting part was how to make these plots and communicate something with the data. So automating those pieces that are very bespoke and kind of annoying of like, how do you get data formats into the notebook is now something you can sort of, you know, task the agent on for a little bit. Right. I'm not a fan of

Michael Kennedy:vibe coding really, but I do think this provides really interesting onboard, like on ramps for people to get into notebooks and programming and so on. Cause maybe they can ask decent questions about data, but they can't necessarily go, okay, I'm going to get the pie X amount, the XML, XLS writer or whatever it is. Right. As you can tell, I don't remember exactly the name of it. So there you go. All right, that kind of thing. And just like load this up and then let's talk about it.

Michael Kennedy:Like I know what a data frame is, but I really need to know how to like select the third sheet in Excel. Yes, exactly.

Trevor Manz:Do I need to know that API to like get my tasks done with these data inside the notebook? And I think, you know, for in this context as well, because Marimo has this, you know, this deterministic execution order, you can sort of collaborate on building, you know, this like this reproducible like workflow of how you got to that notebook. So you can, instead of vibe coding the whole thing, you can maybe allow someone to kind of vibe code the first bit of how do we get the data into memory?

Trevor Manz:And then the things that really require attention about cleaning up the data and plotting the data and running some modeling on that data, now you've sort of freed up your time to focus on those bits as well.

Michael Kennedy:Yeah, 100%. It lets you focus on the parts that actually matter, not just silly file formats and stuff like that, right?

Trevor Manz:Yeah. And we're lucky because Python's such a Swiss army knife to all that has such a rich ecosystem of ingesting data and working with data that you can lean on that ecosystem plus the agent inside of the notebook to get your data into a format that is useful. But then that's the point that you step in and start to direct more about what direction you want to take that analysis.

Michael Kennedy:Totally. So a couple of final questions to wrap up our conversation here. Tips and tricks for people like, okay, you've got the skill, you've got Marimo. Are there interesting things you've all discovered you can do that maybe are non-obvious? Tips and tricks.

Trevor Manz:Honestly, my recommendation would be to, if there is some data set that you have in mind, like the example I mentioned with an Excel file, it's a very fun task to just drag in a data set and say, please load this for me inside the notebook and let's start making some plots or something. And I think very quickly you'll realize how quickly this runtime inspection really shapes this user experience where I think I went from being very hands-on with working in notebooks to being able to sit back a little bit more and think cell-by-cell about what I want to do.

Trevor Manz:So I just encourage folks to try it out with their data and let us know what they run into.

Michael Kennedy:Okay, yeah, that makes a lot of sense. One thing that I've done before, just playing around with data, is I've asked Claude, like, hey, here's the data, here's the scenario. What are some interesting questions we should be asking about it? here's what I think is interesting, but what am I missing? Are there trends in the data that I don't see that maybe you can pull out and just kind of have it just cruise around and just think about it a little bit?

Michael Kennedy:And it was really good.

Trevor Manz:Yeah, and I think you can imagine extending that. Typically when you're maybe asking those questions back and forth with Claude, it's giving you some tables and numbers and distributions in the data. But because when you're connected to a Marimo kernel, now you can ask for plots or different visual representations that might be able to show those trends. So if the agent is telling you that there is this difference, you could say, hey, make a bar chart or a box plot for me to understand that information.

Trevor Manz:Because you do just have this much richer canvas for talking about your data rather than just the ASCII output in your terminal.

Michael Kennedy:Right, the first thing that I got was a bunch of data frames and heads or stats or something like that. And I'm like, this is great, but describe this in pictures. And then I had a bunch of graphs. And I'm like, okay, that was cool. That was really cool. Maybe people could try that, right? Definitely. All right, roadmap. Where are things going?

Trevor Manz:Yeah, so as I mentioned, we are currently building a tighter integration with our native editor inside of VS Code. So essentially our direction with Marimo Pair is to try to think of all the places in which folks are trying to drive agents that maybe we could have the ability to spin up a Marimo notebook and allow folks to collaborate on these reproducible artifacts. So right now that looks a lot like more terminal oriented workflows. We have some integration now inside the Marimo editor itself, like I mentioned, where you can open up the chat and start using Marimo pair.

Trevor Manz:We'll have a further integration into VS Code. And I think down the line, we'll have eventually, you know, if you're using Cloud Desktop or Codex Desktop, that maybe you can start your little chat there. And that could also drive a Marimo notebook as well.

Michael Kennedy:I feel like that's an entirely missing piece of this whole agentic AI world, like the Google Docs CoLab equivalent, right? Like I've started up Claude Code or something like that. And now, why don't you join my session? We'll all talk to Claude and, you know, have it go. I don't know, maybe someday.

Trevor Manz:Yeah, or maybe Maremo can serve. Like, you know, we will have, we are currently working on some real-time collaboration features inside of Maremo. And maybe there's some way that, you know, multiple people have multiple agents that are talking to the same

Michael Kennedy:Maremo kernel. Each person with their agent buddy are all in there. That seems totally reasonable as long as it's, you know, aware. What about remote? So I'm running Marimo, I'm not on my machine, but on some server or some cloud service or whatever, but I've got my cloud local and I want to have those things work together.

Trevor Manz:Yeah, so the way that behind the scenes, like how the tool call works inside of Marimo, it's a bash script that's called execute code. That allows you to swap in a URL, whether that's on local host or something remotely with some authentication. And therefore you can connect your local cloud to some remote Marimo kernel as well. And then you have a sandbox that's not running on your machine at all, but somewhere in the cloud. But you're driving that from your local machine.

Michael Kennedy:Some big machine with GPUs or whatever, that's a better place to run your code.

Trevor Manz:Yeah, exactly. At Marimo, we have a cloud-hosted version of Marimo Notebooks that's called Molab that we recently released on CoreWeave Infrastructure, where we have some GPUs for our community. And you can actually today go inside that UI and click pair with an agent, And you can copy a little cloud command and connect that to your Claude Code or your codex. And then you can start pair programming locally with that remote sandbox in the cloud.

Michael Kennedy:I love it. That's awesome. All right, final call to action. People are like, Marimo pair sounds cool. What do you tell them? How do they get started?

Trevor Manz:Yeah, so I'd recommend going to marimo.io slash pair, grabbing the skill and spinning up a notebook of your own and just trying to do tasks that you do with data. Traditionally, maybe in a notebook or maybe if things haven't been going well inside that notebook. We haven't put up the site yet.

Michael Kennedy:That's right, it's coming soon. I totally forgot you said that. By the time this episode comes out, that will be there.

Trevor Manz:If you're watching the live stream, maybe give it a few days. By the time this episode comes out, check out marimo.io. Or go to our GitHub for marimo pair, install the skill, and show us what you build with Marimo, regardless of if you're driving it with agents. But we'd love to hear if you start using out agents where the skill falls short and how we can really improve that user experience.

Michael Kennedy:Cool. Well, it seems like a really neat idea. I think you're going to have a lot of success with it. So thanks for coming on the show and sharing it with everyone.

Trevor Manz:Yeah, thanks so much for having me, Michael.

Michael Kennedy:Yeah, you bet. Bye. This has been another episode of Talk Python To Me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. This episode is brought to you by Sentry. You know Sentry for the air monitoring, but they now have logs too. And with Sentry, your logs become way more usable, interleaving into your error reports to enhance debugging and understanding. Get started today at talkpython.fm/sentry.

Michael Kennedy:If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTML, and even LLMs. Best of all, there's no subscription in sight. Browse the catalog at talkpython.fm. And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for? Just search for Python in your podcast player. We should be right at the top.

Michael Kennedy:If you enjoy that geeky rap song, you can download the full track. The link is actually in your podcast player show notes. This is your host, Michael Kennedy. Thank you so much for listening. I really appreciate it. I'll see you next time. Thank you.

Transcript supplied by the publisher with the episode.

Talk Python To Me

by Michael Kennedy · English · Tech & Science

Talk Python to Me is a weekly podcast hosted by developer and entrepreneur Michael Kennedy. We dive deep into the popular packages and software developers, data scientists, and incredible hobbyists doing amazing things with Python. If you're new to Python, you'll quickly learn the ins and outs…

More from Talk Python To Me

  1. E558 · 10 Aug 2026 · 1 hr 2 min

    #558: Hyper-Personal Software with Python

    Every company has one. The little internal tool that Jane built back in 2021, and then Jane left. Nobody understands it, nobody will touch it. There are two unwritten rules around it: don't change it, it's working. And if you break it, you bought it. That's dark-matter enterprise software. For every app you can actually see, there are ten of these sitting in the shadows, frozen. Michael Booth thinks that just changed. He read my article on hyper-personal software and ran with it, writing about hyper-team software: small teams inside big companies finally building the tools that were never…

  2. E557 · 2 Aug 2026 · 1 hr 8 min

    #557: Security of everything at PyCon 2026

    Security has always been the vegetables of software. Everyone agrees it matters, and somehow it never quite makes it onto the plate. At PyCon US this year, that changed. For the first time ever, security got its own dedicated, day-long track, one of just two at the whole conference, sitting right next to AI. And the room was packed to the back wall. On this episode, I'm joined by the three people at the center of it. Seth Larson, Security Developer in Residence at the Python Software Foundation and, very recently, a CPython core developer. Juanita Gomez, a PhD researcher at UC Santa Cruz in…

  3. E556 · 26 Jul 2026 · 1 hr 5 min

    #556: Updates on Django's Async Story

    For years, "Django and async" came with an asterisk. The docs themselves warned you off it. Scary performance notes, a story that felt half-finished. Well, that story just got rewritten, literally, and the person who rewrote it is here to tell you why the old framing was wrong. Carlton Gibson is a former Django Fellow, sat on the security team for eight years, and he's on the steering council. On this episode we get into the async topic doc rewrite, what actually remains versus what was just fear, the new Tasks framework in 6.0, DB-level cascades and fetch modes landing in 6.1, and why…

  4. E554 · 10 Jul 2026 · 1 hr 1 min

    #554: Trustworthy AI in Healthcare and Longevity

    You ask an AI a question and it answers with total confidence. Most of the time, a confidently wrong answer is just an annoyance. But what if the question is medical, and there's a real patient on the other end? In that world, a hallucination isn't a bug, it's a patient-safety event. Sumit Gundawar is a London-based software engineer who builds the clinical platform for a UK longevity and aesthetic-medicine clinic, and his whole argument is that in high-stakes AI, the model is the easy part. Earning trust is the real engineering. We dig into grounding, refusal logic, human-in-the-loop…

  5. E553 · 26 Jun 2026 · 55 min

    #553: All of our tools

    This episode is a fun crossover from our Python news and tips podcast, Python Bytes. We have had some big changes over there. Brian Okken has moved on and Calvin Hendryx-Parker has joined the show as the new co-host. To kick off this new era, we decided to do a longer and more personal episode called "All Our Tools". The idea is both of us talk about some of our most useful day-to-day developer and business owner tools that we think you all would find useful. It was so well received, that I'm bringing it to you all as a crossover episode. Enjoy and we hope you find something new and awesome…

  6. E552 · 17 Jun 2026 · 1 hr 5 min

    #552: Astral joins OpenAI

    OpenAI just acquired Astral, the company behind uv, Ruff, and ty. And if your first thought was "wait, is uv toast?", you are not alone. But here's the twist Charlie Marsh shared with me: he thinks they may ship more open source at OpenAI than they ever did at Astral. On this episode, we get into the acquisition, the mixed feelings, the future of your favorite Python tools, and what it's like to build right at the center of the AI universe.

  7. E565 · 2 Oct 2026 · 1 hr 28 min

    #565: Tachyon, Python 3.15's Built-in Sampling Profiler

    Do you know what's actually slow in your Python app? Or are you guessing? Until now, profiling Python meant a tracing profiler that made your code 2 to 3 times slower. Or a third-party tool that broke with every new release. Python 3.15 fixes that. It ships Tachyon, a sampling profiler built into the standard library. It attaches to live production apps with almost zero overhead. My guests are Pablo Galindo Salgado, CPython core developer and Steering Council member, and László Kiss Kollár from Bloomberg's Python infrastructure team. Their first prototype ran at two samples a second. Now it…

  8. E564 · 22 Sep 2026 · 1 hr 8 min

    #564: EVE Online Departs for Python 3

    Every ship in EVE Online eventually undocks and leaves the station. This time, it's the whole game. EVE has run on Python 2 since it launched in 2003, all 2.4 million lines of it, on a custom Stackless interpreter that stopped at 3.8 and was archived last year. Destination: Python 3.12. The route runs through 6,500 lines of division that decide who wins a fight, and 100 gigabytes of pickled Python objects that have to survive the jump intact. Kristinn Sigurbergsson was on this show ten years ago. He's back, with Jamie Bannister, who is flying the EVE Online migration right now, and Thomas…

  9. E563 · 16 Sep 2026 · 1 hr 11 min

    #563: Getting Started with Rust as Python Devs

    Lint the entire CPython code base from scratch. It takes 0.3 seconds. Three blinks of an eye. That is ruff, and it is written in Rust. So are Pydantic, Polars, uv, and Granian. Rust shows up in Python three ways: tools that happen to be Rust, libraries Python imports, and servers that run Python inside Rust. This is Rust for Python developers, not Rust experts. Christopher Trudeau is back on Talk Python to discuss Rust and his latest course Up and Running with Rust. The core rule is that only one thing can own a value at a time. Pass it around freely in Python and the garbage collector…

  10. E562 · 10 Sep 2026 · 1 hr 11 min

    #562: DuckLake: The Lakehouse That's Just SQL and Parquet

    How many files does your query read before it reads any data? On some data lakes, you go through JSON and metadata files first, just to learn which Parquet files matter. DuckLake asks one SQL question instead. The metadata lives in a real database. The data stays in plain Parquet. That's the entire format. Pedro Holanda joined DuckDB in 2018, when it was still a research prototype at CWI. He's the lead DuckLake developer. Guillermo Sanchez Dionis works on DuckLake and the new Quack protocol. With Quack as the catalog, DuckLake handles 200 transactions a second under heavy contention. No…

Every episode of Talk Python To Me →

Take it with you

The Melo app keeps playing with the screen off, works in the car and on your watch, wakes you to your station, and browses the whole catalogue offline. Free, no ads, no account.

Get it on Google Play