CopilotKit OpenBot Gives Each Agent a Computer

Four days after the repository went public, CopilotKit OpenBot has 600 stars and one tagged release numbered v0.0.1. That gap between attention and maturity is the whole story here. The pitch is unusual enough to be worth reading carefully: instead of a chat window that can call tools, you get a set of AI coworkers, each with a container of its own holding a real browser, a real filesystem and whatever tools an administrator has granted. Nothing reaches those tools without a decision recorded first.

If you have watched a browser agent log into something on your behalf and then wondered what else it clicked, that recording requirement is the part worth your attention.

What CopilotKit OpenBot actually is

CopilotKit OpenBot is a self-hosted agent platform, released under MIT by CopilotKit, the company behind the AG-UI protocol. Docker Compose brings up every piece; your data sits in your own PostgreSQL; no model ships in the box, so an administrator supplies the credential, which is stored encrypted and kept out of the logs.

Three coworkers come with the example package: a General Assistant, a Knowledge bot for company questions, and a Risk Analyst. They're configuration rather than code, defined in an agents.yaml file or built through the /agents screen, which means adding a fourth doesn't involve writing a service.

The framing the project uses is that a Bot is anything that speaks AG-UI. Agents written on LangGraph, Mastra, CrewAI, Pydantic AI or Google's ADK all arrive through the same door, as does something you wrote by hand this afternoon. Governance rides on the protocol rather than on the framework, so switching frameworks doesn't cost you the policy layer.

The difference from a browser-use style agent

Point a general browser agent at a task and it drives Chrome on your machine, with your cookies, using your logged-in sessions. It works, and it works fast, and the audit trail is whatever you remember watching. When something goes wrong the reconstruction is archaeology: scroll back through a transcript, guess which tool call did the damage, hope the model narrated it honestly.

CopilotKit OpenBot inverts that. Every action a Bot takes against a computer, a file, an MCP server or a UI component passes through one gateway. The gateway resolves the target from a server-held snapshot rather than trusting what the model claimed it was clicking, evaluates the request against policy, writes an audit row, and only then acts. There's no code path that performs an action before the record exists.

Policies are written in CEL and fail closed. Rules can inspect the tool name, the declared intent, the bot and actor identity, the page URL and host, element attributes, keystrokes, file paths and MCP fields. Deny is evaluated before allow; an absent policy permits nothing; a rule that fails to compile refuses rather than opening the gate. That last choice is the one that separates a governance layer from a configuration file, because broken config usually degrades toward permissive.

What "each coworker gets its own computer" means in practice

In CopilotKit OpenBot a supervisor process hands every Bot a container with its own /workspace volume and its own browser profile, complete with its own logins. Set COMPUTER_RUNTIME=runsc and those containers run under gVisor where the host supports it.

The practical effect is that two coworkers can hold two different sets of credentials for the same service without either seeing the other's session, and neither is touching the Chrome profile you use for your own work. Compared to a laptop agent sharing your cookie jar, that's a meaningful boundary. The cost is equally concrete: a container per coworker, each running Chromium, all of it on hardware that has to be awake when someone starts a channel.

That's the seam where a self-hosted design starts asking for infrastructure rather than a laptop. Containers with browsers inside them are not something a MacBook lid closing is kind to, and the platform assumes the machine underneath it is a server. MoClaw answers the same requirement from the other end: a hosted cloud AI computer that's already up, with a screen and a filesystem of its own, so you get the "not my machine, not my cookies" property without standing up the supervisor yourself.

Decide before acting, record after

The audit model has two halves that are easy to conflate. Deciding happens before the action, against policy the server holds. Recording happens after, and includes refusals and failures, not only successes. Open /admin/audit and the permitted, refused and failed rows sit together, which is the view you want when someone asks why a task stopped halfway.

Two behaviours in that system are worth calling out because most agent tooling gets them wrong.

Secrets never enter the transcript. When a Bot requests a credential, the trail records that a secret was requested and how long it was; the value itself doesn't appear. Anyone who has grepped an agent log for an accidentally echoed token knows why that matters.

Then there's the handover. A Bot that hits a login wall or a 2FA prompt asks for help rather than guessing, and control passes to a person in the same panel. The events are named computer.help_requested, computer.control_taken and computer.control_released. While a human is driving, Bot actions are refused rather than queued, so nothing fires the instant you let go.

Handover raises a question the project doesn't answer, though: the person taking the wheel has to be sitting at the machine the platform runs on, or tunnelled into it. Agents that run somewhere other than your desk need the handover to work from wherever you happen to be, which is the case MoClaw is built around — the computer stays in the cloud and you take the wheel from whichever device you opened it on.

Bringing your own AG-UI agent

AG-UI is an open protocol for agent-to-user interaction, and CopilotKit wrote it. That lineage explains why CopilotKit OpenBot treats the protocol, rather than any one framework, as the thing worth building on. Any endpoint speaking it registers as a Bot; endpoints get the same target validation the platform applies to browser navigation, and the auth header is stored write-only.

The MCP catalogue is curated rather than open by default, shipping entries for Atlassian, Box, Slack, Salesforce and ServiceNow. Custom servers have to pass URL checks first. The classification rule underneath is the conservative one: any tool not positively identified as a read gets treated as a write, which means an unfamiliar MCP tool lands under write policy instead of slipping through as harmless.

There's also a component layer, where Bots answer with compiled React components rather than only prose, and every call asks the server whether that component exists, is published, and isn't withheld from that particular Bot.

Is it free, and can you actually self-host it?

MIT, and yes, with an asterisk. Standing it up needs Docker, Bun 1.3 or newer, a PostgreSQL instance, a model key, and a CopilotKit Intelligence project and licence. That last dependency is the one to read twice before calling this a fully independent stack: threads live in CopilotKit Intelligence, and the quick start walks you through copilotkit login, project select and license --write to get the credentials.

One default deserves flagging. Out of the box the app runs with OPENBOT_DEV_NO_AUTH, which skips sign-in and admits every request as a single administrator. Google sign-in can be wired up instead, and should be before anything reaches a shared network.

The README calls the project alpha and says to expect rough edges and movement, which matches what the repository shows: fifteen commits, four contributors, one release. Treat CopilotKit OpenBot as a design worth studying and a codebase worth watching, not as something to put in front of a finance team next week. If the appeal is the governed-access idea rather than running the infrastructure, MoClaw covers the same ground as a managed service that sits alongside whatever you already run rather than replacing it.

Who this is aimed at, and what it costs to run

The three example coworkers point at the intended buyer plainly enough: a Knowledge bot answering from company documents, a Risk Analyst, and a General Assistant. That's an internal operations team at a company with a compliance function, not a solo developer automating a side project. The launch page says as much, calling it an enterprise agent platform that runs inside your own infrastructure.

Running it means keeping five things alive: PostgreSQL, the API server on port 3001, the app on 3010, the supervisor, and one browser container per active coworker. Nothing in the architecture is exotic, and all of it needs an operator. If four coworkers are on shift, four Chromium instances are resident, and the box has to be reachable whenever anyone opens a channel.

The uncomfortable arithmetic for a small team is that the governance you came for arrives bundled with a platform you now have to run. MoClaw takes the other side of that trade: the cloud AI computer is already provisioned and already awake, so the browser, the files and the tools live somewhere other than a laptop without anyone maintaining a supervisor process. It sits next to whatever you already have rather than asking you to migrate onto it.

FAQ

Is CopilotKit OpenBot open source?

Yes. The repository ships an MIT licence file. Running it in production still requires a CopilotKit Intelligence project and licence, so the code being MIT doesn't make the whole deployment dependency-free.

Who makes OpenBot?

CopilotKit, the company behind the AG-UI protocol. The launch page describes AG-UI as "the protocol we wrote," and the four contributors on the repository as of 20 August 2026 are CopilotKit engineers.

Does OpenBot work with any AI agent?

Any agent that exposes an AG-UI endpoint, which covers LangGraph, Mastra, CrewAI, Pydantic AI and Google ADK builds along with hand-written services. Agents that only speak a proprietary protocol need an adapter first.

How is this different from giving an agent access to my browser?

Your browser carries your sessions and produces no record. Each coworker here gets a separate browser profile inside its own container, and every action is checked against policy and logged before it runs. For the wider version of that argument, see our guide to AI agent sandboxes.

Can I run it without Docker?

Not as shipped. Docker provides PostgreSQL, the per-Bot computers, the supervisor and the example Bots, and scripts/start.sh assumes all of it.

Worth watching, not yet worth deploying

Two things about this release are more interesting than the star count. The first is that a company that writes protocols chose to ship a reference platform with governance in the data path rather than in the documentation. The second is how much infrastructure honest governance turns out to need: a gateway, a policy engine, a supervisor, a container per coworker, and a database holding every decision.

Whether you deploy it or not, the questions it forces are the right ones to ask of anything you do deploy. Which actions get decided before they happen? Where does the refusal get written down? And when the agent hits a wall at 2am, who takes the wheel, and from where?

For the permissions side of that question in the skills ecosystem, see our review of third-party agent skill permissions, and for what self-hosting this class of tool costs once it's running, our breakdown of self-hosted agent costs.

All figures verified against the GitHub API and the project README as of August 2026.