Grok Bot Use Cases: Eight Roles and How to Start Each One

Cursor's guidance is that the best Bot roles own a repeatable outcome, not a loose category of questions. This section covers what that rule means in practice and the ordering the docs recommend before you give a Bot any power to act.

A Bot, in the docs' terms, is an AI teammate with a name, a job and context that builds up over time, working on a persistent cloud computer with a browser, a filesystem and a terminal. A role such as account health or expense manager gives that Bot guidance and makes its saved context reusable, which a general helper does not. The sequence the docs recommend is to start each role with read-and-prepare work, review the result, and only then add approved actions or a routine.

Every starter prompt in the docs ends at a review point on purpose. They return a review list, a set of drafts or a write-up, and they say outright not to send, enroll, publish, change budgets or touch production. Cursor's line is to keep sending, publishing, purchasing and production changes behind approval, so the prompts below are shaped to prepare work for a person to decide on, not to finish it unattended.

The docs give eight roles, each with the sources to connect and a starter prompt that stops short of acting. The table is the quick map, and the paragraphs after it carry the boundary each role should hold.

The go-to-market roles share one shape. Sales outbound is told to score 25 accounts from a CRM view against an ideal customer profile, find up to three contacts per account, draft email and LinkedIn outreach in attached style examples, skip anyone already in an active sequence and return a review list without sending or enrolling anyone. Talent scout finds 20 candidates for a role description, excludes anyone already in the applicant tracking system, explains the evidence for each match and contacts no one. For talent work the docs add that external outreach stays behind approval and the Bot should respect candidate privacy and each source's terms.

The finance and growth roles are numbers-first. Paid media pulls spend and performance by campaign, compares them with the monthly budget and target customer acquisition cost, recommends reallocations with supporting numbers and drafts a Slack update without changing budgets or sending it. Expense manager builds a weekly summary against an attached policy, matches receipts from the finance inbox, flags missing categories or policy exceptions and drafts one follow-up per owner. The docs ask for a policy citation on every exception and for totals that reconcile back to the source.

The investigation roles separate fact from guess. Product performance reviews dashboards and traces after a release, names the highest-confidence hotspot and returns a short write-up with screenshots and links, keeping facts apart from hypotheses and leaving alerts and production settings alone. Bug reproduction reads a bug report, reproduces it in staging with a fresh test account and returns exact steps, expected and actual behavior, screenshots, browser and OS details and a minimal test case where possible, with no production customer data. Test credentials go through a secure handoff, not chat.

The last two roles are about attention. Account health combines recent usage, support escalations, renewal timing and stakeholder activity into a ranked watch list with evidence, why it matters and a suggested next step, and the docs advise defining risk thresholds in the Bot's description so the weekly result stays consistent. Chief of staff reviews activity since yesterday across approved channels, inbox, calendar and meeting notes, returns only items that map to the priorities in a planning document, and for each one gives the source, why it matters, the proposed next step and whether you owe a decision.

A good first run is not the same as a Bot you can leave alone, and the docs give a six-step path between the two. The point of the order is that automation comes last, after the work has been corrected into something reviewable without you.

1. 1Put the job, source systems, output format and standing boundaries in the Bot's description.
2. 2Run one real task with a safe scope.
3. 3Correct the result until it is reviewable without you.
4. 4Save the working process as a skill and test it on a second input.
5. 5Create a routine only after retries and failure cases are defined.
6. 6Keep consequential external actions behind approval.

Several roles name their own next step once the output is reliable. Sales outbound can move to a nightly research routine that stops at the review list, chief of staff can schedule the digest for a time you can actually review it, and product performance can use a routine for a recurring health report, though the docs say not to use one for unsupervised production changes. Paid media is the strictest case: campaign changes stay behind approval even after the analysis becomes a routine.

The overview page recommends starting with a real task that spans a few tools and has a clear finish line, and it gives a model prompt. Reading that prompt against the roles above shows why it works.

The model task asks a Bot to pull this week's pipeline review list from a CRM, skip anyone already in an active sequence, research the top five accounts across the web and Slack, pull the right contacts, draft outreach in the user's voice and leave drafts to approve by tomorrow morning. It names what to do, where to work, what context to pull in and what finished work looks like, and it ends on drafts for approval, not on sent mail. You then review the result, correct it and turn the stable process into a skill or routine.

I would borrow the structure before the content. Whatever the role, the pieces that carry the weight are a named source, a bounded scope, an explicit output and a stated stopping point. The docs are consistent that the stopping point is where a person looks, and a role that lacks one is the role to rewrite before you schedule it.