OpenBot: a forkable template where one gateway governs every AG-UI agent's actions

OpenBot ships as a repository to clone, not a package to depend on

OpenBot is CopilotKit's open-source, MIT-licensed take on a company AI assistant: the same chat shape as ChatGPT, Claude or Grok, but running on infrastructure you control and open to change in every part. The important word in its own framing is template. There is no hosted version to sign up for, and nothing in the repository is published as a package. Every workspace is private, so you cannot add OpenBot to an existing app with a dependency line and pull upgrades later.

The intended workflow is to take the whole repository, replace the example tenant package under examples/ with your own coworkers, channels and skills, and run it. The consequence is ownership in both directions. You can change anything, and you also own the merge every time upstream moves. The project calls itself beta and warns to expect rough edges, bugs and things that move. Recent tags show the pace: v0.1.1 on October 6, 2026, v0.1.2 the next day, and v0.2.0 on October 12, 2026, with the last push on November 2, 2026. A fork taken now will drift from upstream quickly, so decide how you will carry your examples/ changes across upstream updates before you invest heavily in them.

Any AG-UI endpoint can become a coworker

A Bot in OpenBot is any endpoint speaking AG-UI, the open protocol for agent-to-user interaction. That choice is what keeps the platform framework-neutral: an agent built on LangGraph, Mastra, CrewAI, Pydantic AI or Google ADK, or one written by hand, arrives the same way and gets a channel of its own. Governance rides on the protocol rather than on any framework, so the controls described below apply regardless of which library produced the agent.

The repository shows how wide that net is meant to be. Top-level directories exist for agent-adk, agent-ag2, agent-agno, agent-antigravity, agent-claude-sdk, agent-crewai, agent-langgraph, agent-langgraph-agui, agent-langroid, agent-llamaindex, agent-mastra, agent-microsoft, agent-pydantic-ai and agent-strands, and examples/ holds langgraph-bot, mastra-bot and pydantic-ai-bot next to the fintech tenant.

The limit is the protocol itself. An agent that does not speak AG-UI cannot be hosted as it stands; it has to be wrapped or rewritten to expose an AG-UI endpoint first. OpenBot also answers with components rather than only prose, so the interface you see depends on what your agent sends over that protocol.

One gateway decides every action before it runs and records it after

The central mechanism is a single gateway. Anything a Bot does to a computer, a file, an MCP server or a component passes through it, and the gateway decides whether the action happens and records it afterward. CopilotKit's own summary of why that matters: it is the difference between an agent that can use your tools and an agent you can let near them.

Each coworker is given a real browser with its own logins, its own files, and only the tools you grant. You can watch a Bot work on its own screen, take the wheel when it reaches something it should not do alone, and then hand control back. The audit trail, the policy store and the agent tables all live in your PostgreSQL, which is why the project treats the database as the part that must survive. The Dockerfile comment puts it bluntly: the audit trail is the product.

For anyone evaluating governance, the useful property is that this sits below the agent framework. A LangGraph agent and a hand-written one meet the same decision point, because both reach tools through the same gateway rather than through framework callbacks that each library implements differently.

Coworkers are configuration, and thirteen are already written

A fresh deployment starts with two coworkers, General Assistant for everyday work and Knowledge for company questions. They are configuration rather than code. A third, Risk Analyst, joins once its endpoint is configured, and ten more sit in examples/fintech/catalog/, each built for one job: reading an expense claim against the written policy, turning a meeting note into the follow-ups actually in it, drafting release notes from what shipped, triaging a ticket, answering a new starter from the handbook, writing a brief that names what it could not find, writing up an interview, handing over an on-call shift, assembling what is known before a renewal, and grouping customer feedback into themes it can cite.

There are three ways to add one. Copy a catalog entry into examples/fintech/agents/, write your own there or in agents.yaml, or create one from the /bots page in the UI. The catalog lives inside the fintech example tenant, which is exactly the package the template expects you to replace. Treat these entries as patterns to copy into your own tenant rather than coworkers you keep where they are, or your customizations will sit inside a directory that upstream also changes.

First run depends on Bun 1.4, Docker and a CopilotKit Intelligence project

The requirements list is short but has two sharp edges. Docker runs PostgreSQL and the shipped Bots. Bun 1.4 or newer runs the app, the API server and the tests, and some tests fail on Bun 1.3. You also need a CopilotKit Intelligence project and license, and a model key, because no model ships in the box. The proof-of-concept Bot uses OpenAI, while the LangGraph Bot can use OpenAI, Anthropic or Google. An administrator supplies the model credential, which is encrypted at rest and never logged.

Setup begins by creating the environment file and installing dependencies:

cp .env.example .env
bun install

Then connect a fresh managed Intelligence project:

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun scripts/setup-learning.ts

The setup-learning helper provisions the selected project's runtime key, creates or reuses a Learning container named openbot, and writes both settings to .env. It keeps custom container assignments and never replaces an existing OpenBot key; with a key already set, it only creates the openbot container in that key's project if it is missing. For a self-hosted Intelligence deployment, set INTELLIGENCE_API_URL to that deployment's HTTPS API origin, or http://localhost for a local one, and run the helper without the two npx commands. It opens an isolated Chrome or Edge window for sign-in and project choice, so one of those browsers has to be installed first.

If you are setting up with an AI assistant, prompt.txt in the repository root carries the same steps plus the details that trip people up: which blank keys in .env.example are yours to fill (the CopilotKit key and a model key), which the start script fills, and what each start-up refusal means.

OPENBOT_SINGLE_USER=true admits every request as the administrator

Out of the box, .env.example sets OPENBOT_SINGLE_USER=true. That flag admits every request as one administrator, which is how a fresh clone reaches the product without registering an OAuth client first. It is a laptop convenience. With it on there is no separation between people: whoever can reach the deployment acts as the administrator.

Configuring sign-in switches this off, and the project states that sign-in is required before anybody else can reach the deployment. The practical consequence is simple. Do not put a default clone on a shared network, a cloud VM or behind a tunnel to show a colleague. Register the OAuth client and enable sign-in first.

The same assumption runs through the rest of the default setup. The instructions are written for a laptop with one person in front of it, and the Intelligence side follows suit: CopilotKit's free Developer plan covers running Intelligence locally in Docker on a Mac. Moving from that to a team deployment is a set of deliberate changes you make, not a mode you toggle.

The Compose file walls PostgreSQL off from the Bot's shell

docker-compose.yml is unusually explicit about its threat model. The postgres service runs pgvector/pgvector:pg17 and is deliberately kept off the network the Bots use. The reason given in the file: a Bot's computer is on that network, and a Bot has a shell. With no networks defined, Compose would put every service on one network with DNS by service name, so the agent-computer container could open postgres:5432. The comment cites agent-computer/src/shell.ts on the same point: isolation is the container's job, and a shell can reach whatever the container can reach.

Only migrate, plus server and worker when an installed OpenBot runs them, reach the database by name. In local development the API server and the worker run on the host and connect through a published port. That port is bound to loopback on both addresses, because a port published on every interface was reachable from inside agent-computer at the container's default gateway, which is the host. The file records that this was proven: the gateway on 5432 answered and began authenticating as openbot.

The weakness the file points at is its own credentials. POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD are all set to openbot, in plain text in the Compose file. The network split and the loopback binding are what keep them out of a Bot's reach locally. Anything beyond a laptop needs real secrets in their place.

The one-container image gives up per-Bot isolation

The Dockerfile builds everything a laptop runs, minus the database, into one image on one port: the app, the API and a browser the Bots can drive, matching what scripts/start.sh gives you locally. It is meant for any platform that runs a container. Two pieces are left out on purpose, and both change what you get.

PostgreSQL is not in the image because a container filesystem does not survive a redeploy, so DATABASE_URL has to point at a managed instance. The supervisor is also missing. Its job is to give each Bot its own container, which needs a Docker socket, which no serverless container platform permits. Without it, every Bot shares the single browser in the image, exactly as Bots do on a laptop with no supervisor configured. The per-coworker browser with its own logins therefore holds only where the supervisor can run. On a serverless container host, coworkers share one browser and the sessions in it.

The image pins its toolchain: node:24.18.1-bookworm-slim, oven/bun:1.4.3 by digest, an ubuntu:24.04 base, and PLAYWRIGHT_VERSION=1.62.1 for Chromium, which comes from Playwright's own installer rather than Playwright's all-browser image. The file asks that this Playwright version stay matched to agent-computer/package.json, bumped together or not at all, so a fork that updates one without the other breaks that pairing.

Editorial conclusion

OpenBot fits a team that wants to own a governed agent platform outright and is prepared to fork a beta template, run Docker and Bun 1.4, and hold a CopilotKit Intelligence license. It does not fit anyone looking for a hosted assistant or a package to embed in an existing app. Before going past a laptop, turn off OPENBOT_SINGLE_USER by configuring sign-in, replace the openbot database credentials, and confirm whether your host can run the supervisor, since without it every Bot shares one browser.

Frequently asked questions

Official sources

1. CopilotKit/OpenBot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases