What Grok Bot can do for a business, and where its limits are.

Grok Bot gives each user a set of named AI assistants, called Bots, that work on a persistent cloud computer with a browser, a file system and a command line. Each Bot has its own job and conversation, remembers preferences and summaries of past work, can follow reusable written procedures (skills), can run on a schedule (routines), and can message and hand work to other Bots. Consequential actions can be set to stop for the user's approval.

It is not a workflow builder — the documentation says so directly — and it is not a telephone system, a field-service platform or a CRM. Its documentation names a number of connected apps but describes what only a few of them can do, it shares one computer between all of a user's Bots, and it hands passwords, two-factor checks and CAPTCHAs back to a person. Payment steps are handed back too, unless a card has been saved in the Bot's Vault: Cursor's help pages say a saved card can then be used at checkout without asking each time. A business that plans around those facts can use it well; a business that assumes otherwise will be disappointed.

The documentation describes a Bot as a durable AI teammate with a name, a job, its own conversation and working context that develops over time. Setup is done by talking to it: create the Bot, describe the job, and grant access when it asks. Durable rules — preferences, boundaries, responsibilities — are given in chat with a request to remember them, and instructions for a single task are ordinary messages. Personal Bots no longer have a description field; a Team Bot still has one, up to 140 characters, which is what teammates read when they find it rather than a place for its rules. One docs.x.ai page, on use cases, still tells readers to put a Bot's job and boundaries in its description, while the Bots and settings pages say personal Bots have none. Either way, the documentation says safety boundaries should rest on approvals and Auto-review rules, not on memory alone.

The guidance on how many Bots to have is conservative: start with the smallest useful roster, one Bot owning an end-to-end outcome, and add a specialist only when a role is stable and distinct — a different goal, different tools and sources, a different approval boundary or its own recurring schedule. A vague "General Helper" is discouraged.

• DUPLICATING

  A duplicated Bot carries its profile, settings, enabled skills, routines and avatar — but not its conversation history, learned memory or attachments.

• SHARING

  A Bot can be shared as a template. Adding a shared Bot creates a copy on the recipient's account and gives no access to the sharer's computer, logins or history.

• TEAM BOTS

  On team plans, a Team Bot is one Bot the whole team talks to; each teammate has a private chat with it that the others cannot read.

• DELETING

  Deleting a Bot removes its profile, conversation and routines, but files and sign-ins on the shared computer are not isolated per Bot and may remain.

Each user's Bots work on a persistent cloud computer with a browser, a file system and a terminal. Work, including routines, continues when the app, laptop or phone is closed. The computers run in Cursor's cloud — one dedicated virtual machine per user, located in the United States today — on Linux. They cannot be self-hosted or run on-premises. Idle computers hibernate, which is not deletion.

The detail that matters most is the word "shared". All of a user's Bots share that one computer, including its browser cookies and signed-in sessions, its files and its command-line credentials. Signing in to a website once makes that session available to every Bot. Each Bot gets its own screen, so several can work in parallel, but they are not isolated from one another: the documentation says not to use separate Bots as a security boundary. Isolation exists between users, and a workload that needs its own credentials should get its own user account.

Grok Bot uses connected apps, installed as plugins from Connect apps, where they are available, and operates the browser and desktop for everything else. Many browser-based tools work this way, including ones with no connector — but a website may block automation, ask for a new login, show a CAPTCHA or require a human, and the Bot is designed to hand those steps back rather than get around them.

The documentation does not publish a complete list of apps; they are found by browsing or searching Connect apps, and on teams through the Team Marketplace. The apps it names as examples are Gmail, Notion and Slack, and a table on its security page, written for Enterprise network settings, lists more, among them Google Calendar, Outlook, Microsoft Teams, QuickBooks Online, Zoho CRM and Zoho Books, without saying what most of them can do. Cursor's help pages describe a few in detail: Gmail can search and read mail and prepare drafts, and Google Calendar can read and update events and check free time. No field-service or review-site app is named. Team Bots can also use custom MCP servers — the documented route for a business connecting its own systems through a purpose-built integration.

Connected apps are account-wide, available to every Bot the user runs, and their sign-in tokens stay on Cursor's backend rather than on the computer.

Bots accept a wide range of attachments — images, audio, video, PDF, Office documents, spreadsheets and CSV, email files, plain text and more — and can produce reviewable outputs: a document with source links, a spreadsheet with defined columns, a slide deck, a folder of screenshots and logs, or an unsent draft message. A shared workspace folder lets one Bot read what another saved.

A Bot retains stable preferences, important facts and summaries of earlier work. The documentation is explicit that memory is not a substitute for an authoritative source: anything that changes — prices, schedules, balances — belongs in the system of record, and for consequential decisions the Bot should reopen current data.

A skill is a reusable set of instructions capturing steps, decision rules, the expected output and safety boundaries. Skills form one library shared by all of a user's Bots. Where the feature is available on the account, a browser workflow can be demonstrated once ("Teach a task") and turned into a draft skill. For a business, skills are where written procedures live.

A routine tells one Bot when to run a workflow — on a schedule or after an event. docs.x.ai gives Slack messages and GitHub notifications as event examples, through Cursor account integrations, and points to Cursor's help pages for webhooks. Those pages list more: a Slack message; a GitHub, Linear, Sentry or PagerDuty event; an email; or a webhook call. The email trigger works only for mail sent to the Bot's own agent address, not to a business's existing inbox, and a routine cannot filter by subject. A web form can start a routine only if the form's own system is set up to call the routine's webhook, which is a custom integration. There is no documented trigger for a missed call or a new review.

• LIMITS

  A Bot can own up to fifty routines; schedules must be at least five minutes apart; the app keeps the twenty most recent run records for each routine. Cursor's help pages add hourly caps: 300 runs across a user's routines and 200 for any one routine.

• TEST RUNS ARE REAL

  Testing a routine performs real work — it can navigate websites, change files and call connected tools. Test against a sandbox or in prepare-only mode.

• UNATTENDED USE

  After a long absence Grok Bot may ask whether to keep routines running and pause them if nobody answers.

• FAILURES

  Run history shows successes and failures. The documentation describes no automatic retry and no automatic failure alert; its guidance is to design routines with a no-data and stale-data policy, idempotent retries where possible, and a stated place to report partial completion.

Bots can run in parallel and message one another. A Bot can send an asynchronous request to another Bot, which wakes, handles it and replies later, with the handoff visible in the conversation; Bots can also pass ownership of a task so the user is not the router between tools. A group chat holds two to six Bots that can post and pass work among themselves, and the documentation's example has a coordinator Bot assigning work to the others.

Two limits shape any multi-Bot design: approval requests, secret and login requests, and email or Slack drafts do not appear in group chats, and handoff messages to a group are text-only, so an image a Bot must inspect should be sent to it directly.

When an action needs approval, the conversation shows the proposed operation and its inputs, with Allow once, Always allow and Deny. Which actions stop depends on the tool, the risk of the action and the user's rules. The documentation recommends explicit boundaries for sending messages, publishing, purchases and financial transfers, deleting or overwriting data, changing permissions, production changes and accepting legal terms. Its Auto Review is model-based and meant to complement least privilege and explicit boundaries.

An approval controls the proposed action; it does not reverse work already completed, and neither does a "Stop now" message. An approval raised by unattended work — a routine, a trigger or another Bot's message — expires if nobody answers, and the action does not run; docs.x.ai says after about ten minutes, while Cursor's help pages say thirty, so treat the window as short either way. By docs.x.ai's account, passwords, two-factor codes, CAPTCHAs and payment confirmations go through a human takeover of the computer. Cursor's help pages add a Vault, where saved logins and cards let a Bot sign in and check out without seeing them, and say no setting requires approval each time a saved card is used, so a business that wants to approve every payment should not save a card there.

A Bot has no identity of its own: it acts as the signed-in member, cannot hold more access than that member, and can use only what it is granted. Content a Bot reads can try to steer it, and the documentation says its layered controls reduce but do not eliminate that risk. Audit logs, action recording and network allowlists are available on the Enterprise plan only. Anysphere, the company behind Cursor, holds ISO/IEC 27001 and ISO/IEC 42001 certifications with Grok Bot in scope.

The official pages describe access in two ways that do not quite match. The Grok Bot documentation says it is included with every paid individual Cursor plan and the Cursor Teams plan, and can also be reached by linking an individual SuperGrok, SuperGrok Plus or SuperGrok Heavy subscription or through a seat on a self-serve Grok Business plan. docs.x.ai's pages on The X Subscription say Grok Bot is included on its Premium, Super and Ultra plans and not on Plus, and Cursor's help pages call the Cursor plans legacy and add X Premium+ as a subscription that can be linked; SuperGrok Lite does not include it. Usage is included weekly, with optional extra usage on eligible accounts. Prices are on the official plans pages and are not repeated here, and the documentation says a separate Grok Bot spend cap is not available today. Plans change, so check the official plans page rather than any article, this one included.

Cursor manages which AI model serves Grok Bot; there is no model picker and no particular model is promised. Desktop apps exist for macOS, Windows and Linux, with mobile apps for iOS, iPadOS and Android.

Claims about AI agents spread faster than documentation is read. The comparison below is limited to what the documentation states; where it is silent, that is recorded as silence, not as a capability.

None of the documentation's examples are home-service examples; every trade application on this site is Aevrion's illustration. With that said, the documented capabilities line up well with the preparation work that consumes a service owner's evenings: reading and sorting written inquiries, assembling job information from several places into one record, drafting replies, reminders and review requests for a person to send, compiling a weekly summary, and checking drafts against a written procedure.

They line up poorly with anything that needs an instant response, a telephone, a signature, a price, a license or a payment. That is not a reason to avoid the product; it is the shape of a sensible deployment. The One-Man Army article describes how to organize several Bots around those boundaries, and the guide to reliable home-service workflows shows the lifecycle step by step.

Based on the Grok Bot documentation at docs.x.ai as checked on 13 October 2026. Its statements on Bot rules, connected apps, routine triggers, approval expiry, payments and plans were rechecked against docs.x.ai and Cursor's help pages on 26 October 2026 and corrected where those pages had changed or disagree. Features described as rolling out may differ by account. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. Grok Bot provides named, persistent Bots that work on a shared cloud computer with a browser, files and a terminal, and keep working when your devices are closed.
2. Bots remember preferences and lasting rules, follow shared written skills, and run routines on schedules of five minutes or more or on events such as a Slack message, an email to the Bot's own address or a webhook call.
3. Bots can message each other, pass ownership of tasks and work in groups of two to six; approvals and drafts are not shown in group chats.
4. Approvals are configurable and do not undo completed work; raised by unattended work, they expire after about ten minutes by docs.x.ai's account and thirty by Cursor's help pages.
5. Gmail, Notion and Slack are named as connected apps and others are listed without detail; no field-service or review-site app is named. Two-factor checks and CAPTCHAs go to a person, and so do payments unless a card is saved in Vault.
6. All of a user's Bots share one computer and its sign-ins: separate sensitive work with a separate user account.