6 ms·

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

140 points by manzt 6mo ago

Hi HN! We're excited to share marimo pair [1] [2], a toolkit that drops AI agents into a running marimo notebook [3] session. This lets agents use marimo as working memory and a reactive Python runtime, while also making it easy for humans and agents to collaborate on computational research and data work. GitHub repo: https://github.com/marimo-team/marimo-pair https://github.com/marimo-team/marimo-pair Demo: https://www.youtube.com/watch?v=6uaqtchDnoc https://www.youtube.com/watch?v=6uaqtchDnoc marimo pair is implemented as an agent skill. Connect your agent of choice to a running notebook with: /marimo-pair pair with me on my_notebook.py The agent can do anything a human can do with marimo and more. For example, it can obtain feedback by running code in an ephemeral scratchpad (inspect variables, run code against the program state, read outputs). If it wants to persist state, the agent can add cells, delete them, and install packages (marimo records these actions in the associated notebook, which is just a Python file). The agent can even manipulate marimo's user interface — for fun, try asking your agent to greet you from within a pair session. The agent effects all actions by running Python code in the marimo kernel. Under the hood, the marimo pair skill explains how to discover and create marimo sessions, and how to control them using a semi-private interface we call code mode. Code mode lets models treat marimo as a REPL that extends their context windows, similar to recursive language models (RLMs). But unlike traditional REPLs, the marimo "REPL" incrementally builds a reproducible Python program, because marimo notebooks are dataflow graphs with well-defined execution semantics. As it uses code mode, the agent is kept on track by marimo's guardrails, which include the elimination of hidden state: run a cell and dependent cells are run automatically, delete a cell and its variables are scrubbed from memory. By giving models full control over a stateful reactive programming environment, rather than a collection of ephemeral scripts, marimo pair makes agents active participants in research and data work. In our early experimentation [4], we've found that marimo pair accelerates data exploration, makes it easy to steer agents while testing research hypotheses, and can serve as a backend for RLMs, yielding a notebook as an executable trace of how the model answered a query. We even use marimo pair to find and fix bugs in itself and marimo [5]. In these examples the notebook is not only a computational substrate but also a canvas for collaboration between humans and agents, and an executable, literate artifact comprised of prose, code, and visuals. marimo pair is early and experimental. We would love your thoughts. [1] https://github.com/marimo-team/marimo-pair https://github.com/marimo-team/marimo-pair [2] https://marimo.io/blog/marimo-pair https://marimo.io/blog/marimo-pair [3] https://github.com/marimo-team/marimo https://github.com/marimo-team/marimo [4] https://www.youtube.com/watch?v=VKvjPJeNRPk https://www.youtube.com/watch?v=VKvjPJeNRPk [5] https://github.com/manzt/dotfiles/blob/main/.claude/skills/marimo-dev/SKILL.md https://github.com/manzt/dotfiles/blob/main/.claude/skills/m...

aimadetools 6mo ago
[flagged]
manzt 6mo ago
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 capabilities within a session, and figures out the rest.
- gobdovan 6mo ago
  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 interface, the trick is to also have access to the same API yourself (preferably with some extra views for humans), so you see the same mediated state the AI sees. By 'wrap' I mean build a capability-based, effect-aware, versioned-object system on top of objects (execs and namespaces too) instead of giving models direct access. Not sure if your specific runtime constraints make this easier or harder. Does this sound like something you'd be moving towards?
  - mscolnick 6mo ago
    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?
    - gobdovan 6mo ago
      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))

140 points by manzt 6mo ago

aimadetools 6mo ago

[flagged]

manzt 6mo ago

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 capabilities within a session, and figures out the rest.

gobdovan 6mo ago
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 interface, the trick is to also have access to the same API yourself (preferably with some extra views for humans), so you see the same mediated state the AI sees. By 'wrap' I mean build a capability-based, effect-aware, versioned-object system on top of objects (execs and namespaces too) instead of giving models direct access. Not sure if your specific runtime constraints make this easier or harder. Does this sound like something you'd be moving towards?
- mscolnick 6mo ago
  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?
  - gobdovan 6mo ago
    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))