OpenBot, the CopilotKit release from August 19, 2026, raises a question most agent tools avoid: if an AI bot makes a mistake or gets compromised, what is the actual blast radius?
OpenBot's answer is architectural and explicit. Every bot gets its own computer, with its own browser, its own sessions, and its own files, separated from the others. One bot cannot read another bot's files or reuse its sessions. Grok Bot from xAI takes the opposite design. Its official FAQ says that every Grok Bot shares one persistent cloud computer, and that isolation is per user, not per Grok Bot. These are not interchangeable choices. They are different design decisions with different consequences for who pays when something goes wrong.
This article does not repeat what OpenBot is or how to install it. That is already covered in what is CopilotKit OpenBot, where we walk through the architecture, the step-by-step setup, the AG-UI protocol, and the broader comparison with alternatives. Here the focus is narrower: why isolation matters in a company, how you decide what each bot can do, and what kind of records let you prove it if an auditor asks.
Why does isolation matter for an AI agent when you already have passwords and permissions?
People who are learning to code tend to think about security as a wall: a login, a firewall, a strong password. With AI agents, the reality is messier, because an agent is not just a user account you log in and out of. It is a process that can act on your behalf, with your credentials or with access to your tools, and it can be running while you are not watching.
Imagine a company that creates three bots: one for answering internal knowledge questions, one for reviewing sales metrics, and one for ingesting documents from a public form. If all three share the same browser, the same sessions, and the same files, a vulnerability, a malicious prompt, or an unexpected behavior in the ingestion bot can move the context around or read what the knowledge bot had stored. Not because of a shared account handled badly, but because there is a shared resource that none of the bots could isolate from the rest.
Isolation is not only a defense against outside attacks. It is also a matter of internal accountability. When something goes wrong, you want to know which bot did it, in what context, with what permissions, and at what point in time. If the bots share state, that question gets much harder to answer, because the trail gets mixed together.
That is why OpenBot's design points straight at this: isolate each bot in its own computer, with its own browser, its own sessions, and its own files. According to the author, Atai Barkai, in the launch thread on August 19, 2026, each Bot has its own computer, with separate browser, sessions, and files, and one Bot cannot read another Bot's files or reuse its sessions. That sentence matters because it is a design choice, not a marketing upgrade layered on top of an existing architecture.
What is the real difference between isolation per bot and isolation per user?
This is where the comparison becomes useful, but you also have to be careful not to turn it into a turf war.
OpenBot isolates per bot. Each bot has its own execution environment. If one bot is compromised or behaves badly, the blast radius is limited to whatever that bot was allowed to touch inside its own computer. There is no shared computer where a single failure can spill over onto all the bots.
Grok Bot takes a different design. Its official FAQ says that every Grok Bot shares one persistent cloud computer, and that the isolation is per user, not per Grok Bot. In other words, in Grok Bot's model, the blast radius of a compromised bot can be the entire account, because there is a shared resource above the bot level. That does not mean Grok Bot is insecure by definition, and it does not mean OpenBot is automatically safer. They are different models with different tradeoffs.
OpenBot's tradeoff is more granularity and more traceability, but also more operational complexity. Grok Bot's tradeoff is fewer boundaries between bots, which can simplify some things, but it changes the security question. You are no longer asking what one specific bot can do inside its own computer. You are asking what a bot can do inside an account where the other bots also live.
For a company, the question is not which one looks cleaner on paper. It is which one fits your accountability model. If you have different teams, different data, and you want a problem in one workflow to be unable to spread because of a shared resource, isolation per bot is the abstraction that fits better. If your case is closer to one user who has several bots as extensions of themselves, with no sensitive cross-data between them, the shared model can make sense.
The point that is worth being clear about is this: per-user isolation is not the same as per-bot isolation. And if an auditor, a customer, or a regulation asks you where the boundary is when a bot fails, your architecture's answer matters.
What does it mean to govern an agent in a company, beyond whether it can or cannot do something?
When people talk about agent governance, the discussion sometimes stays stuck in generic checklists of controls. In practice, governing an agent in a company usually means being able to answer three questions when something needs justification: what happened, who decided or allowed it, and why.
OpenBot records not only what happened, but who made the decision and why. That is a meaningful difference from systems that only leave a log of actions or model outputs. In a company setting, that is not a small detail. It is what lets you separate an operational mistake from an authorized action, and what lets you defend a decision to someone who was not in the room when it was made.
Think of a concrete and realistic scenario: a risk analysis bot is configured to query an internal data source and posts a summary to a team channel. Later, someone asks why a certain number showed up in the summary, or why one source was queried and not another. A generic log is not enough. You need to know which rule the gateway applied, which human or automated actor authorized it, and at what point. That is what lets you move from "the bot said this" to "this was allowed under these conditions, for this reason, at this time."
That governance layer is especially relevant when agents are not limited to answering questions, but can act on real systems: browsing, filling forms, using tools, touching data. Once an agent has action capacity, the audit question changes from "what did it say" to "what did it do and why was it allowed."
How does isolation actually work in practice with OpenBot?
In OpenBot's design, isolation is not an add-on bolted on at the end. It is part of how each bot lives. Each Bot has its own computer, with a separate browser, sessions, and files. That means the boundaries are explicit from startup, not a permissions layer applied afterward.
There is a real difference between saying "we have well-managed permissions" and saying "this bot does not share any execution resource with that other bot." Permissions can be correct, and still a failure at a shared level can leak context or contaminate sessions. Isolation by separate computer is stricter because it reduces the shared surface before you even get to permissions.
That does not mean OpenBot eliminates every problem. It means the highest-level boundary is drawn so that one bot does not read another bot's files and does not reuse its sessions. The rest, like permissions over tools, the data sources it can reach, and the actions it can execute, is still something the person who configures the system manages.
One detail that can be easy to miss and that actually matters in companies: threads are tied to the person, not to the browser. And new data replaces old data instead of just accumulating. That is different from a model where everything just keeps stacking without any expiration management. In a workspace setting, that choice affects both privacy and the consistency of the context the agent sees.
What have others said about the limits of this model?
Not everyone agrees that OpenBot's current isolation is enough. Tobi Lütke, CEO of Shopify, replied to the launch thread saying it is missing bash and a package manager, and suggested gVisor as a sandbox.
That critique is real, and it deserves to be told as it is, without praise or apology. gVisor is a container sandbox that adds an extra layer of isolation between the process and the host kernel. If you want a stricter execution boundary, gVisor enters the picture. Lütke's suggestion points to a legitimate point: even when a design isolates per bot, some people want one more layer of containment underneath, especially in environments where the trust level is not high.
There is no point hiding that criticism or presenting it as something minor. If you are evaluating OpenBot for a real team, it is worth keeping in mind that other players in the space are calling out concrete limits, not just praising the concept. At the same time, there is no reason to overstate it either. This is an alpha project, and technical critiques about what is missing or what extra layer is worth adding are a normal part of how systems like this mature.
What frameworks can OpenBot use, and why does that matter in a company?
OpenBot works with any agent that speaks AG-UI: Google ADK, AWS Strands, Microsoft Agent Framework, LangChain, CrewAI, Mastra, Pydantic AI, and Claude Agent SDK. It runs on top of the Channels SDK, which is the newly published layer that lets those agents arrive as coworkers with their own channel.
This matters in a company because you are not forced to buy a new agent just to enter a workspace model. If you already have agents built with any of those options, you can add them without changing the underlying harness and give them identity, a channel, and the boundaries OpenBot handles. For teams that have already invested in building agents with LangChain, CrewAI, or any of those options, that can be the difference between a project that stays a demo and one that reaches a real workflow.
The other side of the coin is that governance and isolation are applied on the protocol layer, not on one specific agent technology. That can simplify life when you want to keep control without being tied to one particular framework. But it also means that if you want to make use of this in a real team, you need to understand what AG-UI is, what the Channels SDK is, and how your current agent fits into that layer.
Who is this design good for, and who is it not good for?
OpenBot's design makes sense for a company that needs each bot to have clear boundaries, wants decision traceability, and prefers to run the platform on its own infrastructure instead of handing the system to a third-party SaaS. That includes teams working with sensitive data, teams that need to demonstrate controls, and teams that already have agents built with different frameworks and want to give them a channel and explicit isolation.
It is not a magic answer for everyone. If you want something prefabricated, without operating containers, without managing keys, and with a product-like experience ready to use, this kind of platform is not in that profile. It also does not make sense if your real need is just a bot that answers questions without acting on internal systems, because then the isolation problem we are talking about is not your problem.
And in any case, remember that OpenBot is in alpha. The author says so in the launch thread. That means the project is under active development, with rough edges and decisions that can change. This is not the moment to recommend it for production without warning about that. It is more the moment to understand what kind of architectural commitments it is making and decide whether they fit your case before it matures.
Why does this matter if you are learning to code and not running an enterprise team?
Because the way you think about isolation and accountability today is the same way you will have to think about it when you build real agents. This is not purely an executive topic. If you start coding and your first contact with agents is a chatbot that answers questions, you can come away thinking security is something "someone in infra" handles later. But once an agent can act on systems, read data, browse, or interact with other tools, the question of what is isolated from what, what gets recorded, and who authorizes it becomes an engineering problem, not a policy problem.
The consequences are not hypothetical. A weak boundary between bots can amplify the blast radius of a failure. A system without clear decision records can leave you without an explanation when someone asks why it did something. And a design choice like sharing one persistent resource among bots can make sense in some cases, but it comes with a different responsibility that you need to understand before adopting it.
Understanding this does not require being a security expert. It requires understanding that an agent is not just a model that generates text, and that isolation is not just a firewall. It requires understanding that, in a company, the costliest problems are usually not the ones the model got wrong, but the ones that came from poorly traced shared resources and decisions that were not recorded.
FAQ
What does it mean that OpenBot isolates per bot and not per user? It means each bot has its own computer with a separate browser, sessions, and files, and one bot cannot read another bot's files or reuse its sessions. Grok Bot, by contrast, shares one persistent cloud computer and isolates per user, not per Grok Bot.
Is OpenBot more secure than Grok Bot? That cannot be stated as an absolute. They are different design decisions. OpenBot draws a stricter boundary between bots; Grok Bot shares a persistent resource above the bot level. What changes is the blast radius and how a problem behaves if one of the bots fails or is compromised.
What does it mean that OpenBot records who made the decision and why? It means the record is not limited to which action occurred, but also points to who authorized or resolved it and the associated reason. That matters for audit and for being able to explain a decision in a company setting.
Can I use my current agents with OpenBot? Yes, if they speak AG-UI. OpenBot works with Google ADK, AWS Strands, Microsoft Agent Framework, LangChain, CrewAI, Mastra, Pydantic AI, and Claude Agent SDK, on top of the Channels SDK.
Is OpenBot ready for production in August 2026? No, it is in alpha. The author says so in the launch thread. It is better to treat it as an evaluation project or internal pilot, not as a production foundation without warning about its state.
What real criticism has the launch received? Tobi Lütke, CEO of Shopify, replied to the thread saying it is missing bash and a package manager, and suggested gVisor as a sandbox. That is a public and relevant technical critique, not a generic opinion.
Verified sources: launch thread from CopilotKit and from Atai Barkai (@ataiiam) on August 19, 2026; official landing at https://www.copilotkit.ai/openbot; repository at https://github.com/CopilotKit/openbot; Grok Bot's official FAQ with the phrase about sharing one persistent cloud computer and isolation per user; public critique from Tobi Lütke on the same launch thread. The 4Geeks reference article on what is CopilotKit OpenBot is at https://4geeks.com/en/blog/ai-powered-learning/what-is-copilotkit-openbot.