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

Install and sign in using the official setup guide and its current account requirements. Complete the initial shared-computer onboarding. For a new Bot, choose New → Create new Bot. In its menu, Edit Profile lets you set the name and job description. Name it ‘Vendor research’; use the role below, then place the fictional requirements and evidence in its chat.

Bots under an account share a computer, so a new Bot is not an isolated login or file space. This first exercise needs only supplied text. Do not connect your support inbox to test whether it can compare three documented offers. If sign-in fails, check the eligible-plan linkage and supported data setting in the official setup guide; do not treat a successful app installation as proof of entitlement.

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.

Expected first checkpoint: the Bot can repeat the six-seat, monthly-billing and $120 total requirements without inventing a preference. If it asks for the real company mailbox, restate that this is a fictional document comparison and no connector is needed.

2. Ask for a decision-ready comparison

Run this closed-book fixture first. Birch, Cedar and Maple below are invented; their prices are not purchasing advice. Supply the complete text and request source IDs rather than web citations. The fixture deliberately separates a contacts export from a ticket export and a monthly price from an annual commitment.

Once the fixture passes, repeat with three real candidate URLs and current primary documentation. Check the concrete action an integration supports: a notification integration, a support channel and a marketplace plugin are different capabilities. Keep missing facts visible.

REQUIREMENTS R1: 6 seats; shared support inbox; CSV export of support tickets;
month-to-month billing; total recurring cost no more than $120/month.
Data-location requirement is undecided: flag it, do not invent a region.
B1 — Birch: $12 per seat per month, monthly billing. Shared inbox included.
CSV export includes contacts. Ticket export is not described in this packet.
C1 — Cedar: $99/month includes five seats; $15/month per extra seat.
Monthly billing. Shared inbox and CSV export of support tickets included.
M1 — Maple: $8 per seat per month, billed annually with a one-year commitment.
Shared inbox and ticket CSV export included. No monthly plan is described.
All records are fictional and complete for this exercise. Do not browse.

Use only R1, B1, C1 and M1. Calculate the price for six seats.
For each requirement, label supported / unsupported / not established.
Cite the evidence ID for each decisive claim. Do not equate contact export
with ticket export. Do not present an annual commitment as monthly billing.
Identify the qualifying option under the stated requirements and the
undecided input that must be resolved before a real purchase.

A correct answer may recommend Cedar for a real trial only after resolving the remaining data requirement. It must not claim that we bought, contacted or tested a vendor. For a missing-input test, remove the budget line and replace C1 with ‘source unavailable’; the expected answer asks for the budget and marks Cedar's terms not established, while preserving B1 and M1.

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.

Reuse the two fixture variants above: the complete packet and the missing-budget/unavailable-Cedar packet. Keep their expected outcomes alongside the template. For a later real-source trial, replace the evidence IDs with three candidate URLs; record any inaccessible page as an access gap rather than supplying a remembered price.

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