A deep dive into Grok Bot

Most AI assistants wait for a message, answer it, and stop.

Grok Bot is built around a different idea.

You create a named AI teammate. It gets a persistent computer, signs in to the applications you authorize, remembers how you work, and can continue while your laptop is closed.

You can ask it to do a job once. If the result is good, you can turn the process into a reusable skill. Then you can put that skill on a schedule.

That sounds like a small change from chat.

It is not.

A normal chat has context and tools. Grok Bot adds a place where work can continue: a cloud computer with files, browser sessions, applications, and long-running state.

This guide explains the complete system, how to set it up, what people are doing with it, where it is genuinely useful, and where another tool is a better choice.

One warning before we start: Grok Bot is a new beta and its access rules are moving quickly. The plan and platform details in this guide were checked on August 22, 2026. Always check the current Grok Bot page, documentation, and pricing before paying for a subscription.

What Grok Bot is

Grok Bot is xAI’s product for creating persistent AI teammates.

Do not confuse it with the Grok chatbot inside X, or with the @bot account used to announce the product.

A Bot has:

• a name and a defined job
• its own conversation and memory
• access to applications through plugins or a browser
• files stored on a persistent cloud computer
• skills that describe reusable ways to work
• routines that run those skills on a schedule or when an event occurs
• approval rules for actions that need a person

xAI describes the product as an AI teammate with its own computer and applications. The company says its internal prototype was used for jobs such as sales outreach, campaign work, office operations, and bug fixes before the public beta launched. You can read the launch post on X and the complete Grok Bot announcement.

The word teammate is useful here.

A Bot is not only a prompt. It is a persistent worker with a role, tools, working files, history, and boundaries.

That means the quality of the setup matters as much as the model.

The architecture that makes it different

The easiest way to understand Grok Bot is to separate four parts:

Bot
  ↓
conversation, role, memory, skills, routines
  ↓
personal cloud computer
  ↓
browser sessions, files, command-line tools, applications
  ↓
plugins and optional access to your local computer

The important detail is that you do not get one virtual machine for every Bot.

According to the computer and applications documentation, every user gets one persistent cloud computer, and all of that user’s Bots share it. The team documentation describes it as a managed Linux virtual machine.

Each Bot has its own screen, so several Bots can operate interfaces in parallel. But they share the underlying files, browser cookies, signed-in sessions, and command-line credentials.

This has two consequences.

First, Bots can collaborate through the same environment. One Bot can create a file and another can read it.

Second, two Bots are not separate security boundaries. Creating a second Bot does not isolate it from credentials already available on the shared computer.

That shared-computer model is the central fact to remember when you design a Grok Bot setup.

Persistent does not mean permanent

The cloud computer survives normal sessions, updates, and recovery operations.

Browser logins can remain active. Files can remain available. A routine can continue even when your own computer is turned off.

But the documentation still tells you to treat parts of the machine as replaceable.

Put durable work under /workspace. Temporary directories, installed packages, uncommitted application state, and files saved elsewhere may disappear during recovery.

Think of it as a managed work computer, not an archive.

If an artifact matters, store it in the documented workspace and copy the final result to the real system of record: your repository, document store, CRM, project tracker, or another application.

Who can use Grok Bot

Access expanded shortly after launch.

The beta launched on August 11 for SuperGrok Heavy, Cursor Ultra, and Cursor Teams Premium. On August 21, xAI expanded access: the official @bot announcement added SuperGrok Plus, Cursor Pro+, and all Cursor Teams subscribers, plus a limited trial for other users.

The Grok Bot FAQ currently lists these eligible plans:

• SuperGrok Plus and Heavy
• Cursor Pro+ and Ultra
• Cursor Teams Standard and Premium

Plain Cursor Pro is not on the list. The plans page confirms it does not include Grok Bot.

Subscriptions include a weekly usage allowance, and eligible accounts can add on-demand usage. If you have both a Cursor and SuperGrok subscription, the documentation says Grok Bot uses the account with the larger available usage allowance.

There is also a one-time trial for everyone else. It is a usage credit inside a seven-day window, and used credit is not restored. A large task can consume all of it in one run, so do not start your trial with a vague request that may run for hours.

The replies under the access announcement show the current tension. People are excited to try the product, but several users report hitting usage limits quickly. Others find the plan names and subscription choices confusing.

Treat access, price, and usage as part of the product’s beta status.

Supported platforms

According to the getting started documentation, Grok Bot currently has desktop applications for macOS and Windows. There is no Linux desktop application, even though the cloud computer itself runs Linux.

On mobile, Grok Bot currently works on iPhone with iOS 18 or later, according to the mobile documentation. Android and iPad are not listed as supported clients.

The iPhone application can use the same Bots, chats, routines, connectors, and cloud computer as the desktop application.

You can message a Bot, dictate a request, attach a file, watch the shared computer, and take over an interaction. Work continues when the application is closed.

Some administration still requires the desktop application. Editing routine schedules, testing and deleting routines, reviewing complete run history, and teaching a browser workflow are desktop jobs.

Create your first Bot

Install or update the application linked from the Grok Bot product page.

On macOS, open the downloaded disk image and drag Grok Bot into the Applications folder.

Open the application. Grok Bot starts with a sign-in screen.

Sign in with the Cursor or SuperGrok account that has access. If you use Cursor, the browser asks you to confirm which account should authorize Grok Bot.

Check the account before continuing. Only approve this page when you opened it from the Grok Bot application.

Create one Bot.

Do not begin with five Bots named Researcher, Marketer, Developer, Assistant, and Manager.

Start with one narrow job you already understand.

A good first Bot might be:

• Daily Product Monitor
• Customer Research Assistant
• Support Drafting Assistant
• Bug Reproduction Bot
• Podcast Guest Researcher
• Weekly Account Health Reviewer

A weak first Bot is called General Assistant and has the instruction help me with anything.

The official Bots guide recommends focusing each Bot around a stable job, goal, tools, working style, approval boundary, and schedule.

This is not busywork. A narrow role helps the Bot decide what belongs in its memory, which sources to trust, and when it should stop.

I run this blog, so through the rest of this guide I will use the exact first Bot I would create for it: a daily site reviewer called Blog Pulse.

Write a useful role

A good Bot description answers six questions:

1. What result does this Bot own?
2. Which sources may it use?
3. Which tools may it use?
4. What should the deliverable look like?
5. Which actions require approval?
6. What should it do when information is missing?

Here is the complete role I would give it. Swap the sources and checks for your own site or product:

You are Blog Pulse, the daily reviewer for flaviocopes.com.

Your job is to prepare a daily review of the site.

Use the Plausible analytics dashboard, the Cloudflare Pages
deployments page, the GitHub repository, and the live site.

For every report:

1. Confirm today's scheduled post went live. Check the blog
   index and the RSS feed, and link the new post.
2. Compare yesterday's visitors with the previous 7-day average.
3. List the top 5 pages and where their traffic came from.
4. Check that the latest deployment finished without errors.
5. Separate verified facts from your interpretation.
6. Link every claim to its source.
7. Save the report as /workspace/blog-pulse/YYYY-MM-DD.md.

End with:

- what changed
- what may require attention
- what you checked
- what you could not check
- three suggested next actions

You may read connected systems and prepare drafts.
Do not publish posts, push to the repository, send emails,
close issues, or make purchases without approval.

If a source is unavailable, do not guess. Record the missing source
and continue with the remaining checks.

Notice what this prompt does not contain.

It does not tell the model to be brilliant, proactive, world-class, or exceptionally intelligent.

Those words do not define work.

The prompt defines sources, comparison periods, evidence, output location, stopping conditions, and authority.

Connect applications in the right order

Grok Bot can reach applications in two main ways.

Use a plugin when one exists

Plugins expose structured application actions to the Bot. You can mention one with @ in a message.

This is usually the best option.

A plugin gives the Bot named operations and structured data. It does not need to find a button on a changing page, read text from pixels, or guess whether a click worked.

The official documentation uses the word Plugin for connectors and other integrated capabilities. The idea is similar to an MCP server: an application exposes a catalog of tools instead of forcing the agent through its visual interface.

If you want the background, read my guide to how MCP works.

Use the browser for visual workflows

Use the cloud browser when no useful plugin exists, or when the task is inherently visual.

The Bot can work with a persistent browser session. You sign in once, then the session can remain available on the cloud computer.

When a site asks for a password, passkey, two-factor code, CAPTCHA, payment confirmation, or another human-only step, take over the computer.

Do not paste a password or API key into the conversation.

Use the secure credential request. The documented flow masks the value and keeps it out of the normal transcript and model context.

The browser is flexible, but it is more fragile than a plugin. Pages change. Buttons move. Datacenter IP addresses are blocked. CAPTCHAs appear. A visual action may look complete even when the server rejected it.

For important work, ask the Bot to preserve evidence: result URLs, screenshots, timestamps, confirmation identifiers, and the final state it observed.

Give local-computer access only when needed

The cloud computer and your own computer are different environments.

Grok Bot can request access to the local computer, but the default permission is to ask every time. Keep that default until you have a specific reason to change it.

Local access is useful when the required file, application, or authenticated session exists only on your machine.

It also expands the Bot’s reach from a managed cloud workspace into your personal environment.

Do not enable it only for convenience.

Run the job once before you automate it

The most reliable Grok Bot workflow is:

one-time task → corrected task → saved skill → tested routine

Start by asking the Bot to perform the full job once.

Watch what it does.

Check:

• Did it use the right sources?
• Did it miss an important filter?
• Did it save the result in the right place?
• Did it distinguish facts from assumptions?
• Did it stop before an external action?
• Could another person understand the evidence?
• What happened when one source failed?

Correct the process, not only the final paragraph.

For example:

This report is useful, but the traffic comparison is wrong.
Compare with the same weekday from the previous four weeks,
not with yesterday. Weekend traffic is always lower.
Add the exact Plausible URL beside every number.
If analytics is unavailable, mark that section unavailable instead
of filling it from the previous report.
Run the whole workflow again with those rules.

You are trying to make the procedure stable enough to repeat.

Ask for a reviewable result

Do not ask a long-running Bot to “keep an eye on the blog.”

Ask for an artifact you can inspect.

Good results include:

• a Markdown report with source links
• a spreadsheet with raw data and derived columns
• a draft email that has not been sent
• a branch with a small code change and passing tests
• a bug report with exact reproduction steps and screenshots
• a folder containing a research brief and downloaded evidence
• an issue draft with labels and proposed owner

The files and results documentation recommends defining acceptance criteria and preserving evidence for consequential work.

For a serious task, I would require five sections:

Verified facts
Assumptions
Actions completed
Actions waiting for approval
Unresolved questions

This structure prevents a confident summary from hiding what the Bot did not know.

Turn a successful process into a skill

A skill is a reusable set of instructions.

It captures how to perform a job: which sources to open, which steps to follow, what to calculate, which failure cases matter, and what the output should contain.

Once the one-time blog review works, ask the Bot to save it as a skill.

Then inspect the result.

A useful skill should include:

• purpose and expected outcome
• required inputs
• source priority
• exact workflow
• validation checks
• expected output
• failure behavior
• approval boundaries
• examples of a correct result

Do not save the first lucky run as a skill.

The goal is not to preserve a conversation. The goal is to preserve a working method.

You can invoke saved skills with / in a Bot message.

Teach a browser workflow by demonstration

Grok Bot can also draft a skill from a browser demonstration. The feature is called Teach a task, and the rollout may be gradual, so it can be missing from your account.

Start recording, perform the workflow yourself, and let the Bot observe the visible interactions. A demonstration can last up to ten minutes. Audio is not part of the recording.

The Bot turns the demonstration into a draft skill.

Treat it as a draft.

A recording shows the happy path. It usually does not explain:

• how to recognize a stale page
• what to do when no records are returned
• which account or workspace is correct
• when a value is suspicious
• which confirmation means the operation completed
• what must never be clicked automatically

Add those rules in writing. Then test the skill against a different but normal case.

Teaching by demonstration is useful for navigation. It does not remove the need to define policy.

Put the skill on a routine

A routine tells a Bot when to run a workflow.

Routines can be scheduled or triggered by an event. They continue in the cloud when your laptop is closed.

Before creating one, define:

• owner
• schedule
• timezone
• input sources
• output destination
• approval boundary
• behavior when a source is missing
• behavior when there is nothing to report

For Blog Pulse, the routine could be:

Run /daily-blog-pulse every day at 08:00 Europe/Rome.

Save the full report under /workspace/blog-pulse/.
Send me a summary in this chat.

If a connected source is unavailable, finish the remaining checks
and list the unavailable source at the top.

Do not publish, email, or change any external system.
Ask before opening a GitHub issue.

The 08:00 slot is not random. My scheduled posts go live shortly after 07:00, so the first run of the day can confirm today’s post actually published.

Run a manual test before trusting the schedule.

I used 10:01 in this test so I could watch the first run immediately. Once the test works, change the routine to the time the real job requires.

The test performs real work. It is not a simulation.

Grok Bot currently allows up to 50 routines per Bot and keeps the 20 most recent runs of each, per the skills and routines documentation. Deleting a routine cannot be undone. Deleting a Bot also removes its routines.

Keep important outputs outside the routine history.

Use several Bots without creating chaos

Grok Bot supports up to 50 Bots and group chats combined.

You can duplicate a Bot. The copy receives the profile, settings, skills, routines, and avatar. It does not receive the conversation history, attachments, or memory of the original.

That is useful when two jobs begin from the same process but need different sources or boundaries.

It is not useful as a security isolation technique because both Bots still share the same cloud computer.

Groups let Bots and people work in one visible conversation. One Bot can gather research, another can inspect technical details, and a third can turn the result into a review checklist.

Keep the handoff explicit. This is how I would split the preparation of a tutorial like this one:

Research Bot:
Collect the official docs and release notes for the tool I am
covering and save /workspace/posts/brief.md.

Technical Review Bot:
Read that file. Verify only the technical claims against the
linked docs. Add citations and write /workspace/posts/review.md.
Do not rewrite the brief.

Editor Bot:
Wait for both files. Produce one outline and list every unresolved
claim. Do not publish anything.

Early users have reported that unrestricted multi-Bot conversations can become noisy. Bots may repeat each other, start unnecessary loops, or spend usage discussing work instead of doing it.

Use a group when the handoff needs to be visible. Do not create a committee for a task one focused Bot can finish.

What people are actually doing with it

The launch examples and early user reports fall into a few clear categories.

These are anecdotes from a new beta, not controlled benchmarks. But they show where the product’s shape is helping.

Monitoring and daily research

Alex Finn described a Bot that checks AI company accounts every 15 minutes, plus another that reviews product retention data and prepares outreach for at-risk subscribers.

This is a natural fit.

The Bot revisits the same sources, applies a stable filter, records what changed, and prepares a decision for a person.

The human does not need another summary of the entire internet. The useful result is a small list of new, relevant changes with evidence.

Customer support and community work

The same thread describes a community Bot that answers questions and direct messages throughout the day.

Lenny Rachitsky’s early uses included support email replies, matching job seekers with companies, reviewing subscriptions, and preparing podcast guest briefs.

Support can work well when the Bot has a trusted knowledge source, produces drafts, and escalates uncertain or sensitive cases.

Giving an early beta permission to send every reply without review is a different decision.

Browser testing and software work

Alex also described Bots that continuously test applications, find bugs or possible improvements, and prepare pull requests.

This uses the persistent computer well. The Bot can retain test accounts, browser state, screenshots, repositories, and working files between runs.

The best output is not “I tested the app.”

It is a reproducible bug report containing:

• tested version or deployment
• account and environment
• exact steps
• expected result
• observed result
• screenshot or recording
• console and network evidence
• proposed fix
• tests run

Content operations

Early examples include turning new social posts into newsletter drafts and creating new thumbnail variations based on previous work.

The persistent environment helps because brand references, examples, templates, and previous outputs can remain available.

This still needs a clear boundary between repurposing and publishing.

I would let the Bot collect source material and prepare drafts. I would not let it publish in my name without review.

Personal and office administration

xAI lists expense management, recruiting, sales outreach, paid-media analysis, account health, and chief-of-staff work among its official use cases.

Debbie O’Brien asked one Bot to research her, inspect her existing Bots, and propose a better personal setup. The result behaved like a one-prompt chief of staff.

Digg’s roundup of the launch discussion also highlighted a family meal-planning example: the Bot balanced preferences and new foods, then helped update grocery orders.

These jobs are not technically exotic. Their value comes from remembering preferences, returning to several applications, and completing the boring parts of the workflow.

Reusable Bot roles

Elie Steinbock created Bot Directory, an open directory of one-prompt Grok Bot setups.

That project captures another early pattern. People are beginning to share jobs, not only prompts.

A useful shared Bot definition needs more than a clever persona. It needs tools, source rules, memory guidance, deliverables, and approval boundaries.

The transferable part is the operating procedure.

The best use case for Grok Bot

The best Grok Bot job has seven properties:

1. It happens repeatedly.
2. It crosses several applications or websites.
3. It needs judgment, not only fixed data transformation.
4. It benefits from persistent login sessions and files.
5. It can produce a reviewable artifact.
6. Most steps are safe to perform without approval.
7. The risky final step can be separated and approved.

The clearest example is an operational review.

A Bot checks several sources on a schedule, notices changes, reconciles conflicting information, saves evidence, and prepares a short list of decisions.

The Bot handles the searching, copying, comparing, and organizing.

The person handles priorities and irreversible actions.

That is more useful than a generic autonomous employee. It is also easier to test.

When Grok Bot is the wrong tool

Do not use an AI computer for every automation.

Use normal code for deterministic jobs

If a task has fixed inputs, fixed rules, and a fixed output, write a script or use an automation service.

Examples:

• copy every form submission into a database
• resize an uploaded image
• send a receipt after a payment webhook
• run a test suite after every Git push
• generate a weekly total from one database query

A deterministic workflow is cheaper, faster, easier to test, and easier to audit.

If an agent helps you discover the workflow, you can later turn the stable parts into code. I wrote about this boundary in my Swamp tutorial: use the agent to build the machine, then use a repeatable runtime to run it.

Do not rely on it for hard real-time work

A Bot is not a low-latency event processor.

Do not put it between a payment request and a required response, in a health check that must finish in milliseconds, or inside a safety-critical control loop.

Do not use separate Bots as separate trust zones

Bots share a computer.

If two jobs must never share cookies, files, credentials, or customer data, they need separate accounts or a different isolation model.

Avoid it when model control is essential

The team documentation says Grok Bot does not provide a model picker. Model selection is managed by the product, with a fixed set and automatic failover.

This makes the experience simpler. It also means Grok Bot is a poor fit when you need to choose a specific model, pin its version, use a local model, or control the inference stack.

Avoid vague high-stakes autonomy

Do not ask a Bot to manage legal agreements, make financial decisions, administer production, or contact customers with an open-ended instruction and broad permissions.

It can gather information and prepare a decision.

The authority to execute the decision should live behind a narrow approval.

Approvals and security

Grok Bot asks for approval around consequential actions such as sending, publishing, purchasing, deletion, permission changes, production changes, and accepting legal terms.

An approval can be allowed once, denied, or turned into an always-allow rule.

Use Allow once while a workflow is new.

Only create an always-allow rule after you can describe the exact action, exact scope, and safe failure behavior.

The automatic review system can contain both Require Approval and Always Allow rules. A require-approval rule wins when both match.

That lets you express a useful pattern:

Always allow:
- read the Plausible dashboard
- open pages on flaviocopes.com
- create files under /workspace/blog-pulse/

Require approval:
- send any email
- push to the repository
- publish or edit a post
- close an issue
- purchase anything
- delete any external data

Avoid broad rules such as “always allow browser actions.”

The browser is not one capability. It is a route to every capability available in the signed-in session.

The full behavior is documented in approvals, security, and privacy.

For expensive or irreversible actions, a chat approval is not enough on its own. The underlying tool should bind approval to the exact action, exact target, current state, and current price. I explain that design in how to let an AI agent perform irreversible actions safely.

A practical security checklist

Before giving a Bot access to real work:

1. Create a dedicated account when the application supports it.
2. Give that account the smallest useful role.
3. Prefer read-only access for monitoring and research.
4. Use plugins instead of visual browser automation when possible.
5. Enter passwords and codes through the secure takeover flow.
6. Never paste secrets into chat.
7. Keep high-risk actions on approval.
8. Require evidence after every external action.
9. Review browser sessions and command-line credentials shared by all Bots.
10. Log out, disconnect, revoke, and delete temporary files when a project ends.

Deleting a Bot removes its profile, conversation, and routines. It does not necessarily remove files or authenticated sessions from the shared cloud computer.

Clean up the computer separately.

Grok Bot requires cloud data storage and does not support Cursor Legacy Privacy Mode. Training opt-out follows the settings of the account or team. If you work with regulated, confidential, or customer data, review the current privacy terms with the person responsible for that data before connecting it.

Context and memory are not the same as a database

Persistent memory is useful, but it creates a new maintenance job.

The Bot may remember an old preference after the policy changes. A long conversation may mix unrelated projects. A convenient note may become an unofficial source of truth.

Brian Lovin’s detailed first impressions called out this tension. He liked the named-agent model, polished interface, and the ability to delegate across environments. He also found multitasking inside one agent awkward, worried about long threads mixing context and sensitive information, and found parts of the tool execution less transparent than he wanted.

His workaround was to copy agents and isolate jobs into separate contexts.

That can improve focus, but remember the security limitation: a copied Bot has separate conversational context, not a separate computer.

Keep authoritative information in an authoritative system.

The CRM owns the customer status. The repository owns the code. The project tracker owns the issue. The policy document owns the current rule.

Memory should help the Bot find and interpret those sources. It should not silently replace them.

Grok Bot compared with other tools

Grok Bot is not the first product that can use a browser, run commands, remember work, or continue in the cloud.

Several early users made exactly this point.

Alex Finn said the individual capabilities were not unique. The advantage was that the product made them simple and pleasant to use.

Jesse Hanley described it as a polished package around persistent Linux computers, while noting that systems such as OpenClaw already cover similar ground.

Nick Dobos argued that the persistent cloud computer is the real breakthrough. He also said the beta remained rough and had a higher skill ceiling than its consumer presentation suggested.

That is the right frame for the comparison.

The question is not “which product has an agent?”

The question is “where does the agent live, what persists, which systems can it reach, and who operates the infrastructure?”

Grok Bot vs ChatGPT Work

Both can work locally and in the cloud, use connected applications, handle files, and continue longer tasks.

The important difference is the cloud environment.

The official ChatGPT Work overview says Cloud Work runs in isolated OpenAI infrastructure. Its cloud browser is separate from the browser on your computer. It cannot access your local tabs, extensions, history, password manager, or existing authenticated sessions. It supports public signed-out browsing and connected applications, but it does not accept credentials, sign in to sites, or complete payments in the cloud browser.

Grok Bot is organized around a persistent cloud computer where you can take over, sign in, and keep the session available.

ChatGPT Local Work is the other side of the comparison. It can use local files and applications with permission, which is useful when the work should remain tied to the computer in front of you.

Choose based on where the required state lives.

Grok Bot vs Hermes Agent

Hermes Agent is an open-source agent built by Nous Research.

Its Bot Mode is the closest direct comparison to Grok Bot. It turns agent profiles into named Bots. Each Bot can have its own role, model, memory, skills, credentials, routines, and persistent chat. Bots can coordinate through group chats and @mentions.

The architecture is different.

Grok Bot gives every user one managed computer shared by all their Bots. Hermes lets you run agent backends locally, in Docker, over SSH, or through cloud backends such as Daytona and Modal. You can also assign different models and providers to different Bots.

A Hermes profile separates configuration, memory, skills, credentials, and chat history. The file and process boundary still depends on how you configure its terminal backend and working directory.

Use Hermes when you want the named-Bot model with self-hosting, model choice, and control over where the work runs. Use Grok Bot when you want xAI to manage the computer and package the whole experience for you.

Grok Bot vs OpenClaw

OpenClaw is another do-it-yourself comparison.

It is an open personal assistant that runs on your devices, can keep memory, use tools, and control browsers. Its browser documentation supports an isolated browser profile or an existing signed-in Chrome session.

You choose the models and infrastructure. You also own the gateway, updates, credentials, network exposure, permissions, and incident response.

Grok Bot trades that control for a managed experience.

This explains Lenny Rachitsky’s comparison: he found Grok Bot easier, more reliable, and less intimidating than running a comparable personal-agent setup himself.

If you want to tune every part and are comfortable securing it, OpenClaw is more flexible. If you want the persistent-computer pattern packaged as a product, Grok Bot is easier to start.

Grok Bot vs Claude Code

Claude Code is a coding agent built around a codebase, whether you run it in the terminal, an IDE, or the cloud.

It is the better-shaped tool when the main job is understanding a repository, editing files, running tests, and producing a code change.

Grok Bot becomes interesting when the job begins outside the repository: check several dashboards, reproduce a browser problem, compare customer reports, update a draft, and then ask a coding agent to prepare a fix.

The two can also work together. The operations Bot finds and documents the problem. A coding agent changes the code. A person reviews and merges it.

Grok Bot vs Notion Custom Agents

Notion Custom Agents run recurring or triggered workflows using Notion pages, databases, and connected applications.

They have a narrower environment, which can be an advantage.

If the task begins and ends in a Notion workspace, a Notion agent has a clear source of truth, permission model, activity log, and reversible page history.

Grok Bot is broader. It can work across arbitrary websites, applications, files, and command-line tools. That breadth also creates more ways for state and permissions to become confusing.

How I would use Grok Bot

I would use Grok Bot as an operations layer around the software and content I already manage.

I would not make one Bot the manager of everything.

These are jobs I would try. I am not saying I already run them with Grok Bot.

For this blog

Blog Pulse from the walkthrough would be the first Bot.

The next one would prepare my newsletter.

It could open the previous campaign in Sendy, find everything I published since then, and verify every link on the live site. It could also check the current Bootcamp, Solo Lab, and Ship Factory pages before mentioning their dates or availability.

Then it would prepare matching HTML and plain-text drafts.

The instruction could look like this:

Prepare the next flaviocopes.com newsletter.

Read the previous campaign first. Find every post, course,
software release, and public launch published since that campaign.

Open every URL and include only pages that are live.
Check the current course pages before mentioning dates or availability.

Write an HTML draft and a matching plain-text draft under
/workspace/newsletter/.

Do not schedule or send the campaign.
Do not change a post or course page.
List anything that needs my decision at the top of the report.

This removes a lot of opening tabs, copying links, and checking details.

I would still review every sentence and press the send button myself.

Another useful Bot would watch scheduled posts after publication time.

My site rebuilds several times each day so future-dated posts can appear. The Bot could check the Cloudflare Pages deployment, open the expected post URL, and verify that the article appears in the blog, RSS feed, and topic page.

If something is missing, I want one report containing the failed check and the evidence. I do not want the Bot to edit the post, cancel a deployment, or push another commit by itself.

I would also try a documentation watch Bot.

It could monitor the official release notes for tools I cover, find the affected articles, and prepare a small change brief. Each item would include the old claim, the new official source, the affected URL, and a suggested correction.

I would decide whether the change matters. A coding agent could prepare the patch after that decision.

For my courses business

The first course Bot I would try is a Cohort Desk.

Bootcamp, Solo Lab, and Ship Factory appear on several pages. Each program has a status, date, call to action, waiting list, and analytics events.

A weekly Bot could compare those surfaces and report contradictions.

Review the current cohort offers.

Check the courses page, cohorts page, and the public page for
Bootcamp, Solo Lab, and Ship Factory.

For each program, record:
- current status
- displayed date
- call-to-action text and destination
- whether the waiting-list form works
- aggregate visits and waiting-list events

Report every mismatch and suggest the next check.

Do not edit a page, change a program status, export subscriber data,
submit a real email address, or contact anyone.

This is a good cross-application job. The answer lives partly in the site, partly in analytics, and partly in the email system.

It also has a clear stopping point: a short report I can review.

A second Bot could help with course support.

It could read a student message, find the relevant course page or support document, and draft a reply. An access problem should point to the normal course-retrieval flow. A billing problem or missing purchase record should be escalated instead of guessed.

The Bot could draft the reply. It could not send it, open a buyer record, expose a private course link, issue a refund, or change access without approval.

I would also try a Bot that browses the free courses in a clean browser.

It could follow the lesson navigation, answer a quiz, reload the page to check saved progress, download the course files, and record broken or confusing paths. The report should contain the course, lesson, exact steps, screenshot, and expected result.

The existing tests would still check deterministic behavior. The Bot would add the part that is hard to express in a unit test: whether the complete learning path makes sense in a real browser.

For the apps I built recently

I built many small products during the past month. The source code now lives in the software section of this site. Some of those products are a natural fit for Grok Bot.

HostingPicker gives me another good example.

Its recommendations depend on pricing and limits from 12 hosting providers. A weekly Bot could open each official pricing page, compare it with the last verified record, and report only material changes with the source URL and a screenshot.

I would not let it silently rewrite the data. Hosting prices are full of footnotes, regional differences, and usage conditions. The Bot finds the change. I decide how to represent it. A coding agent updates and tests the data.

Waiting Lists needs a different kind of review.

A Bot could run the complete double-opt-in flow in a staging environment. It would submit a designated test address, verify the email arrives, open the confirmation page, press the confirmation button, and check that the dashboard changes from pending to confirmed.

It could also prepare a launch brief from aggregate confirmed, pending, and failed-delivery counts.

Exporting subscriber data, changing list settings, removing records, or sending a launch email would require approval.

Events Logger could become the Bot’s morning inbox if I gave it access to a read-only dashboard.

The applications would continue sending signups, orders, payments, deploys, and errors through the normal API. The Bot would read the unusual events, compare them with GitHub, Cloudflare, and Plausible, then prepare a short exception report.

I would not ask it to calculate the core metrics or push events. Code already does that better. I would use the Bot to investigate why an error spike appeared beside a deployment, or why signups increased after a particular post.

Not every recent app belongs on a cloud computer.

Port Pilot, Local Hoster, and Livestream Recorder get most of their value from local Mac state. Their own CLIs and a coding agent running on my Mac are a better fit.

This is the boundary I would keep across all these examples.

Code performs the exact checks and mutations. Grok Bot moves between the surrounding systems, gathers evidence, and prepares the decision.

Common failure modes

The Bot loops or keeps talking

Stop or steer the work in the active conversation. Make the deliverable and stopping condition explicit.

For group work, assign one owner for the final result and require other Bots to write files instead of repeatedly discussing the task.

The browser cannot sign in

Take over for the password, passkey, MFA, or CAPTCHA. Some sites block cloud datacenter addresses even after a correct login.

When possible, use an official plugin instead of the visual website.

A plugin stops working

Confirm that the connection is still authorized. Reconnect the application and test one small read operation before rerunning the full workflow.

The Bot cannot find a file

Check whether it was stored under /workspace. Do not rely on a temporary directory for durable work.

Ask the Bot to show the exact path and list the directory rather than searching from memory.

Usage disappears faster than expected

Long browser sessions, multi-Bot discussions, retries, and vague research can consume substantial usage.

Reduce the number of sources, tighten the deliverable, split exploration from execution, and stop loops early.

The current product does not expose a model picker you can use to switch every routine to a cheaper model.

The computer behaves incorrectly after an update

The troubleshooting guide recommends the least destructive recovery first: retry, restart the affected application, update the client, and use normal recovery.

Resetting the agent computer is a last resort. It may remove recent unsynchronized state.

Back up important artifacts and note which applications will need to be reauthenticated before resetting anything.

A compact checklist for every new Bot

Before you call a Bot ready, verify all of this:

• The name describes one stable job.
• The role defines an outcome, not a personality.
• Trusted sources are listed in priority order.
• Required applications use the narrowest useful permissions.
• Durable files go under /workspace and into a real system of record.
• The output is reviewable and includes evidence.
• Missing information produces an explicit gap, not a guess.
• Sending, publishing, purchasing, deleting, and production changes require approval.
• The workflow succeeds once before becoming a skill.
• The skill succeeds again before becoming a routine.
• The routine has a timezone, owner, destination, and no-data behavior.
• Every credential on the shared computer is safe to expose to all your Bots.
• Usage and failures are reviewed after the first scheduled runs.

Start with one boring job

My first Grok Bot would be Blog Pulse, the example we built in this guide.

It checks the same pages every morning, writes one report, and asks before changing anything.

I would not connect every account on day one. I would not create 10 Bots. And I would not automate a task I had not already tested by hand.

Give one Bot one boring job. Run it a few times. Fix the instructions when it gets something wrong.

If you still open its report every morning after a week, keep it. Turn the workflow into a skill and schedule it.

If you spend more time checking the Bot than doing the job yourself, delete it.