2026-08-27 · Guide

Explaining Grok Bot to Someone Who Approves the Budget

You have a ten-minute slot with the person who can approve the budget for a Cursor or SuperGrok line item, and they will hear intern, sandbox, or headcount cut unless you say the actual object first. The phrase grok bot for managers is not a cheaper junior, not a per-bot vault, and not a chatbot upgrade. It is a named teammate on one persistent cloud computer assigned to the user account.

This page is the talking sheet for that meeting. It is not the ROI verdict after a trial run, which decides keep or walk away after a real job. It is not the plain explainer. You are here because someone has to sign, and they will sign the wrong story if you let them.

Facts below follow the Grok Bot FAQ, teams and enterprises, Cursor pricing, and xAI pricing, checked 25 August 2026 and rechecked against Cursor's plans page on 23 September 2026. Confirm the live number on the vendor page before anyone pays. Do not invent a savings percentage.

Open the ten-minute slot by naming the computer before anyone says intern

Start with the object, not the demo. If you open with a screen recording of a bot clicking around Gmail, they will price an intern. If you open with "each bot is isolated," they will price a sandbox they do not have. If you open with "it is like ChatGPT but it works overnight," they will ask why the company does not already have ChatGPT.

Say this sentence, then stop talking for a second:

A Grok Bot is a named job that runs on one cloud computer shared by every bot on that account. The computer belongs to the user, not to the bot. The bot gets a screen. The screen is not a vault.

Then name the door: Cursor Pro at $20, Cursor Pro+ at $60, or a self-serve Cursor Teams seat. Every paid Cursor plan includes Grok Bot; Cursor Hobby, the free plan, does not, and an individual SuperGrok, SuperGrok Plus, SuperGrok Heavy or X Premium+ subscription can be linked instead. There is no standalone Grok Bot SKU.

If they interrupt with "so it is an AI intern," correct it once: an intern is a person you can fire without leaving cookies on a shared machine. This is not that. The shared-computer page holds the detail. In the room you need the sentence.

Translate grok bot for managers into one named teammate on one shared machine

Write grok bot for managers as a staffing model, because that is how budget people listen. One eligible account. One persistent computer. Several named bots if you later want them, each with a screen on that same computer. Cookies, signed-in sessions, files, and command-line credentials are shared. Deleting a bot does not wipe the logins. Hosted MCP sign-in tokens stay with Cursor's backend, which is the documented exception, not a reason to treat the VM as a vault.

You are not buying N machines for N bots. A second bot is another screen, not another invoice line, and not another security boundary. xAI's docs say not to use separate bots as a security boundary. If the signer wanted finance and sales on two machines that cannot see each other, say no in the meeting.

Week one is one named bot, one reversible job, one human who reads the output. Inbox Triage labels and drafts, never send. Chief of Staff Briefing stays a pack. Lead Scout researches and never contacts anyone. Pick one. Not three.

Price the purchase order as twenty, sixty, or two hundred, never as a headcount swap

Put numbers on the table that exist on vendor pages. Then refuse the intern-salary comparison. A contractor costs thousands. A Grok Bot seat costs tens. That ratio is not a savings percentage you can print, because the bot does not replace the contractor until a human still does the irreversible step and the job actually repeats. Is Grok Bot worth it is where that measurement lives, after a trial. This meeting is which door you are even allowed to walk through.

SuperGrok Heavy is eligible. Do not print Heavy as $300. That number is not on the vendor pages this site treats as SAFE. Eligibility widened on 21 August 2026, so roundups that still open at $200 or Mac-only are stale. Shopping detail sits on the cheapest way in. Cost after the door is open sits on Grok Bot cost. Here you only need twenty, sixty, or two hundred, confirmed live, and never a fake percent of a salary.

If they already pay Pro, Pro+, Ultra, Teams, or an individual SuperGrok tier they can link, incremental SKU cost is zero. The meeting becomes a permission meeting. Still say the missing cap and the shared computer.

Say the missing spend cap out loud before anyone drafts the PO

There is no Grok Bot-specific spend cap, but the account-level On-demand monthly limit applies. Subscriptions include a weekly usage allowance. Overflow is on-demand, billed from model and token cost. No plan publishes that allowance as a dollar figure. If you invent one so the PO looks tidy, you have made a representation the vendor did not make.

Say the sentence in the room: we cannot cap Grok Bot on its own at a number today, only the account's on-demand spend. We can cap the work. One standing job. A human review. A calendar check on usage. No five-minute crawl, 288 times a day, "just to keep it warm."

If a numeric Grok Bot-only cap is a hard requirement, the honest close is not this SKU. Do not promise a coming-soon cap. Spend cap and token burn is the operating page after someone still wants the seat. In the ten minutes, you only need the signer to hear "no per-Bot cap" before they hear "twenty dollars."

Refuse the dedicated-VM story in the same breath as the cheaper-intern story

Two false objects travel together. Intern is the staffing false object. Dedicated VM is the architecture false object. Both make the product look safer and cheaper than it is.

The computer is a managed Linux VM. The bot runs as a non-root user. That is not the Linux desktop app, and it is not one VM per bot. All bots on the account share that computer. Each bot gets a screen. Screens are separate work surfaces, not separate security boundaries. Browser cookies, sessions, files, and CLI credentials are shared. Delete a bot and the files and sessions remain.

If finance heard "we will put the CRM bot and the research bot on two machines," stop the meeting. You would be buying one machine with two windows. A research bot can open whatever the CRM bot left signed in. That is the documented model, not a hypothetical.

Hosted MCP tokens staying on Cursor's backend is the exception if someone in the room knows MCP. Do not let that become "so the computer is fine." Browser logins on the VM do not get that exception. A second eligible account is how you actually isolate: a second door, a second computer, a second bill. Creating Bot B is not that.

Write no-audit-view on the one-pager because procurement will still ask

Someone in the room, or someone they forward the notes to, will ask whether Grok Bot records every action. The documented answer is that an audit view of Bot actions does not exist outside Enterprise. Twenty most recent run records per routine are a sliding window, not a ledger. Pause is a stop, not a log. An approval is a gate, not a receipt unless you export the proposal.

Write the gap on the sheet you came in with. Do not wait for the security questionnaire next month. If the company cannot buy software that lacks a central action history, this is not a maybe. It is a no on self-serve plans; audit logs and Action Recording are Enterprise only.

The substitute is yours: the bot writes a packet the company owns on every run. Send stays on ask, or send stays off. A human is allowed to fail the close. No audit view outside Enterprise is the receipts page. Marcus needs to hear "we will not have a vendor audit log" before he hears "the bot can live in Gmail."

Routines belong to one bot, max 50, with 20 run records retained. Deleting the bot deletes the routines. Nothing is team-level. If they thought they were buying a company-owned automation catalog, correct that. Export the working method yourselves.

Answer the VP who asks whether it can send the outbound sequence

This is the meeting that actually happens. You booked Marcus, who signs. Dana, VP of sales, joins because she heard the company might get an AI that does outbound. Her first question is whether it can send the outbound sequence.

The honest answer is no on day one.

Not "not yet, we will see." Not "yes, with guardrails." No on day one. Send is irreversible. A wrong sequence leaves the building. There is no audit view outside Enterprise to reconstruct who approved the wording. An approval does not reverse work already completed. The weekly pool is easy to burn on a long browser job that looks like prospecting. Brand damage is not a line item you can refund.

Dana will hear that as "then why buy it." That is the useful next sentence, not a failure. You buy a never-send worker that drafts, labels, and briefs. Dana still sends. If after a week the drafts are ones she would send, you can talk about send. You do not talk about send as the reason for the PO.

Walk the scene once so it is not abstract. Dana wants a 40-message sequence to a scraped list. You put Inbox Triage on the table instead: overnight mail, labels, three drafts, zero sends. You put Lead Scout on the table as a later job: public sources, a ranked list, no contact. You refuse the sequence as the first job. How to pick the first job is the scoring page you send after the meeting. In the room, the score is one word: reversible.

If Dana insists the only valuable job is send, the meeting has a clean close: we should not buy this SKU for that job this week. That is a better no than a yes that emails 40 strangers from a shared cookie jar.

Start the first paid week on a never-send job with a human in the last mile

Name the job before you name the plan. The first job must be undoable at 9am: delete a draft, relabel a thread, discard a brief. It must produce evidence a human can check. Send, post, purchase, and CRM write stay with a person. That is how you survive the missing audit view and the missing cap. A send-capable mail bot on day one is how the trial dies and how you explain a customer email nobody approved.

Paste-ready cousins already exist. Inbox Triage never sends. Mail Cleanup Assistant never sends, never replies, and never permanently deletes. Chief of Staff Briefing stays a pack. Lead Scout ranks and does not contact. Do not invent a "does Dana's sequence" listing for week one.

A charter that fits the first week:

Name: Week-one briefing desk
Job: One overnight pack, never a send

Each weekday by 07:30, write a one-page pack from sources I named:
the labeled inbox (read and draft only), the public web pages I listed,
and the file I pasted yesterday. Every material claim has a URL or a
message id. If you cannot find it, write could-not-compute.

Boundary: Never send, never reply, never forward, never purchase, never
post, never create an account, never sign into a site I have not listed.
Do not use leftover browser sessions for a new login. Drafts stay in this
chat or in Gmail Drafts. A human sends.

Stop when the pack is ready or when you are blocked. Do not keep browsing
to look busy.

If Marcus asks what success looks like on Friday, it is not "Dana's sequence went out." It is "five packs, a human read them, at least one draft was sent by a person, and nothing left the building on its own." The safety checklist is the pre-flight before mail is connected. Grok Bot and Gmail is the permission surface. Neither belongs as a live demo in a ten-minute budget meeting.

Separate this conversation from the ROI page and from the plain explainer

Three pages, three jobs. Mixing them is how the signer leaves confused.

What is a Grok Bot is vocabulary for someone who has never run one. Do not teach it in the budget slot. Is Grok Bot worth it needs a trial or a week of output. You cannot close that in ten minutes with no run. If Marcus wants payback, schedule it after Friday's packs. Do not invent the payback in advance.

This page is what you are signing and what you are not getting: twenty or sixty or two hundred, no per-Bot cap, no dedicated VM, no audit log outside Enterprise, no on day one to Dana's sequence, yes to a never-send job. After the meeting send the cheapest way in and how to pick the first job. The first is the cart. The second is the work.

Name who can actually log in: Mac, Windows, Linux, iPhone and Android

Platforms are a budget fact because a signer will assume "everyone here can use it." Supported: macOS on Apple silicon and Intel, Windows on x64 and Arm64, Linux on x64 and Arm64, iPhone on iOS 18+, Android 9+, and iPad through the iOS app (iPadOS 18+). The FAQ lists the Linux desktop app (.deb, .rpm or AppImage) as of September 2026. The cloud computer being Linux is not what gives your Ubuntu laptop a client; that desktop app is.

From the phone app (iPhone or Android) you can approve steps and pause or resume a routine, but not edit it. Editing and testing a routine still need the desktop app; the phone can now show run history and delete a routine. If the reviewer lives on a phone, they can stop a run. They cannot fix a charter. Do not staff the human-in-the-last-mile role to someone who only has an iPhone.

Privacy Mode (Legacy) blocks Grok Bot entirely. If the company turned that on for Cursor, the seat you just priced will not open. Ask before the PO.

Supported platforms is the reference. Cursor account access is the door. Grok the chatbot and Grok Bot are different products. Claude Code, SKILL.md, and CLAUDE.md compatibility is Grok Build, never Grok Bot. If an engineer starts talking about SKILL.md, they are on the wrong product. Park that.

Treat leftover sessions as still there after anyone deletes a bot

Deleting a user in Okta feels like a wipe. Deleting a Grok Bot is not. Files and browser sessions on the shared computer remain. The next bot on that account can open them. If a contractor's HubSpot login was on the machine, firing the bot does not fire HubSpot.

When they ask "what if we do not like it," you can stop paying, pause, or delete the named bot. You still need a person to sign out leftover sessions. Delete a Grok Bot safely is the offboarding page. In the room: deletion is a profile cut, not a machine wipe. A second bot is not a sandbox for a messy experiment. That experiment shares the disk with the briefing bot you just praised. A messy experiment is a second eligible account, which is a second line item.

Put a pasteable talking sheet in the invite, not a screen recording

A recording invites the intern translation. A one-pager invites a signature. Send this before the meeting.

Grok Bot one-pager for the budget slot (confirm prices live)

What it is: a named cloud teammate on one persistent computer assigned
to the user account. Each bot gets a screen. Screens are not security
boundaries.

What it is not: a cheaper intern, a per-bot VM, a chatbot SKU, a
separately spend-capped meter, an audit-logged control plane below Enterprise.

Doors (checked 23 Sep 2026, confirm before pay):
- Cursor Pro $20/mo: cheapest individual paid door
- Cursor Pro+ $60/mo, Ultra $200/mo: include, with more weekly usage
- Cursor Teams (self-serve): every member included, no Premium seat
- Individual SuperGrok, Plus, Heavy, X Premium+: link. Hobby: no
- Trial: limited usage, one-time, good for one never-send job

Missing on purpose, say them:
- No Grok Bot-specific spend cap. Weekly allowance, then on-demand
  up to the account On-demand monthly limit. No published dollar
  figure for the allowance. Do not invent one.
- No audit view of bot actions below Enterprise
- No model picker
- No dedicated VM per bot
- Deleting a bot does not clear logins or files

First job: never-send. Inbox drafts or a briefing pack. Human sends.
Dana asked if it can send the outbound sequence. Answer: no on day one.

We will not print a savings percent. We will run one reversible week,
then use the worth-it page, not this sheet, to keep or cancel.

If they want a demo, show a pack filling itself, not a bot sending mail. A send in a demo is how Dana's question wins the room.

Watch the first week for a check that can fail, then keep or drop the seat

Write a fail condition into the notes or the seat becomes a zombie. Friday, Marcus (or you) opens five weekday packs. Mark each used, edited, or discarded. Count drafts a human actually sent. Count anything that left the building without a person. Count times the bot was blocked and said so, versus times it kept browsing.

If nothing was used, cancel. If something left the building unattended, pause, then cancel or rebuild the charter. If packs were used and send stayed human, keep the seat and only then talk about a second job.

That check can fail. That is the point. Worth it is the write-up of the same measurement. A clean one-pager is permission to try, not proof the try worked. If the check needs history past twenty run records, export it yourselves.

Answer the claim that outbound send is the only job worth the line item

Dana's strongest form of the objection is not the question in the table. It is the claim that a bot which cannot send is a toy, so the SKU is wasted until send is on.

Take it at face value. If the only valuable work in the company is unattended outbound, this product is the wrong buy this week. Grok Bot can reach mail and the browser. Capability plus no audit view outside Enterprise plus no per-Bot spend cap plus a shared cookie jar is how you buy an incident, not a good first job.

The claim fails when there is other work that is slow, repeating, and reversible: overnight mail triage, a morning briefing, public-source lead research, a cleanup pass that never deletes forever. Those jobs keep a human in the last mile. If those jobs do not exist, do not invent them so the PO has a story. Walk away. The trial is a metered look and is easy to waste on a send-shaped crawl. How to test Grok Bot on the trial and the free trial page cover that path. Neither converts Dana's sequence into a good day-one job.

Where the objection wins: a sales org whose charter is "send first, measure later," with no reviewer who will sit on drafts. Buy nothing. Where it loses: a team that will read five packs and send the drafts themselves. Buy Pro+ or a Teams seat, confirm the live price, and keep send off until the check passes.

Keep reading: Is Grok Bot Worth It? What One Trial Run Can Prove, The Cheapest Way Into Grok Bot Without Restating Stale Prices, How to Pick the First Job to Hand a Grok Bot.

Frequently Asked Questions

What should I tell finance Grok Bot actually is?

Grok Bot is a named cloud teammate that runs on one persistent computer assigned to the user account, not to each bot. It is sold inside Cursor and SuperGrok plans. It is not a standalone SKU, not a cheaper intern, and not a per-bot sandbox. Screens are separate work surfaces, not security boundaries. Cookies, files, and CLI credentials are shared. The cheapest documented individual paid door is Cursor Pro at $20 a month. An individual SuperGrok Plus subscription can be linked instead. A self-serve Cursor Teams seat includes it. Confirm live prices on the vendor pages before you sign.

Why would we pay sixty dollars if Pro is twenty?

Cursor Pro is $20 per month and Cursor Pro+ is $60 per month, and both include Grok Bot. Pro is the cheapest documented individual paid door. Pro+ buys more weekly Grok Bot usage, not a different Bot. If the signer is buying Cursor for a team, a self-serve Teams seat is the Grok Bot path, and every member gets it without a Premium seat. If one person needs Grok Bot without a team SKU, Pro is the $20 door. Every paid Cursor plan includes Grok Bot; Cursor Hobby, the free plan, does not, and an individual SuperGrok, SuperGrok Plus, SuperGrok Heavy or X Premium+ subscription can be linked instead. Do not put Hobby on a purchase order and expect access. Confirm both figures live before anyone pays.

Can we start by letting it send the outbound sequence?

No on day one. Send is irreversible. A wrong sequence leaves the building. There is no audit view of bot actions outside Enterprise, and an approval does not reverse work already completed. Start with a never-send job: inbox drafts a human sends, or a briefing pack that stays in chat. Lead research that never contacts anyone is a later job. Pick the first job with a reversibility test, not with the loudest request in the room. After a week of drafts a person actually sent, you can talk about send. Not before.

Is there a spend cap we can put on the purchase order?

There is no Grok Bot-specific spend cap, but the account-level On-demand monthly limit applies. Subscriptions include a weekly usage allowance. Overflow is on-demand, billed from model and token cost. No plan publishes that allowance as a dollar figure, so do not invent one for the PO. Write the fact on the one-pager: weekly pool, then on-demand up to the account monthly limit, no product-specific cap. Control spend with that limit, one standing job, a human review step, and a calendar check on usage. If a numeric Grok Bot-only cap is a hard requirement, this product cannot meet it today.