Grok Bot: how persistent cross-app agents change delegated work

Grok Bot is an unusually direct step toward delegated software work: xAI says its agents have their own cloud computer, can sign into tools and apps, continue working while you step away, and return when a judgment call needs approval. The beta is available on desktop and iOS for specified SuperGrok, Cursor, and Cursor Teams subscribers, with usage separate from existing Grok and Cursor plans.

That is the part worth testing. Not “AI teammates” as a slogan, but a workflow where a task can continue across an inbox, a browser, and a system of record without making the user copy context between tabs. The production question is what you let an agent do, how you observe its work, and where approval is mandatory.

What does Grok Bot actually do?

Grok Bot is a team of always-on agents. xAI says each Bot has its own computer, works inside tools and apps, and completes jobs end to end. The official Grok Bot announcement names sales, marketing, office operations, invoice processing, and bug-fix workflows as examples from inside SpaceXAI.

The computer matters because it gives the Bot a place to keep working. The agent can use websites and tools even when there is no clean API or MCP integration, according to xAI. That expands the number of workflows it can attempt, but it also expands the number of interfaces and permissions you must review.

The beta is listed for SuperGrok, SuperGrok Plus, SuperGrok Heavy, Cursor Pro, Pro+, Ultra, and Cursor Teams Standard and Premium subscribers on desktop and iOS. xAI says Grok Bot usage is separate from existing Grok and Cursor plan usage. Verify current eligibility in the product before planning a team rollout; beta access and plan names can change.

The short version: Grok Bot is a persistent computer-using agent service, not a command-line package you should pretend has a stable public CLI.

How do you start a Bot safely?

xAI’s documented path is conversational: download the app, create a teammate, and message it a task. Start with a reversible, read-only job that has a known answer.

Review the project issue list and prepare a short report.

Read-only constraints:
- do not send messages
- do not edit tickets
- do not change files
- do not purchase, delete, or submit anything

Return:
- issues that have not been updated in 14 days
- the current owner for each issue
- one suggested next step
- links for human review

This is a prompt pattern, not an xAI command or guaranteed product template. The constraints are the important part. Tell the Bot what it may inspect, what it must not change, and what evidence it should return.

Once the report is correct, give it one bounded action. Keep the approval point explicit:

Draft replies for the three oldest support threads.

You may read the thread and prepare drafts.
You may not send, archive, refund, change account data, or contact anyone.
Stop when the drafts are ready and show the source thread for each one.

A Bot that can act across apps should not receive “clean up the inbox” as its first production task. Define the nouns, the allowed state changes, and the stopping condition before handing off work.

Why is the persistent computer useful?

The useful difference from a chat response is continuity. A Bot can keep a thread and work context while you leave the desktop or switch to the phone. xAI says users can message a Bot from desktop or phone and pick up the same thread later.

That makes Grok Bot a candidate for work with several visible steps:

• collect information from a set of approved sources;
• update a draft in a work system;
• prepare a handoff for a human;
• reproduce a UI bug and file the evidence;
• process a bounded queue of records.

The source announcement also describes multiple Bots working in parallel and Bots messaging each other or sharing context in threads. Parallel work can reduce waiting, but it changes the review problem. You need an owner for each Bot, a clear job boundary, and a final record that explains what happened.

Use a run record even when the product UI already shows a conversation:

type BotRun = {
  runId: string;
  botName: string;
  task: string;
  allowedSystems: string[];
  startedAt: string;
  completedAt?: string;
  status: 'draft' | 'waiting_approval' | 'completed' | 'failed';
  artifacts: string[];
  humanDecision?: 'approved' | 'rejected';
};

This is an application-side record shape, not an xAI schema. Store the minimum needed to explain the run, and avoid copying private app content into a second log by default.

Where should approval happen?

Approval should happen before an irreversible or externally visible action. The Bot may research an invoice, draft an update, or prepare a bug report. A person should approve sending the email, paying the invoice, changing the customer record, or merging a code change.

Separate preparation from commitment:

prepare -> validate -> request approval -> commit -> record result

The sequence is a design pattern, not a claim about Grok Bot’s internal implementation. It gives your team a clear place to put policy.

A useful approval request includes:

• the exact target system and record;
• the proposed change;
• the source evidence the Bot used;
• the expected side effect;
• a deadline or expiry for the approval;
• the identity of the person approving it.

Do not make “the agent returned successfully” your approval signal. A successful run can still select the wrong customer, misread a page, or act on stale information. Require a human decision for actions where the cost of being wrong is material.

For code work, approval should include the diff and checks. AI provider portability covers the adjacent model boundary: preserve a normalized task contract, validate the result, and record which provider produced it. Grok Bot adds a computer and cross-app state; it does not remove the need for those application boundaries.

How do you handle apps without APIs?

Computer use makes apps without clean APIs available to the Bot, which is one of the strongest parts of xAI’s pitch. It is also where the most fragile assumptions enter the workflow.

A web page can change its labels, layout, login flow, or confirmation modal. A Bot may still complete a visual sequence while selecting the wrong row. Design the task so the Bot has a verification step after every meaningful write:

After updating the record:
1. reopen the record
2. verify the customer identifier and changed fields
3. capture the confirmation state
4. stop if any identifier differs from the task

Again, this is an instruction pattern for a delegated workflow, not a guaranteed Bot feature. Prefer stable identifiers and visible confirmation over “click the third button.” If an app offers an official integration with narrower permissions, compare it before choosing broad UI access.

Never give an agent more access because a workflow is inconvenient. Use a dedicated account where possible, narrow its permissions, and keep production credentials out of pasted prompts. Review what the Bot can see in browser sessions, files, and connected tools.

How should teams run multiple Bots?

xAI describes a team model with specialist Bots for inboxes, expenses, recruiting, bug fixes, and operations. Start with one Bot and one queue. Add parallel workers only after you can answer three questions:

1. Which tasks may run concurrently?
2. What prevents two Bots from editing the same record?
3. Who reviews the final result and handles a failed run?

Use a lease or claim field in your own work queue when two agents might see the same item. Make the claim short-lived and record the Bot run ID. If a Bot disappears, the task should return to a recoverable state instead of remaining “in progress” forever.

For long-running work, background jobs for AI features covers queues, retries, cancellation, and idempotency. The principle applies even if Grok Bot manages the computer: the surrounding product still needs durable state.

Observe the workflow at the same level you would observe a human handoff:

• task received;
• systems accessed;
• draft or action prepared;
• approval requested;
• action committed;
• verification passed or failed.

Avoid logging full inboxes, customer records, or screenshots by default. Keep references and redacted evidence unless a detailed audit is necessary.

What does Grok Bot change for app builders?

The product creates a stronger incentive to make application interfaces consistent and actions explicit. If a Bot is asked to work across web and mobile surfaces, repeated labels, stable layouts, and predictable confirmation states make the task easier to verify. That is an application design problem, not something the model can solve after the fact.

OTF’s templates are one complementary starting point for teams that want the same component API and look across web and native surfaces, plus AI-tool configuration for an owned codebase. The useful connection is not that a template makes an agent trustworthy. It is that consistent interface behavior gives any delegated worker fewer variants to interpret.

Grok Bot makes “finished work” a credible product direction. Use it first for reversible research and drafts, then add one approved write action at a time. Keep permissions narrow, verify after every important change, and record enough state to explain what the Bot did. The persistent computer is the new capability; the approval and evidence loop is what makes it usable.

Sources

• Introducing Grok Bot — xAI
• Clarifying our pricing — Cursor

Originally published at otf-kit.dev — full-stack app templates for web and mobile. See the templates →