How to set up Grok Bot for a small business: a beginner's guide.

Getting Grok Bot running needs only an eligible plan, the desktop app and a sign-in. Getting it running well takes a few more decisions. Give the first Bot one job, start with work it can read and prepare rather than send, connect only the accounts that job needs, decide which actions must stop for your approval, and test on invented data before any customer is involved.

The documentation's own advice points the same way: start with read-and-prepare work, review the result, and only then add approved actions or a routine. Everything below follows that order. What the documentation states is described as such; where this guide adds an operating practice of its own, it says so.

Grok Bot uses a Cursor account, and the official pages describe access in two ways that do not quite match. The Grok Bot documentation lists every paid individual Cursor plan, the Cursor Teams plan, an individual SuperGrok, SuperGrok Plus or SuperGrok Heavy subscription linked to Cursor, or 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, not on Plus, and Cursor's help pages call the Cursor plans legacy and add X Premium+ as a subscription that can be linked. Cursor's help pages also list plans that do not include it, SuperGrok Lite among them. Plans change, so confirm eligibility on the official plans page rather than in any article, this one included.

The main working app is the desktop app, for macOS, Windows and Linux, downloaded from the Grok Bot downloads page. Mobile apps exist for iPhone, iPad and Android, and are useful for answering a Bot away from the desk, but some setup work, such as editing or testing a routine, currently needs the desktop app.

One setting can stop setup before it starts: Grok Bot requires cloud data storage, so an account in Cursor's Legacy Privacy Mode has to change that setting first. If the business has a data policy, read the documentation's security and privacy pages at this point, not after the first Bot is working.

Decide two things before installing:

• WHOSE ACCOUNT

  A Bot acts as the person signed in and, apart from team-managed connectors, can never hold more access than that person. Set it up under the account of the person who will supervise it, not a shared login.

• WHAT STAYS SEPARATE

  All of one user's Bots share one cloud computer and its sign-ins. Work that must stay apart, such as banking or payroll, belongs on a separate user account, not just a separate Bot.

The first job matters more than the first prompt. A good first job is one the business already does by hand every week, produces something a person can read and judge in a minute or two, and does no harm if it is wrong because nothing leaves the building until someone looks at it.

Read-and-prepare work fits that description: summarizing a week of inquiry emails into one list, turning a technician's notes into a tidy job record, drafting replies for someone to review, collecting supplier price changes into a spreadsheet. Jobs that send messages to customers, change records, spend money or involve a licensed judgment are poor first jobs, not because the product cannot be configured for them but because nobody yet knows how this Bot behaves.

A quick test for a candidate job (an Aevrion practice, not a product feature):

• FREQUENT

  It happens at least weekly, so there is enough repetition to judge the results.

• CHECKABLE

  A person can tell in a minute or two whether the output is right.

• CONTAINED

  Its inputs can be shared safely and its output goes to a person, not a customer.

• DEFINED

  Somebody can say what done looks like before the Bot starts.

After a short introduction, the app sets up the cloud computer in the background, creates a first Bot named Grok Bot and opens a chat with it. There is no form to fill in: personal Bots do not have a description field. The documentation's guidance is to give each Bot one primary job in its first message, tell it the standing rules, and ask it to remember them. The Bot can be renamed from its details.

The documentation describes a strong first request in five parts: the outcome you want, the sources it should use, the constraints it must respect, the deliverable it should produce, and the review point where it should stop for you. Writing all five forces the decisions that matter. A vague request produces a confident answer to a question nobody asked.

Memory needs one caution. A Bot builds up working context over time, and Cursor's help pages say it decides on its own what is worth keeping, but the documentation is explicit that memory is not a substitute for an authoritative source. Prices, schedules and balances belong in the system of record, and safety boundaries should rest on approvals and Auto-review rules rather than on what the Bot remembers.

For a first result the documentation suggests a task that needs no connector and no website login: attach a document and ask for a summary. That is a sensible pattern for a business too. Export a sample of the real work, remove anything sensitive, attach it, and ask for the deliverable you defined, such as a summary document or a spreadsheet, for you to review before anything is saved or sent.

Watch the first few tasks. The computer preview in the conversation's right-hand panel shows what the Bot is doing on its computer, which is the fastest way to learn how it interprets an instruction. If the result is wrong, correct it in the conversation and ask the Bot to remember the correction, then run it again.

When a job needs a website, the Bot works in a browser on its cloud computer. Sign-ins are handled by taking over the computer: choose Take over, enter the credentials yourself, then choose I'm done. The documentation says the Bot does not see the password, and that passwords and one-time codes should never be sent in an ordinary chat. A session signed in once is available to the user's other Bots, because they share the computer.

Some services connect as apps rather than through the browser. The documentation calls them apps, formerly connectors, installed as plugins from Connect apps in the sidebar, and names Gmail, Notion and Slack as examples. A connected app is available to every Bot the user runs. The security guidance is short and worth following literally: connect only the tools a workflow needs, and start with read-only tasks and draft outputs.

Websites vary. Many browser-based tools work, but a site may block automation, ask for a fresh login or show a CAPTCHA, and the documentation describes the Bot handing those steps back to a person rather than working around them. Test each tool the job relies on before building the job around it.

When an action needs approval, the conversation shows the proposed operation and its inputs with three choices: Allow once, Always allow, and Deny. Which actions stop depends on the tool, the risk of the action and the user's Auto-review rules. Auto-review is an independent review model that checks risky actions before they run; Cursor's help pages say it is on by default. Where an Allow rule and an Ask first rule both match, Ask first wins.

Two details shape a sensible setup. Always allow can save a matching rule, which widens what the Bot may do without asking; in the first weeks, this guide's suggestion is to prefer Allow once. And an approval controls the proposed action only: it does not reverse work already completed.

The documentation recommends explicit approval boundaries for:

• SENDING

  Messages, emails and posts to anyone outside the business.

• PUBLISHING

  Anything that becomes public.

• MONEY

  Purchases and financial transfers.

• DESTRUCTION

  Deleting or overwriting data.

• ACCESS

  Changing permissions.

• PRODUCTION

  Changes to live systems.

• TERMS

  Accepting legal terms.

The practice this guide recommends before the Bot works on live information is a small test set: five to ten sample inputs with invented names, including the awkward ones, such as a message missing its address, a request outside the service area, a complaint disguised as an inquiry. Write the expected result for each before running it, then compare. The guide to testing an AI assistant describes the method in full, including a case with a planted instruction to check that the Bot ignores text that tries to give it orders.

Test the boundaries as well as the output. Ask the Bot to do something that should stop for approval and confirm that it stops. Ask it for something outside its job and confirm that it says so. A first week spent this way costs a few hours and answers the only question that matters before going live: does it behave the way you think it does?

None of these are failures of the product. They are setup decisions that make a Bot harder to supervise, drawn from the documentation's guidance and this guide's own practice, and each one is easier to avoid than to undo.

• ONE BOT FOR EVERYTHING

  The documentation discourages a vague General Helper. One job per Bot, and a new Bot only for a distinct goal, tool set, approval boundary or schedule.

• EVERY LOGIN ON DAY ONE

  Connecting the business's main accounts before a single task has been checked. Sign in to what the current job needs.

• ALWAYS ALLOW TOO EARLY

  A saved rule can widen authority for future runs. Prefer Allow once until the pattern is proven.

• MEMORY AS THE RECORD

  Prices, hours and policies change. Keep them in a document or system the Bot reads, not in what it remembers.

• STARTING WITH SENDING

  A first job that messages customers turns every early mistake into a customer-facing one.

• NO REVIEW POINT

  A request without a place to stop runs to the end, right or wrong.

• SCHEDULING TOO SOON

  A routine repeats whatever the process is. Make it reliable by hand first.

• BOTS AS WALLS

  Separate Bots share one computer and its sign-ins. The documentation says not to use them as a security boundary.

Once a process works, the documentation suggests asking the Bot to save it as a skill, a reusable set of instructions, or to create a routine that runs it on a schedule. The order matters: a skill captures how the job is done, and a routine decides when it runs. The article on skills versus routines explains the difference and how to test each one.

From there, grow slowly. The documentation's guidance is one primary job per Bot, with a separate Bot for a distinct goal, tool set, approval boundary or schedule. This guide's suggestion is to widen what a Bot may do without asking only after a run of clean results, and only one step at a time. The questions to ask before that step, including what Grok Bot's documentation says about permissions and what it leaves to you, are covered in the article on whether Grok Bot is safe for business.

Based on the Grok Bot documentation at docs.x.ai as checked on 26 October 2026. Details attributed to Cursor's help pages come from cursor.com/help/grok-bot, checked the same day. The product changes often; check the linked pages before relying on a specific limit. 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. Access comes through eligible X Subscription, Cursor, SuperGrok or Grok Business plans, and the official pages describe them differently; check the plans page before relying on any article.
2. The app creates a first Bot called Grok Bot. Give it one job and its standing rules in the first message and ask it to remember them; personal Bots have no description field.
3. Start with read-and-prepare work that needs no login, then connect only the apps and websites the job needs, signing in yourself through takeover.
4. Decide approval boundaries before real data: sending, publishing, money, deletion, permissions, production changes and legal terms.
5. Test on invented data with expected results written first, including the boundaries.
6. Save a working process as a skill; schedule it as a routine only after it runs cleanly by hand.