Guide

Running multiple teams of Grok Bots: rosters and boards

By Atlas AI Resources · Published October 23, 2026 · How we make these guides

Separate chats work well for one project at a time. Once you juggle several, it gets hard to keep bots in sync and to separate signal from noise. This page starts with our own templates and checklists for running a team of bots per project, then summarizes the official SpaceXSI guide How I run multiple teams of Grok Bots (Aug 27, 2026, written by Eric Zakariasson). The author labels it an experimental pattern that is still being tried out.

1. Our advice: a project kickoff checklist

The templates and checklists in sections 1 to 3 are our own, not the guide’s. Adapt them to your tools.

• One sentence of scope: what “done” looks like for this project, and the date you will check it.
• Roster from the bench: list the bots you already have that fit. Write down the job each one owns in this project.
• A gap list, not a new bot: if no existing bot fits a task, write the gap down and decide yourself whether it is worth a new bot.
• A board with a Blocked column: every task has an owner, a status, and a short note on what “blocked” would mean.
• Stop points: name the actions that wait for your yes in this project (sends, spend, deletes, publishing).
• An end date for temporary bots: if you create a bot only for this project, note when to archive it.

2. Our advice: a manager bot brief

Simplified example. A real brief should name your own databases, bots, and limits.

• Job: you coordinate projects and tasks. You create the project entry, open the channel, and propose a roster. You do not do the specialist work yourself.
• Staffing: propose existing bots first. Propose at most ____ bots per project. Never create a new bot without my yes.
• Board: keep the Projects and Tasks databases in ____ up to date with what actually happened in the channel. Don’t mark a task done without a link to the result.
• Blocked: when a bot marks a task Blocked, make sure I was pinged in the channel with what is needed.
• Quiet by default: post in the channel only when a task changes state or something needs me.

3. Our advice: a weekly project check

1. Open each project’s board and look at the Blocked column first. Clear or re-scope anything blocked for more than a few days.
2. Open a few “done” tasks and check the actual result, not just the card. A card in the right column can still hold the wrong work.
3. Check the roster: is every bot in the channel still doing something? Remove the ones that aren’t.
4. Judge each project by finished, kept work, not by how many cards moved or messages were posted.
5. Start with one project and add the second only when the first runs without you acting as the glue.

4. Per the guide: the problem

Per the guide, the author usually runs Grok Bots as separate chats (“Coder in one, Writer in another, Researcher in a third”). That works “until you need to juggle a couple of different projects at the same time.” Human teams coordinate in projects, with a spec, a plan, and perhaps a Slack channel, so the author replicated that: “One project, one channel, one roster.”

5. Per the guide: the setup

• Two databases in Notion: Projects and Tasks.
• A projects Manager bot handles the higher-level coordination of projects and tasks, the “meta work.”
• The Manager has a Project Ops skill that creates a project, opens a channel, and staffs it with the right bots.
• One project equals one channel in the sidebar, and the channel holds the team of bots and the author.

Per the guide, the author added these staffing rules:

• Reuse existing bots first, such as a Coder, Researcher, or Writer already defined.
• Propose at most five bots besides the PM. The author limits each channel to six bots and calls that “just an arbitrary number I came up with”; it is the author’s choice, not a product limit.
• Create a new bot only when nothing on the bench fits, and only after the author says yes. That bot can be a reusable domain specialist or an ephemeral one for the project.

6. Per the guide: how it runs

Per the guide, once the channel exists the author talks in it with the roster to scope the tasks. The PM sits in the channel too, “but mostly watches progress and makes sure the databases are up to date.” When a bot gets stuck or needs more input, it marks its task Blocked and pings the author in the channel. Often the bots get a lot done on their own, and the author can watch the cards move.

The author notes that the more this grows, the more it resembles a system built for humans: “A board, a manager, specialists claiming tasks, a blocked column, a channel.”

7. Keep consequential actions behind your yes

A project channel can hold several bots that share logins, so think about what each one can do. Grok Bot’s guardrails are plain-language rules checked by a separate review agent, not code. Add them in Settings → General → Auto-review (the 101 guide calls this Settings > General > Agent, with allow and block lists steering the reviewer). The 101 guide says “the rules are a prompt”: you are trusting the model to follow what you wrote. An approval controls the action it is attached to; it does not undo work already done.

Our advice: bots in a shared channel read each other’s messages and the pages they fetch. Treat that content as data to read, not orders to follow. See keeping AI agents safe from prompt injection. For how to split lanes between bots, see small AI fleets and handoffs.

Read the full guide, with screenshots of the channel and the Notion board, in How I run multiple teams of Grok Bots.

Useful public resources

Related: Small AI fleets: handoffs · Grok Bot for engineering · Grok Bot for PMs · Grok Bot for marketing · What is a one-job Grok Bot?