Grok Bot: The Agent Got a Computer. Your Bots Share It.
Grok Bot shipped on August 11 as "AI teammates you can give real work to." Strip the adjectives and the object underneath is a cloud computer that logs into your tools as you, in a real browser, and keeps working after your laptop lid closes. The launch post says Bots have "their own computer." The documentation says something narrower: Bots "share the computer," and "sign-ins are not isolated by Bot." That gap is the whole story, and by the time this went up the open-source clones were already copying the shape.
What shipped is a computer, not a chat
Read the launch post from August 11 for the nouns, not the adjectives. Bots "have their own computer." They "sign into the tools you already use and work across apps, inboxes, and more." They finish jobs end to end "and only come back when something needs your approval." You "message them like a colleague." Several of them can sit in a group chat and "pass work, assign ownership, and only pull you in for judgment calls." Show one a workflow and "it saves your workflow as a routine." The one line that matters most for anyone who has built a browser agent: they work across "platforms with no clean API or MCP."
That last sentence is the product. Every other agent runtime you have used, from a coding harness to a workflow tool, needed the world to expose an API. Grok Bot skips the API and logs in as you, in a real browser, on a machine that stays on after your laptop lid closes. The bot is not a model with tools. It is a session with cookies, plus a model that knows how to click.
The documentation is more precise than the launch copy, and it is worth quoting exactly. A Bot is "a durable AI teammate with a name, a job, its own conversation, and working context that develops over time." Bots "can pass context through direct messages, group chats, and shared files." A Bot "can retain stable working preferences, important facts, and summaries from its work," and the docs warn that "Memory is not a substitute for an authoritative source." There is a hard cap: "An account can have up to 50 Bots and group chats combined." Usage is metered on its own: per the launch post, "Grok Bot comes with its own usage, separate from your Grok and Cursor plans." At launch it was available to SuperGrok, SuperGrok Plus, and SuperGrok Heavy subscribers, to Cursor Pro, Pro+, and Ultra, and to Cursor Teams Standard and Premium, on desktop and iOS, with enterprise access by waitlist.
The always-on part is the easiest to test and the most underrated. A laptop-bound agent, which is what most local agent runtimes are, stops when the machine sleeps. A bot with a cloud computer does not. The figure below runs three ordinary jobs on both and lets you close the lid.
Three jobs with fixed durations run on a laptop-bound agent and on a bot with its own cloud computer. Drag the slider to pick the minute you close the lid, then watch what finishes.
clock 00:00 / 60:00
laptop-bound agent runs on your machine
Grok Bot its own cloud computer
Job durations are illustrative. The behavior is the documented one: a Bot's computer stays on when you step away. Anything that runs on your laptop pauses when your laptop does.
Their own computer, singular
Now the sentence that the marketing does not say out loud. The launch post says Bots "have their own computer." The docs say: "Bots have separate roles and conversations, but they share the computer." And then, in the same section: "Shared computer files and sign-ins are not isolated by Bot and may remain on the computer."
Read those two together and the architecture is clear. One account gets one cloud machine. Every Bot on the account is a role running on that machine. The browser profile, the saved logins, the downloaded files, the terminal state: shared. A Bot is a conversation and a job description, not a security boundary.
That is a defensible engineering choice. One machine per account is cheaper, routines that hand files between Bots are trivial when the files sit on the same disk, and "show a Bot how it's done" is easier when the sign-in you used during the demonstration is already there for the next Bot. It is also exactly the design you would not pick if you were thinking about what happens when one Bot reads a hostile page.
Prompt injection is not hypothetical for this product line. On August 20, The Hacker News reported a disclosure by Adversa AI in which instructions hidden as AES-256-GCM ciphertext inside a web page got Grok to decrypt and follow them when asked to summarize the page, leaking the user's name, location, subscription tier, and prompts from the conversation. Adversa reported the issue to xAI's bug bounty on June 3 and said it had no mitigation timeline by publication. That attack targeted the Grok chat product, not Grok Bot, and the reported success rate was about 40 percent across roughly 20 attempts. The mechanism is the point, though: a page the model reads can carry instructions the model executes. Put that mechanism on a machine where the browser holds every login on the account and the question writes itself.
One account, several Bots, each signed into two tools. Click a Bot to say it just read a page carrying injected instructions. Flip the isolation model and count which sign-ins that page can now reach.
Bot roles and tools are illustrative; the sharing rule is quoted from the docs: "Shared computer files and sign-ins are not isolated by Bot and may remain on the computer."
Notice what the docs' own advice implies. They tell you to "create a separate Bot when the work has a distinct" recurring schedule or "set of tools and sources." That is separation of concerns, and it is good advice for keeping a Bot's context clean. It is not separation of privilege. If you want a Bot that reads untrusted email to be unable to reach the Bot that can move money, the boundary you need is a second account with its own computer, not a second Bot.
The plugin layer tells you where this product came from. The GitHub issues for Grok Bot's plugins live in the cursor/plugins repository: a Todoist connector failing with "code_challenge is required for public clients" (OAuth PKCE missing on a public client), a GitHub plugin whose Authenticate button produced no sign-in link. The download links on x.ai resolve to api2.cursor.sh. The pricing page lists Cursor Pro, Pro+, Ultra, and Cursor Teams next to SuperGrok. SpaceX's acquisition of Cursor's parent, announced June 16 and reported closed on August 14 at $60 billion in stock, did not just buy an editor. It bought the update server, the plugin marketplace, and the OAuth layer that Grok Bot now runs on. A coding agent's infrastructure became a general agent's infrastructure in about a week.
Show it once
The second idea in the launch post is routines by demonstration: "Ask a Bot to follow along the next time you do a job. It watches the steps and remembers how you like the work done. It saves your workflow as a routine, takes your corrections, and runs it on its own next time." The docs add one operational detail that should be on a sticky note: "Hiding does not pause the Bot or its routines."
Mechanically this is a compiler. The demonstration is the source. The routine is the program: a list of steps with the specifics you touched lifted out as parameters, plus a trigger. What makes it different from a recorded macro is that the model, not a selector path, replays the steps, so the routine survives a redesigned button. What makes it dangerous is the same thing: the model decides what "the same job" means next Tuesday, on a page it has not seen, with the account's full login jar available. The figure below compiles one and lets you decide where the approval gate goes.
Step through the job once on the left. The routine compiles on the right: steps, extracted parameters, a trigger. Then change a parameter or add an approval gate and run it.
you do it once
compiled routine
Illustrative workflow. The compile step is what the launch post describes ("saves your workflow as a routine, takes your corrections"); the parameter and gate names are mine.
Eight days in, the clones arrived
You can read what a market thinks a product is by looking at what people build to copy it. On August 19, eight days after launch, Open Bot hit Hacker News as "an open-source Grok Bot that works with any agent harness." On August 21, Agent Office was posted as "Slack for AI Agents," with the note that it was "similar to Grok Bot but older." The clones share a shape, and the shape is not a chatbot. It is a runtime: a persistent machine per bot, a plugin store, a message thread as the interface, and routines on a schedule.
That shape is also what the local-first agents already were. OpenClaw and Nous Research's Hermes are self-hosted, run on your hardware, and hold your logins on your disk. Grok Bot takes the same object and moves it to a machine xAI operates, with a message thread as the only interface. Anthropic's Cowork, which rolled out to mobile and web for paid plans on August 18, runs on remote sessions that keep working with no device online. Every vendor is converging on the same primitive: an agent is a computer with your logins on it, and the product decision is whose computer.
The early user reports split along that line. Entrepreneur Andrew Wilkinson posted: "I have about 15 bots and they now frequently say they'll do something then flake or disappear." One Hacker News thread from August 26 asked, after a Musk post, whether you would give Grok Bot access to your bank accounts. Grok Lite on the web spent August 19 and 20 returning word salad to some users, which the official Grok account called "a rare temporary generation glitch." None of those is a verdict on the architecture. All of them are the sound of a product that acts in the real world being used by people who noticed.
What this changes for anyone building agents
The unit of trust is the machine, not the bot. Whatever you call the thing with the name and the job, the thing with the cookies is the computer. Design isolation at that level. If your runtime gives every agent a shared browser profile, say so in the docs the way xAI does, and expect your users to want a second machine for anything that touches money.
No-API access is the feature and the attack surface. Logging in as the user through a browser is why Grok Bot can work a Zendesk queue on day one. It is also why a hostile page is a privileged input. The controls that matter are the boring ones: an allowlist of domains a bot may browse, an approval gate before anything irreversible, and a separate meter so a runaway routine cannot spend the account's main plan.
Routines need a diff, not a replay button. A routine compiled from a demonstration will drift as the pages it touches change and as the model decides what "the same" means. Treat it as code: a readable list of steps and parameters, a dry run, and a gate you can move. The figure above is a toy, but the shape of the control is the shape you will need.
The harness owns the customer now. Grok Bot ships on Cursor's update server, Cursor's plugin repository, and Cursor's OAuth. A coding editor turned into the distribution layer for a general agent in the time it took to close an acquisition. If you are building the model, you are one layer down from where the login jar is. That is the layer this product was built to own.
Update · September 3, 2026
Two weeks later
On August 26 xAI said Grok Bot "is now included with all SuperGrok, Cursor Pro, and Cursor Teams plans," restating the separate usage rule and listing the jobs it sees Bots doing: sales prospector, website builder, digital declutterer, customer support, office manager, meeting stand-in, refunds manager. The tier list matches the launch post; secondary reports say the standalone entry price at launch was higher before the product was folded into plans, which I could not confirm against an xAI pricing archive. On August 29 an X connector arrived: linking an X account creates a developer account if you lack one, paid users get free API credits, and an X plugin covers posts, timelines, trends, and bookmarks. On August 28, OpenAI told SpaceX it will wind down its contract supplying models to Cursor, with a proposed shutoff of November 12, so the model layer under the same download server is now changing while the computer layer expands.
The clone wave kept going: an unofficial Linux port of the official app (August 27, 33 points on Hacker News), an "Ask HN: Open-source Grok bot anyone?" thread (August 28), a durable-state layer to reduce Bot token consumption (August 27), and Gawkbot (September 2), pitched as an open-source Grok Bot "with local vms for each bot," which is the isolation model the docs say the original lacks. On September 2 a Hacker News post asked for a category name for OpenClaw, Hermes, and Grok Bot. Elon Musk announced "another free reset on token usage" for all Grok Bot users on September 1 and restated the pitch the same day: Grok Bot "runs on its own computer in the cloud 24/7, so it doesn't matter if you turn off your laptop." The Android app followed on September 2. One user reported burning the weekly token allowance in under 24 hours on a monorepo cleanup. The category has a runtime, a clone ecosystem, a meter people hit, and no agreed name. It needed the name less than it needs the second computer.
Keep reading