Notebook Intelligence

The deciding trait is execution. It creates a notebook, edits it and then runs it, which means the output you are shown is a result rather than a proposal, and the loop of write, run, look at the number happens without you being the one who presses play. For exploratory work that is the whole job.

You are the wrong buyer if notebooks are a side quest and your real code lives elsewhere, because file access is confined to the Jupyter root. Pick it if that root is where you work. Pick an editor agent if it is not.

The documentation says it plainly: the command tool is arbitrary code execution as the user running the server. That is the correct disclosure and it is also the problem, because the notebook process usually holds credentials, mounted data and network reach that nobody granted an agent on purpose. There is no isolation layer in the row, so the blast radius is the account.

What it does right is confine file access to the Jupyter root. Editing cannot wander outside the tree, which bounds one class of accident.

1. Instructions are assembled from files on disk and injected into the system prompt, which means the behaviour of the agent is inspectable and diffable rather than embedded in a binary. Anyone reproducing a result can read what the model was told. 2. Chat participants are addressable individually, so a request goes to a named component rather than a general handler.

2. No evaluation is published and none is claimed. The design asserts structure, and the structure is visible on the filesystem, which is the honest form of that claim.

333 stars, one maintainer and a product that lives inside somebody else's application. Extension economics are unforgiving: distribution is borrowed, the roadmap is a dependency, and the day the host ships a comparable feature the addressable market halves overnight.

Moat: familiarity with a specific host and its extension points, which is real and small. Likely acquirer: none, though the host's ecosystem absorbing the idea is the standard ending. Position: free, useful and replaceable, so use it without making it a requirement in any workflow document.

The provider list includes the seats we already pay for, so for sixty engineers the marginal licence cost is nothing and procurement has nothing new to review. That is the easiest half of this decision.

The hard half is where it installs. Our notebook servers are shared infrastructure with data attached, and there is no SSO for this component, no audit log and no retention policy of its own. Approved with conditions: local installations only, and an explicit exclusion from every shared analytics host.

The clever part is refusing to reimplement anything. One mode shells out to a CLI I already have configured, and everything attached to it, the skills, the plugins, the MCP servers I run, comes along without a second configuration file. That is composition rather than a feature list.

Ollama is a first-class adapter, so nothing has to leave the laptop, and GPL-3.0 means a fork stays open. It installs as an ordinary package into the environment I already manage, which is one fewer thing pretending to be an application.