OpenBot: An Open-Source Framework for Giving Every AI Agent Its Own Computer

An agent that only talks is limited to what it can describe. An agent that can open a browser, read and write files, and run tools is limited to what it can actually do, which is a much bigger and much riskier surface. OpenBot, a new open-source project from CopilotKit, is built around that second version: each agent gets its own isolated computer, a dedicated browser, file system, and toolset, and every action it takes passes through a policy gateway before it runs and gets logged after. Released on GitHub on August 17 and already at 1.8k stars, it is a framework for the part of agent deployment that most demos skip, what happens when the agent is wrong, or malicious, or just clicking somewhere it should not.

What OpenBot actually sets up

The core idea is one isolated environment per agent, not one shared machine that every agent's session touches. Each agent runs in its own container with its own browser instance, its own file system, and its own set of tools, so one agent's mistake, a bad file write, a wrong click on a page, does not bleed into another agent's session or into the host machine it runs on. That containment is the practical difference between a chat window that describes what it would do and a coworker that actually does it, and it is also the reason a framework like this needs more scaffolding than a single API call.

Sitting in front of every one of those actions is a policy gateway: a central checkpoint that evaluates a rule set before letting an action through, and keeps an audit trail of what ran and what got blocked. The rules are written in CEL (Common Expression Language) and can inspect the tool being called, the URL an agent is about to visit, elements on the page, or the specific file being touched, and the default posture is deny, meaning a new action type has to be explicitly allowed before an agent can take it. If an agent hits something it genuinely cannot get past on its own, a login wall, a captcha, a decision that needs a human, a person can step in and take manual control of that same isolated session rather than the agent failing silently or working around the block itself.

OpenBot is not tied to one agent-building framework. It speaks the AG-UI protocol (Agent-User Interaction Protocol), which is also CopilotKit's own project, so agents built on LangGraph, Mastra, CrewAI, or other AG-UI-compatible frameworks can plug into the same environment and gateway rather than each needing custom integration work. On the interface side, agents respond with compiled React components instead of plain text, so the output a person sees is an actual interactive UI element, not a wall of prose describing one.

Setting it up, and what it costs to run

Running OpenBot locally needs Docker and Bun 1.3 or newer, CopilotKit Intelligence credentials, and an API key for whichever model you point it at, OpenAI, Anthropic, or Google, since OpenBot ships with no model of its own and never logs the key you supply. Setup is a .env file, then bun install && bash scripts/start.sh, which brings the app up at http://localhost:3010. It is designed to run on a single machine, orchestrated through Docker Compose, which keeps the initial setup closer to a weekend project than an infrastructure rollout, but also means it is not yet built for a team that wants several people sharing one deployment.

That local-first shape is also where the honest limitations sit. The project's own documentation marks it alpha, with active development and rough edges still expected. It currently supports a single deployment replica, so scaling out to run many concurrent agent sessions is not something the framework handles for you yet. And because it needs your own model API key and your own machine, it is closer to infrastructure for a technical team that wants full control over where an agent's actions actually happen than a hosted product you sign up for and forget about.

Who OpenBot is actually for

OpenBot fits a specific gap: a team that already has agents doing real multi-step work, not just answering questions, and wants those agents to have a real browser and real file access without giving up containment, an audit trail, or a policy boundary on what they are allowed to touch. That is a different problem than most agent frameworks solve, which tend to focus on reasoning and tool-calling logic and leave the question of "where does this actually run, and who's watching it" as an afterthought. If your agents are still confined to answering questions and calling a handful of narrow, pre-approved APIs, the isolation and policy machinery here is more scaffolding than you need yet.

It is also worth being direct about the tradeoff of being this new. A project created on August 17 with an alpha label is not something to point at a production workflow with real user data next week. The right way to evaluate it is closer to how Nuphus MCP, another young, free, open-source tool for driving real applications from an agent, is worth approaching: read the security model and the policy rules before the setup instructions, run it against something low-stakes first, and decide what you would actually let an unsupervised agent touch before you hand it the keys. For a team building toward agents that do real work rather than just describe it, OpenBot is a genuinely useful look at what that scaffolding needs to include, even before the alpha label comes off.