CopilotKit has published OpenBot, an open-source template for standing up AI “coworkers” on your own infrastructure, and the framing is deliberately unglamorous: it is the assistant your company can own, running in your Docker, writing to your PostgreSQL, using a model key you supply. Each coworker gets a real browser with its own logins, its own files, and only the tools you grant. The pitch that matters is one line in the repo. Anything a Bot does to a computer, a file, an MCP server or a component goes through one gateway that decides and records it.

That sentence is the whole story. Most agent frameworks in 2026 sell autonomy and treat logging as an afterthought. OpenBot sells the opposite: a single chokepoint where every action is decided before it happens and recorded after. The repo puts the distinction plainly. That is the difference between an agent that can use your tools and an agent you can let near them. Whether the implementation lives up to the claim is the open question, but the design choice is the right one to argue about.

What OpenBot actually ships

The repo is candid about what it is not. It is a template, not a product. There is no hosted version to sign up for, and nothing is published as a package to depend on; every workspace in the repository is private. You clone it, replace the example tenant package under examples/ with your own coworkers, channels and skills, and run it. It is beta and under active development, so expect rough edges.

A deployment starts with two coworkers, General Assistant and Knowledge, and both are configuration rather than code. A Risk Analyst joins once its endpoint is configured, and ten more sit in examples/fintech/catalog/. The catalog is specific and small on purpose: reading an expense claim against the policy as written, 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. Each does one job. You add one by copying it into examples/fintech/agents/, writing your own there or in agents.yaml, or making one from /bots in the UI.

The stack is Docker Compose for PostgreSQL and the shipped Bots, Bun 1.4+ for the app and API server, and a CopilotKit Intelligence project and license. No model ships in the box. An administrator supplies the credential, which the repo says is encrypted at rest and never logged. The proof-of-concept Bot uses OpenAI; the LangGraph Bot can use OpenAI, Anthropic, or Google.

The gateway is the argument

Here is where OpenBot earns a second look. The governance rides the protocol, not the framework. A Bot is any endpoint speaking AG-UI, the open agent-to-user protocol, so agents built with LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK or written by hand all arrive the same way. That is a real architectural bet. It means the policy layer does not care which framework a team picked, which is exactly the property you want if you are a platform owner trying to let fifty engineers build agents without fifty different security postures.

The admin surface backs it up. /admin/boundaries configures browser, file and MCP action policy. /admin/audit reviews permitted, refused and failed actions. /admin/approvals sets team rules and shared account requests. /admin/computers views, stops and resets Bot computers. A Bot can run a shell command in its workspace and install what it needs, but through the same gate as everything else, so a rule can refuse a shell outright or refuse particular commands.

Most agent frameworks sell autonomy and treat logging as an afterthought. OpenBot sells the chokepoint.

The isolation story is also more concrete than most. Each person gets their own container, with a folder and browser profile for each of their Bots. Tick Isolated on a Bot to give it a container of its own. Set COMPUTER_RUNTIME=runsc to run them under gVisor where the host supports it. That is the kind of default that matters when a coworker is holding a live login to your expense system.

The catch worth naming

Two things temper the enthusiasm. The first is that OpenBot depends on CopilotKit Intelligence, a licensed product with a free Developer plan that covers running it locally in Docker on a Mac. The local license lasts 30 days and renews with npx copilotkit@latest local renew while your account is in good standing. So “the AI assistant your company can actually own” is true of the agent platform and the data, but not entirely of the intelligence layer underneath it. A company that wants zero vendor dependency in the loop will need to self-host Intelligence, which the repo supports, or accept the managed service.

The second is the beta caveat. The repo says it plainly: expect rough edges and bugs, and expect things to move. A fresh clone sets OPENBOT_SINGLE_USER=true, which admits every request as one administrator so you reach the product without registering an OAuth client. Sign-in turns that off. The point is that the security posture is a configuration away from open, and the people deploying this need to know which side of that switch they are on.

What it means for builders

The interesting move here is not the coworker metaphor. It is the decision to make the gateway the product’s spine and to hang it on an open protocol so it outlives any one framework. If AG-UI holds, OpenBot becomes a reference implementation for governed agents that other platforms copy. If it does not, the template is still a useful checklist: per-Bot containers, encrypted write-only credentials, a deny rule you can add and retry against, an audit log that separates permitted from refused from failed.

Tessera asked CopilotKit for comment on the Intelligence dependency and the beta status. {/* TODO: comment sought from CopilotKit */}

For now the thing to watch is whether teams treat /admin/boundaries as a real control plane or as a checkbox. The repo makes the first option easy. The test is whether anyone uses it before the incident, not after.