Who OpenBot is for#
Security teams running agents near internal systems
Agents that need to pull data from back-office tools, query internal databases, or act on intranet applications can do so without exposing those systems to an external cloud. The audit trail shows exactly what each agent accessed, requested, and was refused, which simplifies compliance reporting.
Skip if:
Your internal systems already expose clean APIs and you do not need browser automation. If agents only call APIs, OpenBot's browser container overhead adds cost without benefit.
Teams building role-specific internal agents
OpenBot lets you publish named agents with specific roles: a knowledge agent that answers from company documents, a warehouse analyst that queries your analytics database, a tool operator that signs into apps with no API. Each agent is granted only the sources and skills its role requires.
Skip if:
You need a production-ready, fully-managed agent platform today. The alpha status and self-hosting burden make it a poor fit for teams without engineering resources to operate and upgrade the stack.
Developers integrating AG-UI agents into a governed host
If your team has built agents on LangGraph, Mastra, or PydanticAI and wants to give them a governed, observable interface that users can interact with in real time, OpenBot provides the channel model, the screen-sharing panel, and the policy gateway without requiring you to rewrite the agents.
Skip if:
Your agents do not need real-time user interaction or audit governance. A simpler queue-and-callback architecture is lighter weight if observability is not the goal.
The problem it solves#
Running AI agents on cloud platforms means trusting a third party with your company's most sensitive data: employee logins, internal documents, back-office records, and the credentials the agent uses to act on your behalf. Most hosted agent tools share infrastructure across tenants, give you no audit trail of what the agent actually did, and require you to grant access to your internal systems from an external service you do not control.
The second layer of the problem is governance. When an agent can open a browser, sign in, and take actions on a web interface, the difference between an agent doing what you asked and an agent doing something you did not intend is invisible without a record that precedes each action. Debugging after the fact is not governance; deciding before the action is.
How it solves it#
Per-Bot isolated computer
Each agent runs in its own container with its own browser profile, login sessions, and file workspace. The supervisor provisions one container per Bot, so credentials and browsing state never cross between agents. Set COMPUTER_RUNTIME=runsc to run containers under gVisor on supported hosts.
Gateway-gated tool execution
Every browser action, file operation, shell command, and MCP call goes through a central gateway that evaluates a CEL policy, writes an audit row, and only then acts. Deny is evaluated before allow. A missing policy permits nothing. A broken rule refuses rather than opens. There is no path that acts without the audit record existing first.
Watch and take the wheel
The agent's screen opens beside the conversation so you can see what it is doing in real time. If it hits a login wall or a 2FA prompt, it asks for help, and you take over in the same panel. Control transfers are recorded as audit events. While you are driving, the agent's own actions are refused rather than queued.
Bring your own AG-UI agent
Any endpoint that speaks the AG-UI protocol registers as a Bot, regardless of framework. Agents built with LangGraph, Mastra, CrewAI, PydanticAI, or written by hand all arrive the same way. Governance runs at the protocol level, not the framework level.
Company knowledge with fail-closed permissions
Connect Google Drive and OneDrive and agents answer from your company's documents, with sources cited. Permissions are normalized to allow and deny principals: deny wins, and a document with an ambiguous permission mapping is not returned at all rather than guessed at.
CEL policy and full audit trail
Admins configure action policy as CEL expressions that inspect tool name, intent, bot ID, actor ID, page URL, element attributes, file path, and MCP metadata. The audit log at /admin/audit lists every permitted, refused, and failed action, with the rule that caused each refusal.
Strengths and trade-offs#
Strengths
- Data stays in your Postgres, not a third-party cloudDocuments, vectors, permissions, and conversation threads all live in your PostgreSQL database. Model credentials are encrypted at rest with your key-encryption key, never returned by an API, and revocable without touching the codebase. Nothing is sent anywhere you did not configure.
- MIT license with no commercial restrictionsThe repository is MIT licensed, so you can run it commercially, fork it, modify it, and build proprietary products on top of it without any licensing fee or notification requirement. The only dependency with separate license terms is the CopilotKit Intelligence runtime, which has a free tier and a self-hosted option.
- Framework-agnostic agent compatibilityThe AG-UI protocol decouples agent logic from the host application. Teams already running LangGraph, Mastra, PydanticAI, or custom agents can register them as Bots without rewriting. The governance layer rides the protocol, so any agent inherits audit and policy enforcement automatically.
- Human oversight without losing the threadPausing a Bot mid-task does not break the conversation. Taking the wheel, completing a step the Bot should not do alone, and handing back all happen in the same channel panel. The full control sequence is recorded, so a reviewer can see exactly what happened and when.
Trade-offs
- -Alpha status with active breaking changesThe README badges the project as alpha and notes that rough edges and bugs are expected. The repository was created in August 2026 and last pushed in September 2026, making the codebase under two months old. Teams adopting it in production should expect API changes and incomplete documentation.
- -CopilotKit Intelligence is a required dependencyThe API server refuses to start without a CopilotKit Intelligence project key (INTELLIGENCE_API_KEY). A free plan is available and Intelligence can be self-hosted, but this is an additional service that a team must provision and maintain. There is no path to run OpenBot without it.
- -Per-Bot containers increase resource requirementsEach active agent runs in its own container with its own browser instance. This adds meaningful memory and CPU overhead compared to shared-browser agent setups. Teams expecting to run many concurrent agents will need to size servers accordingly; the deployment docs note minimum sizes.
OpenBot vs alternatives#
OpenBot vs Grok Bot
Grok Bot is a proprietary service from xAI where named bots share a cloud computer and act on your logins. OpenBot is the self-hosted, open source path: each agent gets its own isolated container, your data stays in your Postgres, and every action goes through an audit gateway before it executes.
| Feature | OpenBot | Grok Bot |
|---|---|---|
| License | MIT | Proprietary |
| Infrastructure | Your servers | xAI cloud |
| Data residency | Your Postgres | xAI cloud |
| Audit log | Full, pre-execution | Not user-accessible |
| Agent isolation | Per-Bot container | Shared cloud environment |
| Agent frameworks | Any AG-UI endpoint | Grok Bot native only |
OpenBot is the better fit when your agents need to touch internal systems (back-office tools, internal databases, company documents) and you cannot route that traffic through a third-party cloud. The pre-execution audit trail and CEL policy engine give a compliance team something to review that Grok Bot does not expose. The tradeoff is that you manage the infrastructure; Grok Bot's managed service means zero ops overhead.
Grok Bot is the better choice for teams that want a fully managed, zero-infrastructure agent service and do not have data residency requirements that would rule out the xAI cloud. If your agents only interact with public or low-sensitivity data, the managed convenience is a real advantage.
OpenBot vs Relevance AI
Relevance AI is a no-code agent builder on proprietary cloud infrastructure. OpenBot is code-first, MIT licensed, and runs entirely on your own servers.
| Feature | OpenBot | Relevance AI |
|---|---|---|
| License | MIT | Proprietary |
| Infrastructure | Self-hosted | Managed cloud |
| No-code setup | No | Yes |
| Custom agent frameworks | Any AG-UI endpoint | Relevance AI native |
| Data residency | Your environment | Relevance AI cloud |
Relevance AI is the better choice for non-technical teams that need to build and deploy agents without writing code, and do not have a data residency requirement that rules out a managed SaaS. OpenBot requires engineering resources to set up and maintain but gives you complete ownership of the agent environment.
Install and self-host#
Self-hosting OpenBot uses Docker and Bun for the setup process.
```bash
git clone https://github.com/CopilotKit/OpenBot
cd OpenBot
cp .env.example .env
npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun install
bash scripts/start.sh
```What it's built on#
- Languages
- TypeScript
FAQ#
Is OpenBot free to use?
Yes. The repository is MIT licensed and free to self-host. You need a CopilotKit Intelligence project key (a free plan is available) and a model API key from OpenAI, Anthropic, or Google. There is no hosted version to sign up for; you clone the repository and run it on your own infrastructure.
How is OpenBot different from a chat assistant?
OpenBot agents do multi-step work in their own isolated environment: signing into web interfaces, running shell commands, reading company files, and calling external tools. A chat assistant generates text in response to a prompt. OpenBot agents take actions and are governed by a policy gateway that logs every action before it happens.
Can an agent access files or systems I cannot see?
No. Permissions from connected sources (Google Drive, OneDrive) are normalized to allow/deny principals, and deny wins. A document with an ambiguous permission mapping is not returned. The agent only ever sees files the person asking it is already allowed to open.
Do I need to rewrite my existing agents to use OpenBot?
No. Any agent that speaks the AG-UI protocol can register as a Bot, regardless of the framework it was built on. LangGraph, Mastra, PydanticAI, CrewAI, and hand-written AG-UI endpoints all work. You provide the endpoint URL and an optional auth header; the governance layer applies automatically.
Is OpenBot ready for production use?
The README labels it alpha and notes that rough edges and breaking changes are expected. The project was created in August 2026 and is under active development. Teams considering it for production should review the current deployment docs, accept the maintenance burden of a fast-moving codebase, and have engineering resources to handle upgrades.
Similar open-source tools#
OpenCompany
Self-hosted AI agent canvas for every business function
OpenClaw
Self-hosted AI assistant for WhatsApp, Telegram, and more
headlong
Bash microharness for agents that think continuously
OpenMausBot
Your AI agent team in a chat app, local-first and MIT licensed
rakazo
AI teammates you own: your keys, your model, your machine.
Hermes Agent
Self-hosted AI agent with persistent memory, multi-channel chat, and model choice across OpenAI, OpenRouter, and custom endpoints.