How to Create a Grok Bot That Owns a Real Job

To create a useful Grok Bot, give one named Bot ownership of one durable job. Define the result it should produce, the sources it may use, and the actions that still require your approval. Then test it on a real task before adding a schedule.

This guide follows the current official Grok Bot setup documentation and Bot management guide. Grok Bot is in beta, so plan availability and individual controls can change.

1. Start with a job, not a personality

A name and avatar make a Bot recognizable, but the job makes it useful. A focused description should answer four questions:

• What outcome does this Bot own?
• Which tools or sources may it use?
• What should the finished result look like?
• Where must it stop and ask for approval?

“Help me with work” is too broad. A more operational starting point is:

Own the weekday pull-request review. Check the repositories I approve, separate merge-ready work from blocked work, and leave a linked decision list. Never merge or close a pull request without approval.

That role has a result, a scope, and a visible safety boundary. Compare it with the source-backed LGTM pull-request Bot in the directory.

2. Install Grok Bot and create the teammate

Use the official Grok Bot access page to confirm that your current plan and device are eligible. The product is available through the desktop app, with supported work also available on iPhone.

In the desktop app:

1. Choose New or press Cmd/Ctrl+N.
2. Select Create new agent.
3. Open the new Bot’s actions and choose Edit Profile.
4. Set a short name, job title, and operational description.
5. Start the conversation with one concrete task.

Do not create a roster of specialists yet. One Bot should first complete one end-to-end outcome. Split the role only when another job needs different tools, context, working style, approval rules, or cadence.

3. Give it a task you can verify

Your first task should finish with evidence you can inspect. Ask for links, screenshots, source names, or a short action log when they matter.

For example:

Review the open pull requests in these repositories. Group them into merge-ready, blocked, and needs-a-decision. Link every pull request and explain the blocking evidence. Do not merge, close, or comment.

This is a better first test than “run this every morning.” A schedule repeats both good and bad workflows. First learn whether the Bot can access the right source, apply the intended rules, and produce the expected result.

4. Connect only what the job needs

When a website requires a password, passkey, two-factor code, or CAPTCHA, the official setup flow lets you take control of the Bot’s computer and complete that sensitive step yourself. Do not paste credentials into ordinary chat.

Bots on one account share a cloud-computer environment, including browser sessions and files. A separate Bot is an organizational boundary, not a security boundary. Connect the minimum sources required for the job and sign out or revoke access when a source should no longer be available.

Read xAI’s current approvals, security, and privacy guide before giving a Bot consequential access.

5. Put the approval boundary in plain language

State what the Bot may prepare and what it may change. Keep these actions behind approval while the workflow earns trust:

• sending messages or invitations;
• publishing content;
• purchases or financial transfers;
• deletion or overwriting;
• permission changes;
• production changes;
• acceptance of legal terms.

A useful approval request should show the current value, the proposed value, and the expected effect. “Make it better” is not a reviewable change.

6. Correct the result, then save the method

Run the task, review the output, and make lasting corrections explicit. Once the result is repeatable, ask the Bot to save the process as a skill. The skill should include its inputs, steps, decision rules, output format, validation method, and failure behavior.

Only then create a routine that tells the Bot when to run it. The official skills and routines guide recommends proving the one-time task before automating it.

A complete starter instruction

Adapt this structure to the job:

You own [specific outcome] for [scope].

Use [approved sources] and return [reviewable result] with links to the evidence.
If a source is missing or stale, report that instead of guessing.

You may [safe actions]. You must ask before [sending, publishing, deleting,
purchasing, changing permissions, or changing production].

Run this once now. After I review the result, help me turn the proven process
into a skill and only then propose a routine.

Choose a source-backed starting point

You do not have to design the role from a blank page. Browse the Grok Bot directory for public examples, then check whether a listing is an installable Template or a documented Use Case. A Template must have a creator-published x.ai/bot/... link; otherwise the directory provides a clearly reconstructed prompt rather than claiming access to the creator’s hidden setup.

Sources and verification

The creation steps, shared-computer boundary, approval guidance, and skill-to-routine sequence were checked against xAI’s public Grok Bot documentation on August 30, 2026. Product access and rollout-specific controls may change; confirm them on the official access page before setup.