Claude, Codex and Grok already have different jobs in our work. The harder question is what happens between them.

When one agent hands a task to another, what goes with it? The files? The reasons behind a decision? Access to the same accounts?

We organize agents in specialist groups, including a small group for video, while shared groups connect different levels of the work. I keep some of that implementation private, but the questions it raises are worth discussing openly.

That is what drew my attention to @OpenBot_: the possibility of keeping a team together even when the models change.

This article is based on OpenBot's documentation and release notes, checked on 29 September 2026. I am reading them through the questions we face in our own work.

The timing matters. Between 26 and 28 September, OpenBot moved from version 0.22.0 to version 0.24.0. The latest release added agent access and auto-approve controls on mobile, while version 0.22.0 had begun enforcing a Workspace only mode for supported providers. This is a project moving quickly enough that any serious review needs a date.

The model is only one member of the team

OpenBot describes itself as a local-first desktop workspace for persistent AI teammates. It currently supports Codex, Claude Code, Grok CLI, OpenCode, Gemini and custom providers.

Its own guide makes a useful distinction. A model generates a response. A provider runtime connects that model to OpenBot. An agent keeps the role, instructions, workspace, conversation, queue and context around the work.

That separation allows an agent to move from one provider to another while keeping its files and conversation in place.

Choosing the model is still important, but the choice changes with the task and with every new release. A useful team should survive those changes. The role, memory and responsibility can remain stable while the underlying model changes.

OpenBot already adds several pieces around that idea: separate agent workspaces, persistent conversations, queues, file transfers, an embedded browser, direct messages between agents and shared channels with explicit delegation.

The migration path from Grok Bot makes the intention even clearer. OpenBot can import an agent's name, instructions, avatar, skills, routines, memories and optional workspace files from a local export. Chat history is not copied, and the file stays on the user's computer.

With those pieces together, I can finally picture an AI team living somewhere more coherent than a row of chat windows.

Why this matters once the work becomes real

A single assistant can help with a single request. Longer work creates a different set of problems.

Someone has to know which agent owns the next step. A reviewer needs enough evidence to check what happened. A failed task needs a state that another agent can recover. The system must decide which context should travel, which files should stay private and which actions still belong to a person.

Consider a draft moving from research to writing to review. The reviewer needs the sources and the decisions behind the draft. That does not mean it needs the publishing account. I want the system to preserve the first distinction and enforce the second.

The technology is impressive, but I care about the attention it can return to people. If the system handles memory and routine coordination well, the team can spend more time on judgment, craft, relationships and the work that still needs a human voice.

OpenBot's local-first approach is attractive for the same reason. The workspaces, conversations, queues and attachments live on the host computer, while the selected provider still receives the material required to run the model. Local-first is not the same as offline. The guide explicitly distinguishes local state from provider and browser network traffic.

Five questions I would ask before moving real operations into it

These are the questions that would help me decide which parts of a real workflow OpenBot can safely own.

How far will Workspace only go?

OpenBot 0.22.0 began enforcing Workspace only for writes. An agent in that mode can write inside its own workspace, the shared folder and temporary folders. Full access remains the default, and the changelog notes that Grok, OpenCode and Gemini agents on Windows and Linux currently need Full access to start.

The release notes describe new write restrictions, while the privacy document still contains a broader description of agent access. A current provider-by-platform permissions table would make the boundary easier to evaluate.

I would now like to understand the next boundary. Can Workspace only eventually restrict reads as well as writes? Can network access, another agent's workspace and the shared agent database be governed separately? Will every provider reach the same level of enforcement across macOS, Windows and Linux?

For teams working with customer data or proprietary material, write isolation is one part of the answer. Read isolation matters too.

How granular can each agent's tools and data become?

OpenBot already manages MCP servers and skills around individual agents, and the latest release keeps sensitive changes such as Full access, Computer Use, auto-approve and MCP configuration under human control.

Could I give an analytics agent read access to one account, and a publishing agent permission to save drafts but no permission to publish? Where would OpenBot enforce those limits, and where would it depend on the connected service?

That distinction would tell me how much of an agent's role is enforced by software and how much still depends on instructions.

Can browser identity belong to the agent?

OpenBot gives agents a persistent embedded browser, and its privacy documentation says that agents currently share the embedded browser profile, including cookies and website sessions.

A persistent browser is powerful. A shared profile also creates a shared credential surface.

Could a future OpenBot agent have its own named browser profile, with only the sessions required for its role? One agent could be signed into an analytics account, another into a publishing tool, and a third into nothing at all.

The clean mental model would be one role, one toolset, one browser identity and one permission boundary.

Can approval become policy instead of a single switch?

OpenBot already supports standing approval for an agent, Turbo mode for local agents, Workspace only, per-agent Computer Use and new access controls on mobile. The speed of that progress is encouraging.

Real operations still need different rules for different actions.

Reading a report may run automatically. Sending an email may need approval. Publishing, spending money or changing customer data should have a stronger gate. Destructive actions should be difficult to approve by accident.

Can OpenBot move toward policies based on the action, destination and risk, while preserving a clear history of who approved what?

What is the commercial path?

The current repository uses the PolyForm Noncommercial License 1.0.0. Versions through 0.1.11 remain under Apache 2.0, while commercial use of the current code requires a separate license from the copyright owner.

That is a legitimate choice, and the licensing boundary is documented in the repository.

For a small company evaluating OpenBot as infrastructure, it would help to know the intended path. Will there be a commercial license for small teams? Hosted and self-hosted options? Support for companies that want to build internal workflows without redistributing the product?

The sooner that path is visible, the easier it becomes to evaluate OpenBot beyond experimentation.

The opportunity I see

The opportunity I see for OpenBot is to become a dependable place where different models can work together without erasing the identity, memory and boundaries of the agents around them.

The project is still a development preview, and some of the controls above are new or incomplete. That is exactly why I appreciate the clarity of the documentation and the pace visible in the changelog. The team is publishing both the progress and the limits.

I also love the personality of the product. The small agents, shared rooms and visible handoffs make the system feel approachable without hiding the seriousness of what it can do.

Thank you to @norbertbodziony and everyone building @OpenBot_. There is one last practical question I would most like to explore with you: what is the smallest workflow a team could trust OpenBot with today, and which boundaries would you recommend setting around it?

For us, the first test would be whether agents can share the work without automatically sharing every permission.