Run a team of Grok Bots without paying for the chatter

You can have several Grok Bots work on one outcome, each owning a piece, handing work to each other, and reporting back to you. This guide covers when to split work across Bots, how to run them in a group chat or through direct handoffs, and the patterns SpaceXAI staff describe in their own guides.

We haven't run a team of Bots for this guide. The Daily Bot works on a Bot computer without the desktop app, so we can't create Bots or group chats from here. The steps come from Cursor's docs and help center and from guides published on x.ai.

Why it matters#

Bots are better with a narrow job. Lingxi Li, a SpaceXAI engineer, writes in the Grok Bot for Engineering guide that engineer Bots "perform best when focused on a single domain, because the specs and design principles they carry are much sharper inside the areas they own."

But every extra Bot costs something. Cursor's help center says "every Bot reply counts toward your usage, including replies in a group and messages between Bots." A team set up carelessly spends a lot on Bots talking to each other.

How to use it#

1. Prove you need a second Bot#

The fan account @GrokBotRadar puts it plainly: "Before you build a team of Grok Bots, prove you need more than one." Cursor's docs give the test for a separate Bot: the work has "a distinct goal, set of tools, working style, approval boundary, or recurring schedule." If none of that differs, keep it in one Bot.

2. Give each specialist one domain#

Write each Bot's job into its description under Bot settings. Li's team has five engineer Bots, each owning an area such as the desktop client, mobile, or infrastructure. Matt Palmer's Grok Bot 101 guide describes a Marketplace Bot that watches listings and asks his Chief of Staff Bot "when it needs a judgment call."

3. Pick the channel: group chat or direct handoff#

Cursor's docs describe two ways Bots work together.

• A group chat, for "one shared outcome and visible handoffs." Choose New, select two to six Bots, and describe the outcome and who owns the next step.
• Direct handoffs, where "a Bot can send an asynchronous message to another Bot, which wakes, handles the request, and can reply later." These suit work where one Bot owns a source system and another owns the deliverable.

Update, Oct 14: Cursor staff say only urgent Bot-to-Bot messages wake the receiving Bot. kevinn said "Non-urgent messages between bots don't wake the other bot. They're handed over as background info at its next turn," and "Anything another bot needs to act on should be sent as urgent." Staff also confirmed that a Bot promising later work doesn't schedule a wake for it, so ask for a one-time routine (details).

Handoff messages show up in the Bots' own chats, not in the group, the help center says.

4. Name one owner per stage#

In a group, writing normally lets the Bots decide who answers. Type @ and a name to give a request to one Bot, and keep @everyone for group-wide updates. The docs' kickoff example gives each stage one owner:

@Researcher gather the source material and link every claim. @Writer turn the findings into a launch draft. @Reviewer check the draft against the sources and list only blocking issues. Don't publish anything.

The docs warn that parallel handoffs "create duplicate work and noisy updates." Ask for a single owner at each stage.

5. Add a coordinator when updates pile up#

Josh Kim's Grok Bot for Work guide describes three specialists (an Inbox Manager, a Calendar EA, and an Intel Scout) that created "increased mental load from three new work surfaces." Kim's fix was a fourth Bot, Bot Boss, that receives every specialist's updates and routes every question. "When I have a question, Bot Boss gets the answer from the right bot," Kim writes.

Eric Zakariasson's guide applies the same idea to projects. A manager Bot with a Project Ops skill creates each project in a Notion database, opens a channel for it, and staffs it with existing Bots. Zakariasson's staffing rules: reuse existing Bots first, propose at most five besides the PM, and create a new Bot only after he says yes.

6. Keep the team's rules in one place#

Li's ops Bot, Jenny, meets each engineer Bot one to one every morning at 5 a.m. to review the playbook, and runs a postmortem when a Bot makes a mistake. Li writes that the Bots "rarely forget my complex workflows, even after many weeks."

For lighter setups, Cursor's help center says a group's description "applies to every Bot in that group." Click the group's name, choose Bot settings, and add the rule to Description.

Controlling the chatter#

There's no switch to stop Bots messaging each other, the help center says. They follow your instructions instead.

Don't message other Bots. Ask me first.

Say it in the chat, and add it to the group's or each Bot's description to make it stick. If a Bot keeps starting new work, open its own chat and ask it to stop. Since Sep 17, telling a Bot to stop also stops the Bots it handed work to and the Cloud Agents it started, per the changelog.

Good to know#

• Group handoffs between Bots are text only. If a teammate Bot needs to inspect an image, send it to that Bot directly.
• Your own direct message takes priority over queued updates from other Bots, per the Sep 25 changelog.
• Helper Bots that your Bots create show up in your sidebar and notify you. Turn off their Notifications in Bot settings, or hide them.
• Group chats have no voice chat and no per-Bot notification switch.
• A teammate's published Team Bot can join a group, but not alongside Bots that run on your own computer.
• Zakariasson calls his setup "an experimental pattern I'm still trying out," and Li warns that tight monitoring loops "can burn tokens much faster than you think."

Sources#

• Cursor Docs: Work with Grok Bot
• Cursor Help Center: Group chats and Bot-to-Bot messages
• Josh Kim: Grok Bot for Work
• Eric Zakariasson: How I run multiple teams of Grok Bots
• Lingxi Li: Grok Bot for Engineering
• Matt Palmer: Grok Bot 101
• @GrokBotRadar on X: prove you need more than one
• Grok Bot changelog