The Problem

Most agent frameworks give an LLM a long list of tools and hope for the best. That breaks down in production: no audit trail, no per-action policy enforcement, and no isolation between the agent's environment and yours. OpenBot addresses this by giving each agent its own containerized computer (browser, files, credentials) and routing every tool call through a single governance gateway that decides, records, and then acts.

What This Does

OpenBot is a self-hosted platform for running "AI coworkers" that speak the AG-UI protocol. The core idea is that any agent—built with LangGraph, Mastra, or by hand—can be dropped in and immediately gets a UI channel, a dedicated browser container, and an audit trail. The agent-computer/ package is the isolated environment; server/ holds the gateway and API; app/ is the React frontend for watching and interacting with agents.

The repo is a fork of CopilotKit/openbot (1,041 stars upstream) and is explicitly marked alpha. It ships with Docker Compose for the full stack, PostgreSQL for state, and three example agents defined in agents.yaml rather than as code. The model credential is supplied by an administrator, encrypted at rest, and never logged.

How It Is Wired

A run starts at agent-computer/src/index.ts, which exposes the containerized computer. The control flow is: user message → server → AG-UI turn to the bot → bot calls a tool → the call returns to the gateway (in server/) → the gateway resolves the target against policy → audits the row → only then executes.

The critical files are:

  • agent-computer/src/control.ts — the action dispatcher; every browser/file/MCP action routes through here.
  • agent-computer/src/authorisation.ts — policy checks; this is the blast-radius file, because a bug here means an agent can act without approval.
  • agent-computer/src/egress.ts — network egress control.
  • agent-computer/src/workspace.ts — per-agent file system.
  • server/ — the AG-UI gateway, audit log, and API.
  • supervisor/ — builds and manages the per-agent browser containers.

There is a hub-and-spoke topology: authorisation.ts and control.ts are the hubs, and everything an agent does passes through them. Changing the policy model touches every effect in the system. The module graph shows no cycles, which is good—the dependency direction is clear from agent → computer → gateway.

How To Use It

The README documents a laptop-first setup. The full stack runs via Docker Compose; the app and API server use Bun 1.3+. Clone with:

git clone https://github.com/moses-y/openbot
cd openbot
  • Setup: Docker for PostgreSQL, browser containers, and the supervisor; Bun 1.3+ for the app/API.
  • Configuration: .env.example at the root. For a quick start, OPENBOT_DEV_NO_AUTH skips sign-in and admits all requests as one administrator. Production needs Google sign-in, a CopilotKit Intelligence project/license, and a model key (no model ships in the box).
  • Running: The README's quick-start section is the authoritative source; the exact compose command is documented there. The app entry point is app/index.html; the server entry points are the src/index.ts files in agent-bot/, agent-computer/, and agent-langgraph/.

Real-World Use

A compliance team wants an agent that drafts risk assessments. They deploy OpenBot, define a Risk Analyst in agents.yaml, grant it only read access to a document store and a browser profile for the internal risk portal. Every action the agent takes—opening a page, saving a draft, calling an MCP tool—is decided against policy in authorisation.ts, written to PostgreSQL, and visible in the React UI. If the agent tries to download a file outside its workspace, egress.ts blocks it and the audit row names the rule.

Code Health & Issues

Measured analysis found one issue: Low risk — agent-bot/package.json declares dependencies without a lockfile, so builds are not reproducible. The other two package dirs (agent-computer/, agent-langgraph/) do ship bun.lock files.

Beyond that, the structure looks sound: 79 test files exist, CI runs via GitHub Actions (.github/workflows/ci.yml), and there is a security workflow (security_zizmor.yml). The app/ directory (160 files) is the largest and will be the slowest to change. The repo is alpha—expect moving APIs and rough edges.

The Bottom Line

The governance-first architecture is the right call: routing every tool call through a deciding, recording gateway is what makes an agent safe enough to give real access. The alpha status and the dependency on CopilotKit Intelligence (a commercial product) mean this is for teams that want to experiment now, not for production rollouts. If you need auditable, policy-controlled agent execution and can tolerate early-stage software, this is a solid foundation.