OpenBot 1.0: A Self-Hosted AI Coworker You Can Audit

Posted on by
Contents show
OpenBot

CopilotKit has released OpenBot 1.0, a modular, self-hostable workspace for AI coworkers that runs on infrastructure you own, and the pitch is aimed at the exact question that has stalled most enterprise AI pilots: nobody can say where the data went. OpenBot runs where your other internal systems run, its source is MIT-licensed and readable, and every governance question a security review will ask has an answer printed on the product page.

The design is compositional rather than monolithic. A Bot in OpenBot is a role with instructions, tools, and a conversation you can return to, and the models behind it are yours to choose from OpenAI, Anthropic, Google, xAI, or any OpenAI-compatible endpoint including local models in Ollama or vLLM. Engineering teams can skip the built-in agent entirely and connect agents they have already built with LangGraph, Google ADK, or the Claude Agent SDK through AG-UI, the interaction protocol CopilotKit authored and maintains.

That combination, self-hosted governance plus model and framework agnosticism, is what distinguishes OpenBot 1.0 from the assistant products it competes with, and this article walks through what it does, how the computer-use model works, what the governance layer enforces, and where it sits in the crowded agent-workspace market.

What a Bot actually is

The unit of work in OpenBot 1.0 is not a chat; it is a role, and the expense-review example from the launch illustrates the design.

A Bot is created for a job: check a travel claim against policy, show the relevant receipt line, flag anything needing human judgment. The creator chooses which tools it may use, which knowledge sources it can read, and which actions are off limits entirely, such as issuing a reimbursement. People talk to it by name, and its conversation persists so a claim can be picked up where it left off rather than reconstructed from a scrolling window.

Skills extend the model. A Skill is a reusable set of instructions, check the nightly room rate before tax and show each night separately, and OpenBot can propose Skills automatically from observed corrections through its learning feature, with a human reviewing what the Bot would learn before publishing it. Scheduled routines add ongoing responsibilities: a weekly check of outstanding claims that pings when something needs attention.

The personal edition runs in three clicks with no sign-in, and the same application scales to a team deployment, which is the composability claim in practice: the workspace a user learns on their desktop is the workspace IT deploys company-wide.

Computer use with a handoff

The computer-use model is the part of OpenBot that solves the problem most agent products leave dangling: what happens when the Bot hits a login.

OpenBot gives Bots access to a browser, files, and a shell, and the browser session opens beside the conversation so the work is visible while it happens rather than reported afterward. When a site demands a second authentication factor, the user takes control mid-task, signs in themselves, and hands the browser back without restarting the task or pasting a code into the thread.

The isolation model is per-agent rather than per-person. A Bot marked Isolated runs on its own computer, with its own files and its own signed-in browser, so a login one agent holds is not one the next agent can pick up. That boundary is drawn deliberately, because shared browser state across agents is the failure mode that turns a convenience feature into a security incident.

Multiple accounts per application are supported as well: several Gmail or Slack connections, a default designated, and the Bot using the one the request is about. It is a small feature that reflects the reality of people who live across multiple work accounts, and most agent products have not addressed it.

Governance that a security review can pass

The OpenBot governance layer is the launch's centerpiece, and its controls are specific enough to evaluate rather than aspirational.

Retrieval fails closed. Permissions from connected sources normalize to allow and deny principals, deny wins, and a document with an ambiguous mapping is not returned at all. An agent only ever sees files the person asking is already allowed to open, so sharing a Bot with a colleague does not leak the creator's access.

Tool calls are gated. Sensitive MCP calls pass through a gateway with an explicit per-tool allowlist, and every call and outcome is recorded. Boundaries define actions no Bot can ever take, checked before every attempted action. The audit trail records every action a Bot took or tried, who started it, and whether it was allowed, exportable as CSV.

Credentials stay local. Admins hold the provider keys, which are encrypted at rest with a customer key-encryption key, never returned by the API, never logged, and revocable. No bundled model silently serves requests: the built-in agent stays unavailable until an admin configures a provider, so nothing falls back to somebody else's LLM.

Enterprise controls complete the picture: single sign-on, SCIM user management, per-capability switches from browser use to Slack and Teams, and an admin view managing credentials, approvals, computers, plugins, and skills for every Bot in one place.

AG-UI, MCP, and A2A: the protocol stack

OpenBot's architecture is clearest when read as an answer to the agent-protocol fragmentation problem, and CopilotKit's framing of the three layers is the cleanest in the industry.

MCP is context: how an agent pulls in tools and external knowledge. A2A is coordination: how agents hand work to one another. AG-UI is interaction: how the work becomes something a person can watch, question, and interrupt, the leg the other two protocols do not cover. CopilotKit wrote AG-UI, released version 1.0 in September as a stable spec with a JSON schema, and ships the reference implementation.

The practical consequence is the no-vendor-lock claim, which is testable rather than rhetorical. Any agent that speaks AG-UI, from LangGraph, Mastra, PydanticAI, or a team's own framework, registers as an endpoint and gets a channel in OpenBot. The engineers who know the expense system maintain the expense agent; the finance team defines how reviews are conducted; changing the model does not move anyone's work to another application.

Tool connections follow the same openness: Notion and Google Drive as plugins, web search through Parallel, Exa, and Firecrawl, and hundreds of third-party apps through Composio and Arcade. The user chooses which connections a particular Bot may use, per Bot rather than globally.

For teams evaluating agent workspaces, this is the differentiator to verify: whether the product connects to the agents you already have or requires rebuilding them inside its own runtime.

From desktop to Kubernetes

The OpenBot deployment story spans personal and enterprise without changing the application, which is the other composability claim.

The desktop edition for Mac, Apple Silicon or Intel, and Windows is fully self-contained: the installer includes the app and its backend, no separate server required. Developers can run OpenBot from source or use Docker images and open the workspace in a browser. Teams on Slack or Microsoft Teams reach it through OpenTag, and mobile access is in early access.

OpenBot for Business is the supported production path: self-hostable on your own infrastructure inside your network, installable on Kubernetes with Helm on AWS, Azure, or Google Cloud, or available as an early-access hosted deployment for teams that would rather not operate it. The Business license includes CopilotKit Intelligence, and the annual plan adds SSO, SCIM, and an offline deployment option.

The subagent capability rounds out the workspace model: a Bot can split a large task across subagents, each inheriting the Bot's tools and rules, which is the orchestration pattern that keeps delegated work inside the same governance boundary rather than spawning ungoverned side processes.

Where OpenBot sits in the market

The agent-workspace market is crowded, and OpenBot 1.0 enters it with a distinct position, and OpenBot's position is best understood against the alternatives it was compared with at launch.

Against hosted assistants from the model providers, the trade is control versus convenience: hosted products deploy in minutes and own the updates, while OpenBot requires operations and returns ownership of data, permissions, and model choice. Against other open-source agent frameworks, the trade is completeness versus pieces: OpenBot ships the workspace, channels, knowledge, computer use, and governance as a product, while most frameworks provide the agent runtime and leave the application to be built.

The governance-first positioning is the sharpest differentiator, because the failure mode of enterprise AI pilots is rarely the model and usually the review: pilots stall when nobody can answer where documents went, which keys were used, and what the agent was permitted to do. OpenBot 1.0 is built to make those answers part of the product rather than part of the sales conversation.

The signals to watch are adoption in regulated industries, where the self-hosted audit story has the most value, and whether the AG-UI ecosystem grows fast enough to make the bring-your-own-agent path a real network effect rather than a specification.

For readers tracking the agent workspace and protocol landscape, the orchestration acquisition that validated the multi-agent pattern is examined in our Meta Conductor analysis, the workspace category's developer-side counterpart is covered in our Orca coding agents piece, and the tool-calling protocol layer beneath these products is unpacked in our Droid 1.0 analysis.

The OpenBot knowledge layer, examined

The document-grounded answers in OpenBot deserve their own examination, because enterprise knowledge is where most assistant deployments earn or lose trust.

Connections to Google Drive and OneDrive let Bots answer from what the company already wrote down, and every answer names the documents behind it so the reader can verify rather than trust. The citation model is the difference between an assistant that asserts and one that shows its sources, and it is what makes the expense-review example auditable after the fact rather than only during it.

The fail-closed permission model deserves repetition because it is unusual. Permissions from connected sources normalize into allow and deny principals, deny wins conflicts, and any document whose mapping is ambiguous is excluded from retrieval entirely. Most retrieval systems resolve ambiguity toward inclusion, which is precisely how over-sharing incidents happen; OpenBot resolves toward exclusion and accepts the cost of missing a document over the cost of leaking one.

Sharing semantics follow the same principle. Sharing a Bot with a colleague does not transfer the creator's account connections, and each person's queries are evaluated against their own permissions, so the Bot is a lens onto existing access rather than a new grant.

For organizations comparing knowledge assistants, the question to ask any vendor is what happens when permissions are unclear. OpenBot's answer, return nothing, is the one a security review wants to hear, and it is rare enough to be a differentiator on its own.

The OpenBot interfaces story: OpenDuet and the workspace family

The same OpenBot application ships behind multiple interfaces, and that separation of workspace from frontend is an architectural decision worth understanding.

OpenDuet, OpenDots, and OpenMuse are different interfaces for the same OpenBot backend, so an organization can change how people experience their Bots without rebuilding agent logic. OpenDuet, the proactive-coworker template built on Google's A2UI 1.0 specification, demonstrates the pattern: an open-source frontend that any AG-UI-speaking agent can appear in.

The separation mirrors what the industry learned from the chat-to-agent transition. The agent runtime, the governance layer, and the user experience evolve on different schedules, and coupling them means every frontend change touches governance. OpenBot's split keeps the audit trail, permissions, and tool gating stable while the surfaces people use change freely.

For buyers, the practical question is which interface their workforce will actually adopt, and the multi-frontend answer means that decision is reversible, which is rare in enterprise software and worth weighting in an evaluation.

The OpenBot teach-a-Bot workflow

Among the 1.0 features, the recording workflow is the one that changes who can build automations, and it deserves a concrete description.

Hit Record, perform a task once in the browser, and the Bot learns it: the recording captures the navigation, the forms, and the steps, and turns them into a repeatable procedure the Bot can execute afterward. For the kind of routine web work that fills operational teams' days, checking a portal, pulling a report, updating a record, the recording removes the prompt-engineering barrier entirely, because the person who knows the task demonstrates it rather than describing it.

Combined with Skills, the learning loop composes: a recorded procedure becomes a Skill, the Skill is shared across the team, and corrections made in real reviews feed proposed improvements that a human approves before publication. The governance boundary holds through the loop, because learned Skills run under the same tool allowlists and audit trail as everything else.

Check-ins extend the model to monitoring: a Bot watching something that changes, an inbox, a shared document, a claim queue, pings the user when attention is needed rather than requiring a scheduled interrogation. For operational teams, that converts the assistant from something you remember to use into something that surfaces work.

The pattern across all three features is the same philosophy in miniature: automation that a domain expert can build, review, and bound without engineering involvement, inside the same governance envelope the security team approved.

A practical evaluation checklist

For teams considering OpenBot 1.0, the features worth testing first are the governance controls, are the ones that determine whether the model of governed delegation fits the organization, and a short checklist covers them.

Start with a task someone on the team knows well enough to review, as the launch guidance suggests, because a Bot built on work the evaluator understands produces an honest assessment of output quality. Give the first Bot only the tools it needs, work a real example end to end, and note where the handoffs, the mid-task interventions, actually occur.

Second, test the permission boundary deliberately: connect a document source, restrict a folder the test user cannot access, and confirm the Bot returns nothing rather than guessing. The fail-closed claim is the product's most important security property, and it is verifiable in minutes.

Third, exercise the audit trail end to end: run a Bot through a task with an approval gate, export the CSV, and read what it recorded. The audit is only as valuable as its usability, and reading a real export is the fastest way to know whether the security team will accept it.

Fourth, connect an existing agent through AG-UI if the engineering team has one, because the bring-your-own path is the architectural difference from the hosted assistants, and its smoothness in practice determines whether OpenBot composes with the organization or competes with it.

Teams that work through those four tests will know whether OpenBot fits in an afternoon, which is a reasonable evaluation cost for a product asking to sit inside the network.

Questions readers are asking

Is OpenBot free?

The application source is MIT-licensed and the desktop edition is free to download, with users bringing their own model credentials. OpenBot for Business, with hosted options, CopilotKit Intelligence, SSO, SCIM, and offline deployment, is a paid annual plan.

Can I use my own model?

Yes. OpenAI, Anthropic, Google, xAI, any OpenAI-compatible endpoint, and local models through Ollama or vLLM, with admins holding the credentials and nothing falling back to a bundled provider.

Does it replace my existing agents?

No. Agents built with LangGraph, Google ADK, the Claude Agent SDK, or any AG-UI-compatible framework connect as endpoints and get their own channels, which is the composable alternative to rebuilding inside a new runtime.

What stops a Bot from doing something dangerous?

Layered controls: per-Bot tool allowlists through an MCP gateway, approval requirements for specific actions, a boundaries list checked before every action, fail-closed retrieval permissions, and a full CSV-exportable audit trail.

Sources
[fluentform id="2"]