Jupyter AI: Agentic AI Inside JupyterLab via ACP and MCP

What Jupyter AI actually is, and who it is built for

The README describes Jupyter AI as "an open source extension that connects AI agents to computational notebooks in JupyterLab." The wording matters. This is not a model wrapper that ships its own assistant. It is a front end and a set of integration layers that let external agent programs, which you install separately, operate inside a running JupyterLab server.

The intended user is a notebook user who already has an agent CLI they trust. The README lists Claude, Codex, GitHub Copilot, Gemini, Goose, Kiro, Mistral Vibe and OpenCode as supported agents, all reached through the Agent Client Protocol. If none of those names means anything to you, you are not the target audience yet. If one of them is already part of your daily work, the pitch is that you keep using it while gaining notebook and file context.

The project is under incubation in the JupyterLab organization, and the most recent push to the main branch was on 2026-08-28. The releases in the same window are pre-releases (v3.2.0a0, v3.2.0a1, v3.2.0rc0), so the 3.2 line is still settling. That is a normal state for a young extension, but it means you should read the changelog before pinning a version in a shared environment.

How the ACP and MCP layers fit together

Two protocols carry the work. ACP, the Agent Client Protocol, is how JupyterLab talks to an agent process. MCP, the Model Context Protocol, is how an agent reaches tools. Jupyter AI sits on both sides: it speaks ACP to the agent and exposes a Jupyter MCP server so the agent can read and write files, run terminal commands and interact with notebooks.

Detection is automatic. The README states that agents are found when their dependencies are installed, so there is no registry file to edit before your first chat. The practical consequence is that the set of available agents is a function of what is on the machine, not of a configuration list inside Jupyter AI.

Guardrails come from a permission system. Agents request approval before writing files or executing commands. That is a design decision with a cost: the interaction is interrupt-driven, and a long agent task becomes a sequence of prompts. For exploratory work on your own machine that is a reasonable trade. For unattended batch work it is not, and the README does not describe a mode that removes the prompts.

Around the agent itself, the chat UI supports multiple concurrent chats, dragging files or notebook cells in as context, and real-time collaboration with other users connected to the same server. Custom MCP servers can be added to give agents domain-specific tools, resources and prompts, and developers can register their own AI personas through the entry points API.

Installing Jupyter AI and starting a first chat

The package is published as jupyter_ai, and the README points to the Getting Started page for installation, agent setup and first chat. The project metadata requires Python 3.9 or newer. Because the agent is a separate program, plan on two installs: Jupyter AI itself, and the agent CLI you intend to use.

Install the extension into the same environment that runs your JupyterLab server:

pip install jupyter_ai

After installation, start JupyterLab as usual and open the chat interface. The README says agents are detected automatically when their dependencies are installed, so the agent you installed should appear without further configuration. If nothing appears, the dependency is the first thing to check, not the Jupyter AI configuration.

The core dependency set is pinned to narrow ranges, which is worth knowing before you upgrade anything else in the environment:

[project]
name = "jupyter_ai"
requires-python = ">=3.9"
dependencies = [
  "jupyterlab_chat>=0.25.0,<0.26.0",
  "jupyter_ai_acp_client>=0.3.0,<0.4.0",
  "jupyter_server_mcp>=0.3.0,<0.4.0",
]

Two optional groups exist. The magics group adds jupyter_ai_litellm and jupyter_ai_magic_commands, which is the path for the older %%ai cell-magic style of use. The jupyternaut group adds jupyter_ai_litellm and jupyter_ai_jupyternaut, which is the built-in assistant rather than an external agent. Neither is installed by default, so a plain pip install gives you the agent chat, not the magics.

Real-time collaboration is also optional. The project metadata notes that RTC is off unless you install one of the provided groups; the rtc group uses jupyter-collaboration and rtc-jsd uses jupyter-server-documents. Pick one deliberately, because installing both is not described as a supported combination.

The permission system is the feature and the friction

Every agent action that writes a file or runs a command goes through an approval request. That single mechanism is what makes it defensible to hand an agent a Jupyter server that also holds your data, credentials in environment variables and a shell.

The failure mode is attention. Approval prompts are only meaningful if a human reads them, and a prompt that appears twenty times in a session trains the user to click through. The README does not describe per-agent policy files, allowlists or a headless approval path, so the guardrail is as strong as the person sitting in front of it. If you plan to run Jupyter AI on a shared server with several collaborators, the real-time collaboration feature means other users are connected to the same session; the README does not document how approval requests are attributed or arbitrated between users. Confirm that before you put it in front of a team.

The second constraint is the dependency surface. Jupyter AI pulls in a chat package, a router, a persona manager, a chat-commands package, an ACP client, an MCP server, a tools package and a live-content package, each pinned to a minor range. In a fresh environment that is fine. In an environment already carrying a JupyterLab stack built by someone else, expect to resolve versions rather than just install.

Where Jupyter AI is the wrong choice

If you want one assistant that answers questions about your code without leaving the notebook, and you do not want to install a separate agent binary, Jupyter AI is more machinery than you need. The optional jupyternaut group exists for a built-in assistant, but it is an optional extra rather than the default experience, and the README frames the project around external agents.

If your work is unattended, the permission model works against you. Agents that must ask before every write and every command are a poor fit for scheduled or batch execution, and nothing in the README suggests that requirement can be waived.

If you are not in JupyterLab, the extension does nothing for you. It is a JupyterLab extension, incubated in the JupyterLab organization, and the chat UI lives in the Lab interface. Editor-integrated assistants that operate on a repository rather than a running server solve a different problem, and swapping one for the other is not a configuration change.

Finally, if you need a stable, long-lived interface, note that the current release line is pre-release. The last push was 2026-08-28, and the three most recent tags are v3.2.0a0, v3.2.0a1 and v3.2.0rc0. Pre-release tags are not a defect, but they are a signal about how much churn to expect in the entry points API and the persona manager.

Alternatives and the real difference in approach

The closest comparison is a vendor assistant that ships its own model and its own interface, of the kind people search for as a Jupyter AI versus GitHub Copilot question. The difference is architectural, not cosmetic. A vendor assistant bundles the model, the client and the UI, so installation is one step and the behaviour is uniform. Jupyter AI bundles none of the model. It standardises the connection instead, which is why the README can list seven agents and why adding a custom MCP server is a supported path rather than a fork.

A second alternative is the built-in assistant route, which the project itself offers through the jupyternaut optional group. That path uses jupyter_ai_litellm and jupyter_ai_jupyternaut and does not require an external agent CLI. It is the lower-setup option and the one to consider if the ACP layer is the part you do not want.

A third is a general editor-integrated agent that treats your repository as the workspace. Those tools edit files on disk and run commands in a terminal outside the notebook kernel. Jupyter AI's distinguishing capability is the Jupyter MCP server: the agent interacts with notebooks as notebooks, and cells can be dragged into the chat as context. If your work is mostly .py files, that capability buys you nothing.

Maintenance, upgrade cost and licence

The repository is not archived, and the last push was on 2026-08-28. Releases in the days before that were all pre-releases, which tells you the maintainers are still moving the 3.2 line. For an incubating project that is expected, but it sets your upgrade policy: pin the minor version, read CHANGELOG.md before bumping, and do not track main in an environment other people depend on.

The upgrade cost is concentrated in the pinned dependencies. Because jupyter_ai holds narrow ranges on jupyterlab_chat, jupyter_ai_acp_client, jupyter_server_mcp and the rest, a Jupyter AI upgrade can force upgrades of packages you did not intend to touch. Budget for that in any environment with other JupyterLab extensions installed. The entry points API for custom personas is the other surface likely to move, so a persona you wrote against one minor version deserves a test before you rely on it after an upgrade.

The licence is BSD-3-Clause, declared in pyproject.toml and in the LICENSE file, and the Python classifier is "License :: OSI Approved :: BSD License". That is a permissive licence, which matters here for a specific reason: Jupyter AI does not ship a model, so the licensing question you actually face is the terms of whichever agent and model you connect, not the terms of the extension. The extension's licence says nothing about those, and the README does not attempt to. Read the agent vendor's terms separately.

Editorial conclusion

Adopt Jupyter AI if you already work in JupyterLab and want agents that can touch real files and kernels under an approval prompt, and if you are comfortable installing agent CLIs yourself. Do not adopt it if you want a single self-contained assistant with a hosted model and no extra binaries, or if you expect the magics-based interface to be the default, because the optional magics and jupyternaut groups are separate installs. Verify first that pip resolves the pinned dependency set without conflict, that your agent is detected automatically, and that the permission prompts behave the way your team expects before you let an agent run against a shared server.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes