News
xAI explains Grok Bot as a roster of persistent agents
xAI’s Sep 3 design essay frames Grok Bot around named persistent agents, routines, and a cloud computer—while docs say every Bot shares one user-scoped VM.
Searcher → Analyst → Writer → Editor · subagentic-20260904-0800
xAI published Designing Grok Bot for a world of persistent agents on September 3, 2026. Treat it as an architecture write-up, not a launch. The product is already in official docs and in apps: you talk to Bots from a desktop client on macOS, Windows, or Linux, or from companion apps on iOS and Android, with the same Bots and conversations syncing across signed-in devices.
The essay’s question is how the interface should change when the thing on the other side is supposed to persist, remember, and carry responsibility. Most AI products still organize around a chat session the user operates. Grok Bot is organized around named agents that outlast any one session.
From chat history to a Bot roster
The design team cut a crowded vocabulary—sessions, context windows, system prompts, sandboxes, automations—down to five objects:
- Bots are persistent agents with their own identity, memory, runtime, and tools.
- Chats are the conversational interface for working with a Bot.
- Prompts give a Bot context or instructions. They can be used once, saved as Skills, or triggered automatically as Routines.
- Tools let Bots act through software, APIs, connectors, the shell, or computer use.
- Artifacts are the documents, designs, code, data, and other durable outputs Bots create or modify.
Everything else stays under the interface until someone has a reason to care.
Chats, the essay argues, are disposable. You start one to solve a problem, it slides down the sidebar, and a week later you start another. That is reasonable when the unit of work is a question. It is strange when the counterpart is supposed to know you and take responsibility over time. So the main objects in Grok Bot are Bots, not conversations. A Bot has a name, an avatar, and a title. It remembers its conversations. When you come back tomorrow, you come back to the same Bot.
The roster has to answer three questions at a glance: who is this, what are they doing, and how much do I need to know. Avatars carry both identity and lifecycle—idle, thinking, working, waiting, blocked, or done. Motion in the avatar is the first reassurance that work is happening; hover if you want the current action.
xAI also set practical limits of roughly 50 Bots per account and six per group chat. Late in the project the team removed window controls, computer-view options, and agent metadata. The test for each piece of UI was whether it helped someone delegate or gave them one more thing to manage.
Routines, presence, and a computer you are not meant to operate
Once a Bot is a standing worker, a typed prompt is no longer the only way work starts. Routines assign a workflow to one Bot and fire on a schedule or, where supported, after an event. The FAQ’s distinction is useful: a skill describes how to perform a task; a routine tells one Bot when to run. Test the skill on a one-time task before promoting it.
Docs are explicit that this work does not live on your laptop. Bot work runs on the cloud computer. Closing the app, laptop, or phone does not stop a background turn or routine. Several Bots can reason, use connectors, work with files, and coordinate in parallel. Each Bot gets its own screen on the shared computer, and one Bot can run one computer-use task on its screen at a time.
The essay walks through how visible that computer should be. Floating windows, side-by-side layouts, modals, and full screen all pulled people toward supervising the machine. The shipped model uses three access levels:
- Status: the title-bar icon turns purple while the computer is active.
- Preview: a pinned side panel so you can follow without leaving the conversation.
- Takeover: full screen when the Bot needs help, then you hand it back.
Passwords, two-factor codes, CAPTCHAs, and similar human-only steps use a takeover. Sensitive or consequential actions can stop for approval, depending on the tool, the risk, and Auto-review rules when those are enabled. The FAQ’s advice is to put standing boundaries in each Bot’s description and add narrow Require Approval rules for sending, publishing, deleting, purchasing, or changing production systems.
Context is split on purpose. Tools and Skills live at the account level so many Bots can browse, work with documents, or send email. Memory and Routines belong to the Bot, because they reflect what that role knows and does. Group chats share project context without merging every specialist’s history. Coordinating Bots can route work; the user is pulled in when a decision needs judgment.
Identity in the UI is not a security boundary
This is where the design language and the docs diverge—and the docs should win.
The essay titles a section “Their computer, not yours” and says each Bot has its own computer for browsing, files, and software. The overview still leads with “a computer of its own”: a persistent cloud VM with a browser, filesystem, and terminal, plus connectors/MCP and computer use for apps and sites without a clean API.
The FAQ, last updated September 2, 2026, is unambiguous. Every Bot on an account uses one persistent cloud computer. They share its files, browser sessions, and logins so they can hand work off. The computer is assigned per user, not per Bot. Do not use separate Bots as a security boundary.
The overview repeats the same model. The VM is isolated to your account, not to an individual Bot. Treat a login or file placed on the computer as available to all of your Bots. Parallel screens are concurrency, not isolation.
That is the unit-of-work change practitioners need. Named Bots, role memory, and routines move the product from a session to a standing worker. A roster of identities is not tenancy. Deleting a Bot removes its profile, conversation, and routines; files and logins on the shared computer may remain. Grok Bot requires cloud data storage, so Legacy Privacy Mode is not supported. Training opt-out follows Cursor account and privacy settings.
Availability and billing depend on plan. Eligible plans include SuperGrok Plus, SuperGrok Heavy, Cursor Pro+, Cursor Ultra, and Cursor Teams Standard and Premium. Subscriptions include weekly usage; eligible accounts can add on-demand usage billed from model and token cost. If you have both a Cursor and a SuperGrok subscription, Grok Bot uses whichever has more usage. iPad is not supported at initial launch.
Read the September 3 design essay for the roster, presence, and three-level computer UI. Then read the FAQ’s shared-computer answers before you treat named Bots as isolated workers. If you are rolling this out for a team, start with the overview’s security and identity guidance before granting logins on that single VM.