Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Marimo pair – Reactive Python notebooks as environments for agents

github.com

Post reply on HN
Print view View original

11–20 of 40 posts

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#11

Post by gobdovan »

mscolnick wrote: post #9
gobdovan wrote: post #7

Earlier quoted context omitted.

You could wrap pyobject via a proxy that controls context and have AI have a go at it. You can customise that interface however you want, have a stable interface that does things like proxy.describe() proxy.list_attrs() proxy.get_attr("columns") This way you get a general interface for AI interacting with your data, while still keeping a very fluid interface. Built a custom kernel for notebooks with PDB and a similar…

How do you teach the model to use this new API? Wouldn't they be more effective just using the polars/pandas API which is has been well trained with?

Codex just picks it up. The surface is basically a guarded object model, so pandas/polars-style operations stay close to the APIs the model already knows. There's some extra-tricks but they're probably out of scope for an HN comment.

In practice, Pandas/Polars API would lower to: proxy -> attr("iloc") -> getitem(slice(1,10,None))

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#12

Post by jploudre »

I do programming as a side project — Marimo has been a huge unlock for me. Part of it has been just watching the videos that are both updates about the software and also little examples of how to think about data science. Marimo also helps curate useful python stuff to try.

Starting to use AI in Marimo, I was able to both ‘learn polars’ for speed, or create a custom AnyWidget so I could make a UI I could imagine that wouldn’t work with standard UI features.

Giving a LLM more context will be fab for me. Now if I could just teach Claude that this really is the ‘graph’ and it can’t ever re-assign a variable. It’s a gotcha of Marimo vs python. Worth it as a hassle for the interactivity. But makes me feel a bit like I’m writing C and the compiler is telling I need a semicolon at the end of the line. I’ve made that error so many times…..

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#13

Post by manzt »

gobdovan wrote: post #7
manzt wrote: post #3

One of the authors here, happy to answer questions. Building pair has been a different kind of engineering for me. Code mode is not a versioned API. Its consumer is a model, not a program. The contract is between a runtime and something that reads docs and reasons about what it finds. We've changed the surface several times without migrating the skill. The model picks up new instructions and discovers its capabilitie…

You could wrap pyobject via a proxy that controls context and have AI have a go at it. You can customise that interface however you want, have a stable interface that does things like proxy.describe() proxy.list_attrs() proxy.get_attr("columns") This way you get a general interface for AI interacting with your data, while still keeping a very fluid interface. Built a custom kernel for notebooks with PDB and a similar…

Really interesting idea! Part of the ethos here is that models are already really good at writing Python, and we want to bet on that rather than mediate around it. Python has the nice property of failing loudly (e.g., unknown keywords, type errors, missing attributes) so models can autocorrect quickly. And marimo's reactivity adds another layer of guardrails on top when it comes to managing context/state.

Anecdotally working on pair, I've found it really hard to anticipate what a model might find useful to accomplish a task, and being too prescriptive can break them out of loops where they'd otherwise self-correct. We ran into this with our original MCP approach, which framed access to marimo state as discrete tools (list_cells, read_cell, etc.). But there was a long tail of more tools we kept needing, and behind the scenes they were all just Python functions exposing marimo's state. That was the insight: just let the model write Python directly.

So generally my hesitation with a proxy layer is that it risks boxing the agent in. A mediated interface that helps today might become a constraint tomorrow as models get more capable.

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#14

Post by akshayka »

TheTaytay wrote: post #5

Thank you for this! I am a big fan of Marimo and was trying to use it as my agent’s “REPL” a while back, because it’s naturally so good at describing its own current state and structure. It made me think that it would make a better state-preserving environment for the agent to work. I’m very excited to play with this.

Thanks for the kind words.

We've had the same thought, and are experimenting in this direction in the context of recursive language models.

Let us know if you have feedback!

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#16

Post by manzt »

jploudre wrote: post #12

I do programming as a side project — Marimo has been a huge unlock for me. Part of it has been just watching the videos that are both updates about the software and also little examples of how to think about data science. Marimo also helps curate useful python stuff to try. Starting to use AI in Marimo, I was able to both ‘learn polars’ for speed, or create a custom AnyWidget so I could make a UI I could imagine that…

Really glad to hear that! The graph can get complex for big notebooks and maintaining a full picture of variable dependencies across cells is a lot to ask a model to do correctly and hold in context. (It took us a little bit to get the parsing right in marimo!) With pair, it doesn't have to.

The model just "lives" in the environment, and when marimo says "you can't reuse that variable," it renames it and moves on. Hope you give pair a spin!

Re: Show HN: Marimo pair – Reactive Python notebooks as environments for agents

#17

Post by gobdovan »

manzt wrote: post #13
gobdovan wrote: post #7

Earlier quoted context omitted.

You could wrap pyobject via a proxy that controls context and have AI have a go at it. You can customise that interface however you want, have a stable interface that does things like proxy.describe() proxy.list_attrs() proxy.get_attr("columns") This way you get a general interface for AI interacting with your data, while still keeping a very fluid interface. Built a custom kernel for notebooks with PDB and a similar…

Really interesting idea! Part of the ethos here is that models are already really good at writing Python, and we want to bet on that rather than mediate around it. Python has the nice property of failing loudly (e.g., unknown keywords, type errors, missing attributes) so models can autocorrect quickly. And marimo's reactivity adds another layer of guardrails on top when it comes to managing context/state. Anecdotally…

Yeah, I'm talking more about a wrapper over the python data model (pyobject) rather than an MCP-style API for kernel interaction. I'm not proposing you abstract interactions under a rigid proxy, but that you can use proxy objects to virtualise access to the runtime. You could still let the model believe it is calling normal python code, but in actuality, it goes via your control plane. Seeing the demo I'd imagine you already have parts of this nailed down tho.
Post reply on HN