LearnGrokChat assistants answer. Grok Bot, launched in 2026 and still labelled an early beta, does work, and the reason it can is a single mechanism worth understanding before anything else.
The mechanism: a Bot has a computer
Each Bot runs against a persistent cloud machine: a managed Linux virtual machine with a browser, a filesystem and a terminal, on which the Bot runs as a non-root user. That machine is why a Bot can operate a web app that has no API, keep a session signed in between tasks, and carry on after you close your laptop.
Three consequences follow immediately, and they explain most questions people ask in their first week.
The computer belongs to you, not to a Bot. One machine per person, shared by every Bot on your account. Files, browser cookies, signed-in sessions and command-line credentials are common property across your whole roster. That is what lets one Bot pick up where another left off, and it is also the single most important thing to understand about the security model, which is covered in Connecting Bots to your tools safely.
Each Bot gets its own screen on that machine. Several Bots can drive browser and desktop tools at the same time. But one Bot runs one computer-use task on its screen at a time, so a Bot that looks stuck is often simply busy with an earlier task on the same screen.
Durable work lives in a known place. There is a shared workspace directory that survives updates and recovery, along with browser state and supported sign-ins. Temporary directories, packages you install by hand and unsaved application state are explicitly replaceable; a recovered or reset machine may not have them.
What actually changes versus chat
The loop is asynchronous. With chat you are present for every step. A Bot works while you are elsewhere and comes back when it needs a decision. That is the whole value, and the whole risk.
Actions happen in your real tools. A Bot that can send, file, book or update can also do those things wrongly. The question shifts from "is this answer good" to "was this a reasonable thing to let software do unsupervised".
Context accumulates per Bot. A Bot keeps working preferences, facts and summaries of what it has done. Useful, but the documentation is careful to say this memory is not an authoritative source. Anything that changes should live in the system of record, and for consequential decisions you want the Bot to reopen current data rather than recall it.
What a good Bot task looks like
The tasks that work are ones you could hand to a competent new colleague:
- The goal is one sentence, and it is checkable.
- The inputs are named: which inbox, which folder, which document.
- The boundaries are explicit: what to do, and what to come back and ask about.
- The output has a destination: a draft, a document, a queue for review.
The tasks that go wrong contain an unstated "obviously, don't…". Say the obvious part. There is a template for it in Grok Bot task brief prompts.
What it is not
Not a chatbot with a longer memory, and not an IDE feature. Also not, at the time of writing, a product that lets you choose which model backs it; no model picker exists for members or administrators.
Two things worth calibrating early: a Bot cannot get past a site that blocks automation, demands a CAPTCHA or requires a human, and it is not supposed to try. Those steps come back to you. And a claim that Bots run "in parallel, 24/7" is true of the roster, not of one Bot's screen.
What changes
Grok Bot is early and moving quickly: platform support, availability, plan names and the feature surface are all live questions. Confirm anything specific at x.ai/bot and in xAI's Grok Bot documentation rather than trusting the date on this page.
