Every habit we have built around AI at work assumes a draft. The model produces something, a person reads it, fixes what is wrong, and decides whether it goes out. The checking is free because it sits in the path: you cannot send the thing without passing through the place where you would have noticed.
Grok Bot removes that step by design. xAI's own documentation describes the point as work finishing "in the real tools rather than as chat drafts". That is one sentence, and it moves the entire review problem somewhere else.
So the question worth asking about it is not whether the model is better. It is what you now have to check, and when.
What Grok Bot actually is
It went into beta on 11 August 2026. xAI describes a Bot as a single persistent, named agent, and the word they use for it is teammate rather than assistant.
The concrete part is the environment. Each Bot runs on a persistent cloud VM with a browser, a filesystem and a terminal. It is not answering from a chat window with a few tools bolted on. It has a machine, that machine keeps its state between sessions, and the work it does lands on it.
The product is organised around five things: Bots, Chats, Prompts, Tools and Artifacts. Chats are where you talk to one. Prompts are instructions, which can be used once, saved as Skills, or fired automatically as Routines. Tools are how it reaches software. Artifacts are the durable outputs, the documents and code and data it creates or changes.
That last distinction is the one to read twice. An artifact is not a message in a conversation. It is a file that now exists.
Computer use is the feature, not the model
Most of what gets written about a release like this is model comparison. The consequential design decision here is further down: xAI's docs say Bots use connectors and MCP where those exist, and computer use for apps and websites without a clean API.
That second half is the interesting one, because the software a company actually runs on is mostly the software without a clean API. The rota system. The supplier portal. The finance package chosen in 2014. The internal tool one person built and left. Integrations have never reached those, which is why the last mile of almost every automation project is a person retyping something.
An agent that drives a browser the way a person does is aimed squarely at that gap, and it is a real gap rather than an invented one.
The honest caveat is that driving a user interface is brittle in a way an API is not. A layout change is a broken process, and it breaks quietly. An integration that fails usually throws an error somebody sees; a bot that clicks the wrong thing because a button moved just proceeds. Anything you hand over this way needs a check on the outcome, not on whether the run completed.
A draft invites a check. A finished action invites a notification.
This is the shift that matters, and it is behavioural rather than technical. Reading a draft is a decision point you cannot skip. Being told that something has been done is a notification, and people do not audit notifications. They acknowledge them.
So the review has to be deliberately reinserted, and the only workable way to decide where is by reversibility. Work out in advance which actions can be undone cheaply and let those run. Anything irreversible or outward-facing, anything that sends, publishes, pays, deletes or commits, gets an approval step even when the bot is right nine times out of ten. Especially then, because that is when people stop looking.
xAI's documentation tells you to review approvals, security and privacy before granting access to sensitive systems. That line is doing a great deal of work, and it is worth treating as the instruction it is rather than as boilerplate.
One computer, shared logins
Here is the detail from the documentation that deserves more attention than it has had. Multiple Bots share one user-scoped computer and can run in parallel, with access to the same files, the same browser sessions and the same app logins.
Read that as a security property rather than a convenience feature. It means the reach of the narrow bot you set up for one tidy job is the reach of every other bot on your machine, because they are all sitting on the same authenticated sessions. Scoping a bot's task is not the same as scoping its access.
There is a documented reason to take this seriously rather than treat it as a hypothetical. In July 2026, Grok Build was found to have uploaded entire user source repositories to Google Cloud Storage, including API keys and shared secrets, despite the "Improve the model" setting being disabled. xAI disabled the behaviour and said the data would be deleted.
The useful lesson there is not that one company was careless. It is that a data path existed which nobody had modelled, and the control people were relying on did not cover it. An agent with a shell, a browser and your logins has far more such paths than a chat window does, and the ones that matter are the ones nobody has thought of yet.
The practical response is unglamorous and effective: give the bot its own accounts rather than yours, scoped to what its job actually needs, so that the question of what it can reach has an answer you can look up instead of reason about.
The pricing has a cliff, and long-running agents walk towards it
Worth knowing before you budget for this. Grok 4.6, released on 12 August 2026, carries a 500,000 token context window and costs two dollars per million input tokens and six per million output.
Those rates hold until the prompt reaches 200,000 tokens. At that point the price doubles to four dollars per million input and twelve per million output, and xAI's pricing documentation is explicit that the higher rate applies to all tokens in the request rather than to the excess.
That is a step rather than a slope, and it points the wrong way for this product. The agents you are paying for are the long-running ones that keep working, and a long-running agent accumulates context by doing its job well. The cost lever is therefore not how many tokens you use, it is deciding what gets carried forward into the next request and what gets summarised and dropped. Nobody enjoys that work, and it is where the money is.
What this does to the skill that matters
When AI produced drafts, the skill that appreciated was editing. Knowing what was wrong with a plausible paragraph, and being fast about it.
When AI produces actions, two different skills appreciate. The first is deciding what should be done at all, which was always the valuable half and is now the only half a person is definitely doing. The second is being able to tell whether something was done properly, in a system you did not touch, from evidence rather than from a status message.
Almost nobody is practising the second one. It is harder than reading a draft, it produces nothing you can show anyone, and it does not feel like work, which is exactly the profile of a task that quietly stops happening. A team that hands over execution without building that check ends up with a great many things that happened and no way to say whether they were right.
So the test I would apply before expanding any of this is simple. Pick one process, let a bot run it for a fortnight, then ask somebody who was not involved to reconstruct what actually changed and why. If they can, you have an AI teammate. If they cannot, you have an unaudited one, and the difference will not show up until it matters.
