Open Multi-Agent Canvas: A CopilotKit Frontend That Requires Copilot Cloud

The problem: one chat window that has to hold several agents at once

Most agent demos give you a single assistant with a single tool loop. The moment you want a travel planner and a research agent in the same session, you are either writing your own routing layer or opening two browser tabs and copying context between them. Open Multi-Agent Canvas targets that gap. The README describes it as an open-source multi-agent chat interface that lets you manage multiple agents in one dynamic conversation, and names travel planning, research and general-purpose tasks as the intended work. The audience is narrow and specific: developers who already build on CopilotKit and LangGraph, who want a front end they can point at agents that live elsewhere, and who are willing to accept a hosted dependency to get there. It is not a library you import into an existing app. It is a canvas you run.

Three pieces: a Next.js canvas, LangGraph agents, and an MCP agent in the middle

The architecture visible in the material is a split between a frontend and an agent backend. The frontend is a Next.js application built with CopilotKit, and its only documented environment variable is NEXT_PUBLIC_CPK_PUBLIC_API_KEY, which points at Copilot Cloud. The agents are not shipped inside this repository. The README lists a CoAgents Travel Agent and a CoAgents AI Researcher that live in separate repositories and can be run separately or deployed on LangSmith. The one agent that does ship here is the MCP Agent, described as general-purpose and able to handle various tasks through configurable MCP servers. That agent runs as a LangGraph server, and the frontend reaches it over a tunnel on port 8123. So the data flow is: browser canvas, CopilotKit runtime, tunnel, LangGraph server, MCP servers. Note the README expands MCP as Multi-Channel Protocol. The widely used expansion is Model Context Protocol, and the documentation link it gives points at LangGraph's MCP examples. Treat the expansion in the README as a typo rather than a different protocol.

Running the frontend and the MCP agent backend

The frontend path is short. You need pnpm. You rename example.env in the frontend folder to .env and fill in NEXT_PUBLIC_CPK_PUBLIC_API_KEY, which you obtain from the CopilotKit dashboard. Then cd frontend, pnpm i, and pnpm run build && pnpm run start. The backend is optional and separate. Rename example.env in the agent folder to .env and set OPENAI_API_KEY and LANGSMITH_API_KEY. Then cd agent, poetry install, and poetry run langgraph dev --host localhost --port 8123 --no-browser. If you want the frontend to reach that local server, the README says to open another terminal, select Remote Endpoint, then Local Development, copy the generated command, and change the port to 8123. That tunnel step is the part most likely to bite: the frontend and the backend are separate processes with separate env files, and the only thing joining them is a forwarded port. Nothing in the material describes what happens when the tunnel drops mid-conversation.

MCP servers are configured in the UI, not in a config file

The MCP Agent is configured from inside the running interface. The README says to click the MCP Servers button in the top right, then add servers through the configuration panel. Two transports are supported: Standard IO, which runs commands locally such as Python scripts, and SSE, which connects to external MCP-compatible servers over Server-Sent Events. The README points at mcp.composio.dev and mcp.run as public servers you can connect to. This is the most interesting design decision in the project, and also the one with the least documentation. Standard IO means the canvas can spawn local processes on the machine running the backend. The README does not describe any allowlist, confirmation prompt or sandbox around that. If you are evaluating this for a shared or hosted deployment, that is the first thing to read in the source, because the material does not answer it.

The Copilot Cloud requirement is the real adoption boundary

The README states plainly that Copilot Cloud is required to run this project, and the only frontend environment variable is a Copilot Cloud public API key. That single line rules out a large class of use cases. You cannot stand this up on an air-gapped network, in a regulated environment that forbids third-party SaaS in the request path, or as a fully local demo, without either obtaining a key or replacing the CopilotKit runtime layer yourself. This is not a hidden cost, it is stated, but it is easy to skim past because the project is described as open source under the MIT License. Open source here means the source is readable and modifiable, not that the running system is self-contained. The second boundary is maintenance. A note at the bottom of the README says the project has been consolidated into the CopilotKit monorepo and that the latest version lives at examples/showcases/multi-agent-canvas, with issues and pull requests to be opened in the main CopilotKit repository. That makes this repository a pointer rather than the active development surface. There are no releases retrieved for it, so there is no versioned artefact to pin against.

What you would use instead, and how the approach differs

The obvious alternative is to assemble the same thing from CopilotKit and LangGraph directly, without this canvas. The difference is where the work sits. This project hands you a finished chat shell with an MCP configuration panel already wired to the agent runtime, so the effort goes into pointing it at agents and servers. Building it yourself means writing the multi-agent switching UI, the MCP server form, and the transport handling for Standard IO and SSE, but you keep control of the runtime and are not bound to a Copilot Cloud key. A second alternative is LangGraph Studio or langgraph dev on its own, which the README already uses as the backend command. That gives you the agent graph and its traces with no chat interface at all, which is the right tool if you are debugging an agent rather than demonstrating one. The honest framing: this canvas saves frontend work and adds a hosted dependency. If your bottleneck is the interface, it is worth the trade. If your bottleneck is the agent, it is not.

Licence and the cost of tracking a consolidated project

The README says the project is distributed under the MIT License and points at a LICENSE file. The repository metadata supplied here lists the licence as unknown, so verify the LICENSE file in whichever copy you actually clone. MIT is permissive, which means the usual obligations are attribution and keeping the licence text with redistributed source. That is a description of the licence, not legal advice. On maintenance: because the README directs you to the monorepo path, your upgrade path runs through CopilotKit's release cadence rather than this repository's. The practical consequence is that a fork pinned to this repository will drift from the maintained copy, and the tunnel plus port 8123 arrangement is the kind of setup detail that tends to change when a showcase moves into a monorepo. Check the monorepo copy's README before you write any deployment scripts against the instructions here.

Editorial conclusion

Adopt this only if you already hold a Copilot Cloud API key and want a working multi-agent chat shell with an MCP configuration panel, and read the copy under examples/showcases/multi-agent-canvas in the CopilotKit monorepo rather than this repository, because the README states the project has been consolidated there and asks for issues and pull requests to be opened in the main CopilotKit repository. Do not adopt it if you need a self-contained stack with no hosted dependency, or if you cannot run a LangGraph server and a tunnel on port 8123. Verify two things first: whether the consolidated copy still requires Copilot Cloud, and whether the MIT licence in the LICENSE file survives the move.

Official sources

1. CopilotKit/open-multi-agent-canvas on GitHub
2. Issues
3. Project website
4. README