Grok Bot teams: one Bot or multiple Bots?

Use one Grok Bot when one stable owner can complete the job with the same sources, output, and approval rules. Add another Bot only when ownership genuinely changes—not to create a decorative org chart.
The official FAQ says each Bot keeps role-specific context and memory, while files, browser sessions, logins, group messages, and direct handoffs can move context between them. All Bots on one account share the same cloud computer, so separate Bots are not a credential or security boundary.
One Bot is enough when
- The work serves one durable outcome.
- It reads the same sources and returns the same kind of result.
- The same person reviews consequential actions.
- Its schedule and failure rules are coherent.
- A new instruction would refine the role rather than create a different owner.
A research Bot that gathers sources, compares evidence, and writes one brief does not need a separate “link finder,” “reader,” and “summariser” unless those stages have different access or durable ownership.
Add a specialist when
- The job requires different accounts or narrowly scoped permissions.
- Its output and quality test are materially different.
- It runs on a separate clock or event.
- Its approval boundary belongs to a different person.
- It needs stable role knowledge that would distract or conflict with the first Bot.
For example, an inbox triage Bot can prepare tasks while a finance Bot reconciles invoices. The inbox Bot should not inherit financial authority merely because both can see files on the shared computer.
Give every Bot a contract
- Owns: the result it is responsible for.
- Reads: named sources and accounts.
- Returns: a defined artifact and destination.
- Asks: decisions or missing facts it cannot infer.
- Stops: actions requiring approval.
- Hands off: the exact object, source links, state, and remaining question.
The official Bot guide describes named Bots with separate roles and conversations. The files and results guide explains how files can carry durable work between conversations and Bots.
Share context without pretending memory is global
Use a short source-of-truth file, a group conversation, or a direct handoff. Include current facts, links, decisions, and the next owner. Do not assume every preference, hidden instruction, or past conversation automatically synchronises across the team.
A community personal-team thread and a shared-context discussion show demand for team recipes and global instructions. They are design ideas, not platform guarantees.
Keep one security boundary in mind
All Bots on the account share the cloud computer's files, sessions, and command-line credentials. Connect only what the roster needs, remove temporary sensitive files, sign out when access should end, and do not create a new Bot as a substitute for revoking access.
Team rule. Split ownership, not security theatre: one result has one owner, every handoff carries evidence, and every consequential action keeps its real approval boundary.
The recipe
Get the bots this setup runs on.