When does a group of Grok Bots help, and when should you talk to only one?

Talk to one Grok Bot when one role can own the outcome from start to finish. Use a group when several Bots must share one result and you need the handoffs visible. A group is two to six of your Bots in one chat, not a second cloud computer and not a Team Bot the whole company messages. They still share your account’s computer and its logins. The group changes who speaks and who you can watch. It does not split the machine.

The manage-Bots docs say to start with the smallest roster: one Bot owns an end-to-end outcome, you add another only when the work has a stable specialist role, and you put them in a group when the handoff itself needs to be visible. External actions stay behind an approval boundary. That is the whole decision. Parallel screens are real. A second personality is not a reason to open a group.

When does one Bot finish the job?

When the work is one thread of judgment. A single inbox, a single draft, a single research pass, a routine that one role already knows how to run. That Bot has its own conversation and its own learned context. It has one screen on the shared computer, and it runs one computer-use task on that screen at a time. You are not the router. You message it, it works, it comes back when it needs a decision.

One Bot is also the right call when the thing you are protecting is a login. Your Bots share one cloud computer and its logins. Adding a “careful” Bot next to a “fast” Bot does not give the careful one a private browser. If only one role should ever see a mailbox or an admin session, do not invent a second Bot to hold the temptation. Leave that login off the computer, or do not give the job to this account’s roster at all.

One Bot is the right call when you would otherwise become the middleman for no reason. The product pitch is that Bots can message each other so you are not pasting notes between chats. If there are no notes to pass, a group is a meeting. You will spend the turn naming owners for a job one person, or one Bot, could have carried. The create-a-Bot guidance says your existing Bots can suggest a focused Bot when a slice of work should have its own owner, and that you should ask before creating several. Keep the roster small on purpose.

When is a group the right room?

When the outcome is shared and the handoff is the thing you might get wrong. The collaboration docs say to use a group in that case. On the desktop you choose New in the sidebar, then in New chat you select two to six Bots, open the group, and edit the generated name if you want. On iPhone or Android the path is plus, then New Group Chat. Membership can be edited later. The first message should name the shared outcome and who owns the next step.

You can write normally and let the Bots decide who responds. Type @ and pick a Bot when one teammate owns the request. Mention several only when each of them actually has a part. @everyone is for a rare group-wide update, not for every kickoff. Bots can post into the group and pass work among themselves. A kickoff the docs use as the shape, not as a script you must paste, names a researcher to gather sources, a writer to draft, and a reviewer to list blocking issues, and it says not to publish. The useful part is the ownership, not the three job titles.

Their example of a standing group is a website launch: a coordinator, a content editor, an analytics reviewer. The coordinator assigns. The group keeps the handoffs in one conversation. That is a group earning its keep. Three Bots all “helping with email” is not, because there is no specialist boundary and no handoff you need to see.

What can a handoff do, and what can it not carry?

A Bot can send an asynchronous message to another Bot. The receiver wakes, does the work, and can reply later. You can see that handoff in the conversation. The docs list the cases: one Bot owns a source system and another owns the deliverable, a specialist should review a draft, a blocker belongs to another role, or a long job should continue without you coordinating every step. Ask for a single owner at each stage. Too many parallel handoffs create duplicate work and noisy updates. Each Bot still has only one computer-use task on its own screen at a time, so “parallel” means several screens, not one Bot doing five browser jobs at once.

Your own messages in the group can include attachments. Bot-to-group handoff messages are currently text-only. If another Bot must inspect an image, the docs say to send that image directly to that Bot. A group is a bad place to assume a screenshot hopped across with the paragraph. Say which file on the shared computer they should open, since files are already visible to every Bot on the account. The text handoff is the assignment. The file is the artifact.

Direct messages between Bots still exist when you do not need the room. Use the group for the visible chain. Use a direct handoff when the rest of the roster would only add chatter. Conversation memory stays per Bot until something moves it: a file, a group message, or that direct handoff. Do not expect Bot B to know a preference you told Bot A last week unless you handed it over.

What should stay a human decision inside the group?

Sending, purchasing, deleting, publishing, and changing production systems. The routines guidance says to require approval for those. A group does not get a free pass because three Bots agreed. Auto Review can still stop an action for a tap, and ask-first rules beat allow-automatically rules. Put the approval in the kickoff in plain language, the way the sample kickoff says not to publish. Then keep the product setting that matches the sentence. A paragraph in the chat is not a substitute for the rule if a Bot can act from the shared browser without you.

Also leave the owner human when the next step is a judgment you did not define. “List only blocking issues” is a Bot job. “Is this the version we ship” is yours. The launch stories about Bots pulling you in only for judgment calls are describing that pause. They are not a promise that a group will know your standard on day one. Role context compounds per Bot. A new reviewer Bot does not inherit the editor’s taste except through what you handed it.

How is this different from a Team Bot?

A group is your Bots talking to each other on your account. A Team Bot is one Bot the owner publishes so teammates can chat with that same Bot, in the Grok Bot app or in Slack, without each person starting from scratch. Sharing a template link creates a copy on someone else’s account. The docs are explicit that the copy does not include your computer, your logins, or your conversation history. Publishing a Team Bot is how you give the team one Bot they all talk to, rather than a copy each person customizes.

If the question is “should my researcher and my writer sit in one room,” you want a group of your Bots. If the question is “should the company message one assistant,” you want a Team Bot, and the Slack rules are different again: it answers DMs, and in channels it answers when mentioned, then follows that thread. Do not build a six-Bot group to imitate a team inbox. That is a different product surface, with its own connector approvals. In a shared Team Bot conversation, a personal connector asks before it is used. That ask is about teammates and plugins. It is not the same control as your private group of Bots on one shared computer.

What does coming back to the group look like?

The work did not need the phone to stay open. A background turn and a routine keep going on the cloud computer after you lock the screen or close the app. The group transcript is where you see what the Bots told each other. Open it and look for a named owner, a file path, and a stop at the approval you asked for. A pile of three drafts and no owner is the failure the docs warn about: parallel handoffs with nobody accountable for the stage. Hide a Bot you are not ready to delete. Deletion removes that Bot’s profile, conversation, and routines, and files on the shared computer can remain. The group getting smaller does not clean the disk.

If status in the chat is ambiguous, ask the owner Bot, in that group, what it finished and what it refused to do. Do not ask all of them the same question and then try to vote. That is how a group recreates the middleman job you were trying to leave. One answer, from the Bot who owned the stage, is the check. The others can stay quiet until the next handoff names them.

A practical cut

Start with one Bot and a finish line. Add a second only when you can name the role in a sentence that would still make sense next month. Open a group, two to six Bots, when you want those handoffs in one transcript and you will name a single owner for each stage. Stay in a direct chat when the extra voices would duplicate the work or when the only difference between the Bots is a vibe. The computer underneath does not multiply with the roster. The clarity of the owner does, and that is the part you still have to write.