Grok Bot is xAI's early-beta take on persistent AI teammates. You name a Bot, give it a role and an outcome, and it works in its own cloud computer with a browser, file system, terminal, and connectors. It keeps going after you close the tab, then comes back with results or an approval request.
That makes it a better fit for recurring, cross-tool work than for one-off questions. Here is how I'd set up the first one.
Know the boundary first
All Bots under one user account share one cloud computer. Files, signed-in sites, and credential state can be visible to every Bot. Each Bot has its own screen and task context, but that is not a security boundary.
So use multiple Bots to split roles, not to isolate permissions. Clean up temp files, stale sessions, and unused connectors. Deleting or hiding a Bot does not wipe what it left in the shared environment.
Pick a low-risk role
| Role | Hand off first | Keep for yourself |
|---|---|---|
| Conference assistant | Agenda, takeaways, follow-ups, recap | External commitments, final calls |
| Chief of Staff | Daily brief from calendar, inbox, project status | Priorities, staffing, sensitive messages |
| Researcher | Public sources, comparison table, links | Which conclusion to act on |
| Marketing operator | Material, event page draft, content calendar | Publishing, ad spend, brand sign-off |
| Engineering assistant | Bug repro, logs, minimal fix proposal | Production changes, merges, permissions |
Start with read, prepare, and recommend. Keep sending, publishing, spending, and production changes behind approvals.
Write a four-part brief
Outcome, where the material is, what needs approval, and the delivery format:
You own: research and a draft event page for this week's product event.
When you finish, I need: one page of copy, three headline options,
source links, and a list of open decisions.
Find material in: the event library in Notion and public web sources.
Ask before: publishing, sending invitations, payments, deleting files,
or changing permissions.
Deliver as: Markdown, conclusion first, then evidence and next steps.
When a result is off, this tells you whether the material, the rules, or the execution path was the problem.
Lock approvals before the first run
In Settings → General → Auto-review, require approval for sending messages or invitations, public posts, purchases and transfers, deleting or overwriting data, permission changes, production changes, and accepting legal terms. If Require Approval and Always Allow both match, Require Approval wins.
Approvals only stop the next action. They can't undo one that already ran.
Passwords, passkeys, 2FA, CAPTCHAs, and payment confirmations need you to take over the computer. If no task needs local files, leave Execution on Local Computer at Never allowed; the Bot can still use its own cloud computer.
Then Skills, then Routines
After you have revised two real deliveries and the task runs reliably, save it as a Skill: trigger, inputs, access scope, steps, validation, output format, approval points. That is the "how".
A Routine gives a proven Skill to a Bot on a schedule or event. That is the "who and when". Test runs do real work, so test with that in mind, and decide ahead of time what happens when data is missing, a step fails, or an approval is pending.
Teach a task lets you record a demo of a small stable process, up to 10 minutes per recording. The docs say it is still rolling out.
More Bots last
Add a second Bot only after the first one's quality, format, and approvals are stable. A workable setup is one Chief of Staff that splits and merges work, plus specialists for research, content, spreadsheets, or bug repro. Group Chat takes two to six Bots, assigned with @ mentions. Handoffs in the group are text-first, so send images straight to the Bot that needs them.
Each extra Bot adds shared-environment, handoff, and approval overhead. Stabilize one workflow before you expand.
Check before you quote
- The docs list macOS, Windows, and iPhone. Check the current page before claiming Android, iPad, or Linux.
- Usage and billing vary by plan and region. Don't estimate team capacity from one person's two days of usage.
Originally published at fxai.ai.
Top comments (0)