Grok Bot launched on August 11, 2026, and within days it had already produced two very different reactions online: people amazed it could run real, multi-step tasks unattended, and people alarmed that an AI agent could now complete purchases with real money attached. Both reactions are correct, because Grok Bot genuinely is that capable, and it genuinely does need to be operated with real discipline.

This is the complete course. Sixteen minutes is roughly how long it takes to read this once. Actually mastering the tool takes longer, the same way reading a manual and being good at using the machine are different things, but everything you need to go from zero to confidently running your first real Bots is here, grounded in the product's actual documented behavior, not speculation.

What Grok Bot Actually Is, In One Paragraph

Every other AI chat tool waits for you to type something, answers, and stops. Grok Bot is built around a different model entirely. You create a named Bot, it gets its own persistent cloud computer, complete with a browser, a filesystem, and the ability to sign into applications you authorize, and it continues working after you close your laptop. You can ask it to do a job once. If the result is good, you can turn that exact process into a reusable skill. Then you can put that skill on a schedule and let it run without you present at all.

That's the entire conceptual leap worth internalizing before anything else in this course. You're not learning a smarter chatbot. You're learning to direct a small team of persistent, always-on workers, each with a defined job.

Module One: Getting Access And Understanding The Real Cost

Before setup, know exactly what you're paying for, since Grok Bot has no standalone plan and no dedicated checkout page. You get it bundled into an existing subscription: SuperGrok Heavy, xAI's top tier, normally around $300 a month though xAI has run a promotional rate as low as $99 a month for new and existing subscribers, or through a qualifying Cursor plan, with Cursor Ultra at $200 a month being the realistic entry point for a solo user with no team to share seats with.

There is no free tier and no standalone trial beyond a one-time trial period. For a team, the "$120 per seat" figure that circulates undersells the real commitment, five people on that tier is $600 a month, $7,200 a year, before you've measured whether the Bots are actually finishing useful work yet. Treat your first month as a genuine pilot, not a full rollout, regardless of team size.

Module Two: The Persistent Computer Model, And Why It Changes Everything

The single architectural fact that makes Grok Bot different from a chat window: each Bot gets a computer that doesn't disappear. Files persist. Browser sessions persist. Application logins persist. State persists across however long the task takes, hours or, per xAI's own framing, potentially days.

This is also exactly why the setup process matters more here than with a normal chat tool. You're not just writing a prompt, you're provisioning a worker's actual desk, deciding what applications they can access, what credentials they're trusted with, and what they're allowed to do without asking first.

Module Three: Your First Bot, The Chief Of Staff

Every credible account of using Grok Bot well converges on the same starting move, and it's worth treating as close to mandatory rather than optional: build a Chief of Staff before you build anything else.

Give this first Bot access to your existing documentation, whatever you actually use, Notion, Slack, Gmail, your project tracker. Have it audit your current situation and tell you, specifically, which two or three additional agents would actually move things forward, not a generic list, a prioritized recommendation based on what it found reading your real, current state.

The reason this works better than jumping straight to a specialist agent: you don't yet know which specific tasks are worth automating in your specific situation, and a Chief of Staff that has actually read your real documentation gives you a genuinely informed starting point instead of a guess based on what sounded impressive in a demo.

Example brief for your first Chief of Staff Bot:

"Review our current [Notion workspace / Slack history / email threads]. Audit what's actually happening in the business right now, what's working, what's stuck, what's repetitive. Based on what you find, recommend the top three specific tasks that, if automated, would move revenue or efficiency the most. Be specific about what each recommended agent would actually do, not a generic category."

Module Four: One Mission Per Setup, Not One Setup For Everything

This is the single most important operational discipline in the entire course, and it's easy to get wrong on your first attempt because it feels efficient to combine everything into one place.

Grok Bot's agents run on a shared cloud computer per Bot. Mixing unrelated missions into one setup, your newsletter, your social posting, your business receipts, all in the same Bot, creates context bloat and burns through your usage allowance fast, because the Bot is now holding far more irrelevant context in working memory than any single task actually requires.

The fix is scoping discipline: one mission per setup. A Bot handling your content pipeline should not also be handling your expense tracking. This isn't a minor efficiency tip, it's the difference between a system that stays fast and cheap to run and one that quietly becomes both slow and expensive without an obvious single cause.

Module Five: Earning Each New Agent, Not Hiring Speculatively

Once your Chief of Staff has named the top candidates worth building, resist the urge to spin all of them up simultaneously. The proven pattern is sequential, and it exists specifically to prevent trusting an unproven process with real, unattended execution.

Have the Chief of Staff perform the candidate task once, manually, with you watching closely. Review the actual output. Only once you've confirmed it genuinely works do you say, explicitly, "now build a Bot that does exactly that, on a repeating basis." You earn each new hire by proving the underlying task works first, the same discipline you'd apply to trusting a new human employee with a repeating responsibility, rather than assuming a demo means production-readiness.

Module Six: Teaching A Task Instead Of Describing One

Grok Bot supports a genuinely useful alternative to writing a detailed prompt for a browser-based task: teach it directly. Where this feature is enabled, you perform the actual workflow once in the browser while the Bot watches, and it builds a draft skill from what it observed, which you then review and test before trusting it to run on its own.

This matters specifically for tasks that are easier to demonstrate than to describe in words, a specific multi-click process inside a piece of software with a particular quirky interface, for instance. Teaching by demonstration captures the actual sequence more reliably than a written description often can, especially for anything involving a UI that doesn't map cleanly to plain language instructions.

Module Seven: Turning A Proven Task Into A Scheduled Routine

Once a task has been proven manually and then confirmed working as a standalone Bot run, the final step is scheduling it as a recurring routine, the mechanism that actually delivers the "works while you sleep" promise this entire product is built around.

Ask your Chief of Staff directly what recurring jobs would move the business forward if they ran automatically, overnight or on a regular cadence, and have it build the actual automation for the ones that make sense. This is deliberately the last step in the sequence, not the first, because scheduling something that hasn't been proven yet just means automating a mistake to repeat itself reliably instead of once.

Module Eight: Understanding Approval Boundaries And Why They Exist

This is the safety layer that makes the entire persistent-agent model trustworthy enough to actually use, and understanding it well is what separates confident, safe usage from either overcautious avoidance or reckless overexposure.

You can require explicit approval for specific categories of action: sending messages, publishing content, deleting data, making a purchase, or changing anything in a production system. When one of these comes up, you get real choices, Allow once, Deny, or Always allow, plus the option to set Auto Review rules for categories you've decided are low-risk enough to pre-approve.

Critically, for passwords, passkeys, two-factor codes, CAPTCHAs, and payment details specifically, the Bot is designed to hand the screen back to you rather than take the credential itself. This is a real, structural safeguard, not just a policy statement, it's the mechanism that prevents a compromised or malfunctioning Bot from having your actual login credentials in the first place.

The practical rule worth adopting: default to requiring approval on anything in the sending, publishing, purchasing, deleting, or production-changing categories until a specific Bot has demonstrated, through repeated real use, that a specific narrow category of its actions can be safely pre-approved. Never pre-approve broadly just for convenience.

Module Nine: Real Workflow Patterns Worth Studying

A handful of documented, real-world Bot patterns are worth understanding closely, since they represent the actual shape of what this tool is good at, more useful than a generic feature list.

The sales outbound Bot. Researches target accounts overnight, scores contacts for genuine intent, drafts personalized outreach in your own voice, and queues everything for your approval by morning rather than sending automatically.

The Amazon cart Bot. Reads your past order history, identifies the products you actually reorder regularly, and builds the cart, stopping deliberately before checkout so a human confirms the final purchase.

The meeting follow-up Bot. Reads new meeting transcripts and separates what you specifically promised to do from what the other person promised, a genuinely useful distinction most manual note-taking blurs together.

The content pipeline Bot. Publishes to your own site first, keeping that page as the canonical source, then prepares tailored, separate drafts for other platforms, respecting the difference between a primary publication and its distributed variants.

The subscription pruner. Finds recurring charges buried in your inbox, recommends what to keep or cancel, and shows you the complete list before touching a single subscription.

The automation scout. Reads across your actual tool history, Slack, Notion, GitHub, whatever you use, finds genuinely repeated patterns of work, and proposes specific automations based on what it actually found, not a generic suggestion.

Notice the pattern across all six. Every one does real, substantive work, and every one stops at the exact point where a human's final judgment actually matters, sending, purchasing, publishing, deleting. That boundary isn't a limitation to work around. It's the actual design principle worth replicating in whatever Bot you build next.

Module Ten: The Shopping Feature, Understood Correctly

Grok Bot can search for products, compare options, build a cart, and initiate checkout, connected through a service called Link. This drew real attention, and real concern, when it launched, and it's worth understanding precisely rather than through either the hype or the alarm.

The actual safeguard: xAI's guidelines require human approval for the purchase itself, processed through Stripe, and the Bot cannot access your passwords or two-factor codes at any point. It can do the browsing, comparing, and cart-building labor. It cannot complete a transaction without your explicit, separate approval at the moment money actually moves.

This is the exact same approval-boundary principle from Module Eight, applied to the specific case that makes people most nervous. Understanding that pattern once means you understand why this feature is safer than the headline alone suggests, without needing to take either the hype or the fear at face value.

Module Eleven: Where Grok Bot Genuinely Struggles

Honest limitations, not marketing gaps, worth knowing before you build around this tool.

Browser automation is fragile by nature. Websites change layouts, add CAPTCHAs, or actively block automated access. xAI itself warns about this directly. A structured connector, where one exists for the specific tool you're working with, is more reliable than general browser control, which provides broad coverage at the cost of being more brittle against a site that changes without warning.

Data retention isn't clearly specified. Current documentation defers to Cursor's own terms rather than publishing independent, Grok Bot-specific retention policy. If this matters for your specific compliance needs, verify directly rather than assuming.

The weekly usage allowance isn't published. Eligible plans include some amount of weekly usage, with on-demand usage available beyond that where enabled, but the exact allowance size isn't disclosed publicly. This makes a measured pilot genuinely necessary before any team-wide rollout, since you can't calculate your real capacity needs from public documentation alone.

It's still an early beta with known issues. xAI says this plainly. Start every new task category with low-stakes, reversible work, and expand what you trust it with based on demonstrated performance in your own specific use case, not based on how the feature sounds described in a launch announcement.

Module Twelve: How Grok Bot Compares To The Alternatives

For context, since this is a genuinely competitive category, not a space where one product stands alone. Anthropic's Claude Code and Cowork have a longer track record and more documented enterprise usage in regulated industries specifically. Jack Dorsey's Block built a different architecture entirely with Buzz, giving every agent its own cryptographic identity within a shared team workspace, closer to a Slack replacement built for agent-human collaboration than Grok Bot's individually-directed, persistent-computer model.

The honest comparison isn't which is definitively better, it's which has more real-world proof for your specific task. If you already pay for a qualifying SuperGrok or Cursor tier, testing Grok Bot on one real, low-stakes workflow costs you almost nothing marginal and tells you more than any comparison, including this one.

Module Thirteen: The Common Mistakes That Undo Everything Above

A handful of specific errors account for most of the frustration people report, worth naming directly.

Skipping the Chief of Staff and jumping straight to specialist agents. This is the single most common way people waste their first week, building a sales Bot or a content Bot before they've had anything actually audit their real situation and prioritize correctly.

Combining unrelated missions into one Bot's setup. Context bloat and burned usage allowance are the direct, measurable result, not a hypothetical risk.

Pre-approving broad categories of action for convenience. The approval boundary system exists specifically to prevent an unproven process from acting unsupervised in a high-stakes category. Convenience is not a good enough reason to remove it before real, repeated evidence justifies doing so.

Scaling a workflow to a full schedule before proving it manually and then as a single unscheduled run. Automating an unproven task just means an unproven mistake now repeats reliably, unattended, which is a worse outcome than the manual version ever was.

Assuming beta limitations will resolve on your specific timeline. Build your current plan around what the tool reliably does today. Treat future improvements as a bonus, not something your business plan depends on arriving by a specific date.

Module Fourteen: Building A Multi-Bot System Without Losing Control

Once you have one or two Bots genuinely proven and running reliably, the natural next question is how to scale toward the kind of multi-department setup that turns individual automations into something closer to a real, functioning operation. This deserves its own module because scaling badly is where most people's early success quietly turns into a liability.

Each new Bot, regardless of how well your first ones performed, should go through the identical sequence from Module Five: proven manually first, confirmed as a standalone run second, scheduled only third. Confidence earned in one domain, sales research performing excellently, for instance, tells you nothing definitive about how a differently-scoped Bot will perform on a different task, like customer support or financial admin. Different categories of work carry genuinely different risk profiles and different failure modes, and treating your overall comfort with the product as a substitute for task-specific evidence is exactly the mistake that turns an early win into a later, avoidable problem.

Keep each Bot's tool access scoped narrowly to what its specific mission actually requires, even once you have several Bots running well. The instinct to grant a proven Bot broader access "since it's earned trust" mistakes proof of competence on one specific task for a general credential covering anything you might want to hand it later. Those are different claims, and only the first one is actually supported by your evidence.

As the number of active Bots grows, track their performance separately rather than judging your overall Grok Bot adoption as one undifferentiated success or failure. A sales Bot performing excellently alongside a scheduling Bot producing inconsistent results is a completely normal, expected pattern, not evidence the whole approach is failing. Lumping them together into one overall judgment obscures exactly the information you need: which specific workflows are earning their place and which need more work, tighter scoping, or should be abandoned for that particular task entirely.

Module Fifteen: Measuring Whether This Is Actually Working

The final skill worth building, and the one most guides to a new tool skip entirely, is an honest, ongoing measurement habit, since a system can feel productive without that feeling being backed by real evidence.

For each active Bot, track three things monthly, not just once at setup. Real hours saved, calculated against how long the task genuinely took you manually before, not an optimistic estimate made before you had real data. Output quality, judged specifically by how much correction or editing you personally still need to apply before something is usable. And your own trust trajectory for that specific Bot, whether your confidence in it is growing, holding steady, or quietly eroding based on its more recent performance, since a Bot that's slowly gotten worse is easy to miss if you've already relaxed your review habits from the early, careful weeks.

This tracking habit catches a specific, easy-to-miss failure pattern directly: a Bot that performed excellently when you first built it, which understandably led you to review its output less closely over time, but which has since drifted through changing inputs, a shifting business context, or simple inconsistency, without anyone noticing because nobody was checking as closely as they did in week one. Revisiting each Bot's actual current performance on a real cadence, rather than trusting your original impression to stay valid indefinitely, is what keeps a multi-Bot system healthy months in, rather than slowly accumulating quiet, unnoticed failures in the exact domains you've stopped actively supervising.

The other real value of this habit is knowing where to invest further effort versus where to cut losses. A Bot that's clearly excelling and saving genuine time deserves the effort of expanding its scope carefully. A Bot that's consistently underperforming despite real, honest attempts to fix its brief and its scope may simply be a poor match for this kind of delegation in your specific situation, and recognizing that plainly, rather than continuing to invest in something that isn't working, is as much a part of using this tool well as building the parts that do succeed.

Your Actual 16 Minutes, Spent Correctly

If you genuinely have sixteen minutes to invest right now before reading further, spend it exactly like this. Three minutes confirming which subscription tier you actually have access through, and what it costs you. Five minutes setting up your Chief of Staff with real access to your actual current documentation, not a placeholder. Five minutes writing the audit brief from Module Three, adapted to your specific business. Three minutes reading what it comes back with, and deciding which one candidate task you'll test manually first, per Module Five's sequence.

That's the entire mastery curve worth compressing into sixteen minutes. Everything after that, teaching your first real task, setting your first approval boundaries, scheduling your first routine, is the second session, built on evidence from the first, not assumption.

Master the sequence, not the individual feature. Chief of Staff first. Prove manually. Build the Bot. Schedule only once proven. Approve narrowly. Expand only with evidence. That discipline, more than any single feature covered in this course, is what actually determines whether you end up with a genuinely useful team of always-on agents, or a handful of unsupervised automations you stopped fully trusting weeks ago.

Follow @cyrilXBT for updates as Grok Bot matures out of beta and the workflows that actually hold up become clearer.

How to master Grok Bot in 16 minutes - Full Course

Job breakdowns