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.
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?
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.
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.
Ah, I think I misread your earlier comment. That's a more interesting version of the idea than what I responded to. We don't do this today, but marimo's reactivity already gives us some control plane benefits without virtualizing object access. That said, I can imagine there are many more things a proxy layer could do. Need to think on it, thanks for the clarification :)
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))