Very cool!<p>We’ve been exploring a similar direction too, but focused on a plain REPL rather than notebook semantics or explicit session management beyond interrupts and restarts. It seems like the tradeoff is between keeping the interaction model simple and the context small, versus introducing notebook structure earlier and having the model work toward an artifact at the same time as it iterates and explores. Curious how you think about that balance?<p>Repo: <a href="https://github.com/posit-dev/mcp-repl" rel="nofollow">https://github.com/posit-dev/mcp-repl</a>
Thank you for this!<p>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.
One of the authors here, happy to answer questions.<p>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.<p>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.
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")
proxy.sample_rows(limit=5)
proxy.children(path=["model", "layers"], limit=10)
`
This way you get a general interface for AI interacting with your data, while still keeping a very fluid interface.<p>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.<p>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?
Looks cool. I love notebooks.<p>I built something similar with just plain cli agent harnesses for Jupyter a while back.<p>It supports codex subscriptions and pi, (used to support Claude subs, might still be okay since I didn’t modify the system prompt).<p>Has some bugs and needs some work but getting help and code changes inline in Jupyter is way better than copy pasta hard to select text from cells and cell output all day.<p><a href="https://github.com/madhavajay/cleon" rel="nofollow">https://github.com/madhavajay/cleon</a>
[dead]
[flagged]