OpenBot Review: What Self-Hosted AI Coworkers Really Require

An AI coworker needs more than a browser and a job title

OpenBot is an MIT-licensed template from CopilotKit for running AI coworkers on infrastructure you control. It combines an agent interface, browser computers, files, shell access and MCP integrations with a server-side policy and audit gateway. You supply the model and operate the deployment.

That makes it interesting for teams that need more control than a packaged assistant offers. It does not make it a turnkey, fully offline or automatically secure replacement for Grok Bot. The current OpenBot README explicitly calls it an alpha template, not a finished product somebody else operates for you.

Our recommendation: evaluate OpenBot for a narrow, supervised business workflow when configurable permissions and deployment ownership are requirements. Do not choose it just because the source code is free.

Review method: documentation-based assessment of OpenBot commit 1c7bd923fd1ec14ef15f7d6ab6e33ad73c72f2a4, checked on 10 September 2026. We did not deploy or penetration-test OpenBot. Examples and pilot criteria below are our proposed evaluation approach, not measured product results.

What does OpenBot provide?

The example package defines General Assistant for everyday work, Knowledge for company questions and Risk Analyst for risk-related work. These are configurable roles, not three independently validated specialists. A Risk Analyst label does not establish compliance expertise or authorize decisions.

A coworker can use a browser with retained logins, work with files and call granted tools. Google Drive and Notion appear in the current MCP catalogue. The platform accepts agents that speak AG-UI, so you can connect a supported framework or your own compatible endpoint rather than treating OpenBot as a language model.

Creating a name, role and instructions in the interface is the easy part. Model access, endpoint configuration, permissions, data sources and acceptance tests still need an owner. The current deployment documentation also distinguishes which example agents are available when the managed agent endpoint is absent.

The important design: policy, audit, then execution

The OpenBot architecture documentation places the action boundary on the server, not in the model's instructions. For routed computer actions, the gateway resolves the target, evaluates policy, writes the decision to the audit trail and only forwards a permitted action. Execution failures receive a further record.

Agent request → resolve target → evaluate policy → record decision → execute or refuse

This is stronger than telling a model to “be careful.” A reviewer can inspect which rule permitted or refused an action, rather than interpreting an assistant's explanation after something changed.

However, a recorded permission decision is not proof that the business result was correct. Nor does a gateway record make an external write atomic, undoable or safe to retry. A supplier record created twice is still a problem even when both requests have audit entries. Those workflow properties require separate design.

The boundary also applies to actions routed through the platform. It should not be interpreted as a guarantee that arbitrary code or a separately operated agent endpoint can never act outside that route.

Does OpenBot deny everything by default?

The evaluator fails closed, but the shipped startup policy is permissive. These are different facts.

The architecture documentation states that a missing or empty policy permits nothing, denies take precedence over allows, a broken deny expression denies, and a broken allow expression does not grant permission. It also states that startup supplies an explicit policy with deny: [] and allow: ["true"] unless an environment or saved administrator policy replaces it.

Consequently, “missing policy permits nothing” does not mean a fresh installation has a restrictive business policy. Before connecting company accounts, replace the permissive startup policy with a reviewed set of allowed actions and verify both permitted and refused outcomes.

OpenBot uses Common Expression Language (CEL) for policy expressions. CEL is an embedded expression language, not a prompt to another model. Its usefulness here is making rules inspectable and testable against the action context. Policy quality still depends on the fields supplied by the application and the rules your team writes.

For the broader distinction between tool connectivity and authorization, see why MCP is not the security boundary.

Is every AI coworker isolated?

Per-coworker isolation depends on the deployment topology. With the supervisor configured, each Bot receives a separate computer container, workspace volume and Chromium profile. Without it, Bots can share the configured computer.

This matters because the current OpenBot deployment guide also offers a single-container image that does not include the supervisor. In that path, Bots share a browser, files and logins. The guide explicitly warns against treating that shared setup as a boundary between tenants.

Before approving a deployment, ask which architecture actually runs, not whether the README mentions containers. A separate Bot name is not a separate security boundary. A separate container also does not automatically restrict the network destinations or external accounts available inside it.

The model is different from Ramp Inspect's disposable environment per coding session. OpenBot's persistent coworker profiles and workspaces need their own retention, reset and account-revocation procedures. For a sandbox runtime rather than a complete coworker application, compare the OpenSandbox execution platform.

What happens at login or two-factor authentication?

OpenBot documents a human handover in the same browser panel. The person takes control to complete a login or another step requiring attention, then hands control back. While human control is active, the Bot's browser actions are refused rather than queued for later execution.

That is a useful interaction rule. It avoids accumulating Bot actions while a person is changing the page or entering credentials. It is not blanket approval for whatever the Bot does after control returns.

The dedicated secret-entry flow is separate from chat, and its audit events record metadata rather than the secret value. Still treat browser profiles, authenticated sessions, screenshots and tool outputs as sensitive. Protecting the password-entry path does not make every later observation harmless.

For a pilot, use a task-scoped account and confirm that logging out or revoking access has the intended effect. Completing 2FA proves that a person authenticated. It does not grant the coworker authority to send messages, accept terms or approve purchases.

Is OpenBot fully self-hosted or fully local?

You can host OpenBot, but you must account for the rest of its data path. The current configuration reference requires CopilotKit Intelligence connection settings. It also supports compatible model endpoints, which may be a provider API, a gateway or infrastructure you operate.

A local model changes the inference row. It does not, by itself, move conversation persistence or connected business tools onto your machine.

The current managed Intelligence setup uses the project runtime key without a separate licence token. A self-hosted Intelligence installation may require its own entitlement configuration. Follow the pinned documentation rather than an older tutorial's setup commands.

What does OpenBot cost beyond model tokens?

The MIT licence covers OpenBot's code. Your budget also needs compute, PostgreSQL, storage, backups, model usage, the chosen Intelligence arrangement, connector maintenance and the people operating it.

As of 10 September 2026, CopilotKit pricing lists the free Developer tier at one developer, 200 threads and three-day retention. Its VPC/on-prem entitlement is runtime only. Confirm persistence and self-hosting terms; free does not mean unlimited or entirely local.

A useful planning measure is:

Cost per accepted task = (model + hosting + persistence + operations + review + rework) ÷ accepted tasks

Keep the denominator tied to an agreed outcome. A low token bill is not a saving when staff have to repeat the task or reconstruct missing evidence. No public benchmark reviewed here establishes OpenBot's cost advantage for your workload.

OpenBot vs Grok Bot: ownership, not assumed feature parity

Calling OpenBot a Grok Bot alternative describes a buying choice, not verified equivalence. Grok Bot's official team documentation describes managed cloud computers, per-user Firecracker isolation, shared compute among a user's Bots and approval controls. Administrative capabilities vary by plan.

Neither architecture is automatically safer or cheaper. For a standard workflow, buying a maintained product can be the better decision. The custom software versus off-the-shelf guide explains when ownership earns its ongoing cost.

A practical OpenBot pilot for a business team

Start with a document-preparation task, not payments or production administration. An illustrative workflow is a supplier onboarding brief: retrieve permitted documents, identify missing evidence and produce a draft for a person to approve. The coworker must not activate a supplier, send the brief externally or approve an invoice.

The control model should follow OWASP's guidance on excessive agency: minimize functionality, permissions and autonomy; enforce authority in the systems being used; require approval for high-impact actions.

Days 1–3: define the boundary. Pick an owner, one workflow, a frozen task set and the expected outputs. Use synthetic or approved test documents. Record the exact OpenBot revision, model and deployment topology. Replace the permissive policy and configure authentication before other users can reach the service.

Days 4–7: verify control behavior. Confirm legitimate reads succeed and prohibited writes are refused. Verify the deployment stops rather than acts without its required audit record. Exercise human browser takeover and release. Check separation between coworker workspaces and accounts in the topology you selected.

Days 8–10: verify operations. Restart the deployment, recover its audit store, inspect what conversation retention actually preserves and revoke a connected account. Test a failed tool call and a repeated request without allowing duplicate business changes. Record recovery behavior instead of accepting a green container health check as proof.

Days 11–14: compare accepted outcomes. Measure completion rate, reviewer time, corrections, model spend and operating effort against the current process. Expand only when quality holds, permissions behave as designed and the total effort improves. Otherwise narrow the job, use a deterministic integration or buy a managed tool.

When should you choose OpenBot?

Choose a controlled pilot when you have an engineering owner, a concrete workflow and a reason to customize deployment, agents or action policy. Defer it when the main requirement is a supported assistant with minimal maintenance, or when nobody can own authentication, permissions and recovery.

Wavect's AI consulting helps define that decision before a platform build. A useful first deliverable is a data-flow map, a permissions matrix, a representative task set and a go/no-go recommendation. The Twinsoft AI case study provides context for our work around making AI applications maintainable and ready for real use; it is not an OpenBot deployment claim.

Discuss an OpenBot feasibility pilot around one workflow and its acceptance criteria, rather than starting with a company-wide rollout.

The opportunity is not simply to give AI coworkers more access. It is to make the access you grant explicit, observable and worth the operating cost. OpenBot provides a starting point for that work, not a substitute for it.