Grok Bot: separate the jobs, then test the handoff

What the documentation establishes

The vendor documents persistent Bots that use a cloud computer and can keep working while the local app is closed. Bots under one account share files, browser sessions and logins on that computer. Source ↗

The setup guide lists desktop and mobile access, Cursor sign-in, and eligible plans or linked SuperGrok access. It also notes that Legacy Privacy Mode must be changed to a supported data setting before Grok Bot can start. Source ↗

X documents an invite-only Grok Bot template rewards pilot. Rewards are discretionary, and promotional template posts in the program require a paid-partnership label. Source ↗

The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.

1. Create a role with a finish line

Use the official setup guide to install and sign in. Name the first Bot by its job, such as ‘Vendor research.’ Attach a short requirements file: team size, required channels, data-location requirements if relevant, and a monthly budget ceiling. If you do not know a requirement, mark it undecided instead of filling the gap with a default.

Keep the initial trial on public product pages. You do not need to connect a CRM, mailbox, or payment system to compare documentation. More access is only useful if it changes the work the Bot can complete.

Job: Vendor research for our support-tool selection.
Use the attached requirements as the decision boundary.
Return a comparison table with exact source links and a checked date.
Separate documented facts, missing facts, and your assessment.
Do not contact vendors, start trials, accept terms, or change accounts.
If pricing requires a quote, say so; do not estimate it as a fact.

2. Ask for a decision-ready comparison

Choose three candidates yourself for the first trial. This removes discovery quality as a variable while you assess evidence quality. Ask the Bot to compare the same dimensions for each: eligibility, integration fit, limits, setup effort, and costs that the public source actually establishes.

A comparison should expose missing information. ‘Supports Slack’ may mean a notification integration, a complete support channel, or a marketplace plugin. Make the Bot explain the concrete action the integration supports and cite the appropriate page, rather than treating every matching logo as equivalent.

Compare [vendor A], [vendor B], and [vendor C] for our attached support workflow.
For each requirement, return supported / not supported / not established,
with a primary-source link and the exact feature or limit it establishes.
List plan-specific restrictions separately. Do not mix monthly and annual
prices. End with three questions we need answered before a trial.
Save a concise findings document and identify every unresolved assumption.

3. Add a reviewer only after the contract is clear

If a second Bot is justified, give it the requirements and the first Bot’s findings, with a different task: identify unsupported comparisons and omissions. It should not simply vote on which vendor sounds best. Ask it to return disputed rows and the reason each row fails the requirement.

Because Bots share computer resources, put outputs in named folders and state which files each role may change. A second conversation does not imply a separate browser account. Avoid simultaneous tasks that require incompatible logins or editing the same spreadsheet.

4. Turn a good run into a reusable routine

Run the corrected brief a second time on a different set of vendors. If the same omissions recur, improve the brief before scheduling it. A routine should specify the inputs, output location, maximum scope, and what happens when a source disappears or requires login.

Track review time as well as generation time. An assistant that produces fifty plausible rows can create more work than one that returns six carefully supported comparisons. Expand the number of Bots only when the combined result is easier to inspect than the single-Bot version.

5. Package the routine so someone else can evaluate it

A routine that works only with your remembered company context is not ready to become a reusable template. X now documents an invitation-only template rewards pilot; that makes it especially useful to distinguish a shareable task contract from a persuasive demo. A promotion or reward is not independent evidence that the routine works.

Create a clean copy of the brief with placeholders for all organization-specific inputs. Remove customer names, account links and example output taken from real work. Keep the research-only boundaries from the first exercise. The template should ask for missing requirements before creating a shortlist; it should never silently substitute its preferred team size or budget.

Test two fictional fixtures. In the first, supply three candidate URLs and complete requirements. In the second, omit the budget and provide one inaccessible URL. The second result should expose the missing input and access gap, rather than inventing facts to fill the comparison. Keep the expected behavior beside each fixture, then ask a colleague to try the brief without your explanations.

Purpose: compare support tools against an explicit requirements file.
Required inputs: team size, required channels, data constraints, budget,
three candidate URLs, and a checked date.
If an input is missing: ask for it; do not assume.
Allowed work: read public documentation and create a comparison draft.
Output: one row per requirement/candidate, source URL, checked date,
supported / unsupported / not established, plus unresolved questions.
When a page fails: mark not established and record the failed URL.
Never: contact a vendor, create an account, start a trial, or buy a plan.
Completion: all requested comparisons have evidence or an explicit gap.
Review: a person checks the decisive rows before using the shortlist.

Bundle the blank brief, the two fictional fixtures, expected outputs and a revision note. Record whether the recipient needed extra explanation and how many unsupported positive claims survived review. If it fails, narrow the job or improve the missing-input questions before adding another Bot.

This handoff can be used privately without joining a rewards program. If you later consider public distribution, check the current product sharing controls and the pilot terms separately. This guide does not enroll you, publish a template or establish earnings. Keep version 1 of the brief so a regression can be traced to a particular change.

Guide history

Revisions preserve the original instructions. A source recheck alone does not create a new revision.

Revision 3 · Added a documented Bot creation path, complete fictional six-seat vendor packet, cost and evidence answer key, and a reproducible missing-input test.

Revision 2 · Re-read all sources; added a reusable template contract, complete/missing-input fixtures, clean handoff and transparent pilot context.

Revision 1 · Initial documented guide

Continue learning