A Guide to Running Multiple Grok Bot Projects: One Channel, One Roster, and a Two-Tier Notion Board

When you only use one or two AI bots to handle ad-hoc chores, opening two separate chat windows on the left—one for writing code and one for copywriting—is certainly intuitive enough. But if you are pushing two or three complex, real-world business projects forward simultaneously, this "1:1 chats" model quickly descends into chaos: context is fragmented into pieces, it becomes difficult to tell who is driving what in a low-signal window list, and having bots responsible for different stages sync their progress with one another is practically impossible.

xAI engineer Eric Zakariasson shared an organizational model he developed in an engineering guide. His core idea is straightforward yet hits the critical pain point of multi-agent deployment: Since human teams collaborate using a "project-based" model, why not directly port this proven human workflow to AI wholesale?

In human organizations, every project has its own project specification (Spec), action plan, dedicated communication group (such as a Slack channel), and a task board assigned to specific owners. Eric mapped this mechanism onto Grok Bots, distilling it into a cohesive organizational unit:

One project = a dedicated channel in the sidebar + a fixed roster of members + a two-tier board in Notion.

This is not presented as an official, cure-all definitive solution, but rather an experimental collaboration framework being continuously iterated in real-world work.

The Backbone of the System: A Two-Tier Notion Database and the "Projects Manager" Bot

To get multiple bots to collaborate like a team, you must first separate high-level project meta-work from concrete execution details.

Eric set up two linked underlying databases in Notion to manage macro-level projects and micro-level tasks respectively:

1. Projects Database (Project Board): Tracks the lifecycle of macro-level projects. The board columns include Planning, In progress, Paused, and Backlog. For example, developing a TypeScript client SDK or building a leaderboard feature in official examples exists here as distinct project cards.
2. Tasks Database (Task Board): Records atomic execution items. Every task card is strictly linked to its parent Project. The core status columns on the board include Todo, In progress, Blocked, and Done.

Once the data structure is in place, how do you drive it? If humans had to manually create groups, invite members, and update statuses every time, efficiency would actually regress. Therefore, the central hub of the entire system is a resident agent named Projects Manager (PM).

The original text assigns the PM Bot the responsibility of project operations and meta-work. It is equipped with a dedicated skill named Project Ops, specifically tasked with three duties:

• Kicking off projects and creating channels: Establishing a dedicated channel in the Grok Bot sidebar matching the new project name;
• Staffing the team: Selecting the most appropriate specialist bots from the "bench" based on the nature of the project and adding them to the channel;
• Syncing boards: Silently listening in on group discussions and maintaining project and task entries in Notion in the background.

Staffing Rules: Keeping Team Sizes Lean with Human Gates

The easiest pitfall for many multi-agent systems is allowing the model to spawn new sub-agents without restraint, resulting in context explosion, overlapping role responsibilities, and a severe dilution of compute and attention.

In practice, Eric established three disciplined Staffing Rules for the PM Bot:

1. Reuse existing bots first: Never create new roles indiscriminately. When kicking off a project, the PM must first inspect the existing "bench" and prioritize adding pre-defined general-purpose roles, such as Coder for engineering, Researcher for investigation, Writer for copy, etc.
2. Strict team size limits (At most five bots besides PM): Besides the PM, each project channel may propose adding at most 5 specialist bots, capping the total number of bots in a single channel at 6. Eric notes that 6 is an arbitrary number he personally chose rather than an unbendable physical or technical ceiling; the author did not provide comparative tests on team size, so readers can adjust the headcount according to task requirements.
3. New roles require human approval (Create a new bot only after I say yes): Only when existing bench members are completely incapable of handling the task may the PM propose creating a new bot, and it must wait for the human to explicitly agree ("say yes") before executing the creation. Depending on project needs, new roles can either be retained as long-term reusable domain specialists or treated as ephemeral bots serving only the current project.

Real-World Operating Mechanism: From Scoping to "Explicit Blocked" Routing

Once the project channel, member roster, and Notion board are in place, how does a complete workflow operate? We can break it down into four sequential stages:

1. Collaborative Scoping Inside the Channel

The human lead enters the newly created channel and engages in direct dialogue with the specialist bots on the roster. Together, they break down the project's broad objective into discrete, actionable tasks. This process mirrors a human team's scoping meeting: the human outlines constraints and expectations, while specialist bots flesh out implementation paths.

2. Silent Monitoring and Bookkeeping by the PM Bot

Throughout the discussion, the PM Bot remains in the channel, but mostly stays quiet without interrupting. Its primary role is to serve as a background monitor: parsing conversation conclusions, ensuring scoped tasks are accurately recorded into the Notion Tasks database, and keeping the database updated as the project progresses.

3. Task Execution and Board Visualization

Once responsibilities are established, specialist bots (like Coder) independently pick up and execute their respective task cards. As work commences, cards in Notion are automatically moved to In progress. The human lead no longer needs to constantly ask "How's progress?"; watching the cards flow across columns on the board is enough.

4. Core Fault Tolerance: Explicitly Tagging Blocked and Pinging Humans

When a specialist bot hits an unexpected snag during execution—such as missing specific credentials, encountering external API errors, or facing ambiguities in instructions—its configuration requires it to stop cleanly and ask for help.

Its standard operating procedure is: immediately update the task card's status to Blocked, and then explicitly @mention the human lead in the project channel, explaining the blocker and waiting for the human to provide supplementary information.

This design thoroughly frees human effort from "micromanaging every step of execution," shifting humans into the high-leverage role of "setting objectives + acting as a blocker remover."

Prompt Configuration Reference for Team Coordination

The original article did not include the full contents of the Project Ops skill, but based on its operating mechanics and the three staffing rules, the configuration reference below has been adapted by the editor; adapting this on other platforms also requires capabilities to create channels, manage bots, and update boards.

The following configuration examples faithfully recreate Eric's project-based collaboration logic. Values and names use placeholders so readers can adapt them to their own toolchains (such as substituting Notion with Lark Base, DingTalk AI Tables, or GitHub Projects).

1. Projects Manager (Project Coordinator Bot) Configuration Reference

Configuration Example Adapted from This Workflow

Role Definition: Project meta-work coordinator, responsible for creating project channels, staffing teams, and syncing boards.

Operating Principles and Hard Constraints:

1. Bench First: When receiving a request to create a project, check the existing roster ([List of available bots, e.g., Coder, Researcher, Writer]) first. Creating new bots outright is strictly prohibited.
2. Headcount Cap Gate: Beyond yourself, each project channel may propose adding at most [5] specialist bots; the total number of bots per channel must not exceed [6], excluding human members.
3. Creation Approval Gate: If no existing bench members match the project's domain requirements, you may propose creating a new bot to the human lead, explaining the rationale and outlining the proposed role. However, you must wait for explicit human approval before calling the creation interface.
4. Silent Background Maintenance: Keep message frequency minimal within the project channel. Focus on listening to task delegations and status shifts in chat, ensuring that the [Projects Database] and [Tasks Database] remain up to date in real time.

2. Collaboration Contract Reference for Specialist Execution Bots (e.g., Coder / Researcher)

Configuration Example Adapted from This Workflow

Role Definition: Specialist executor in the project channel, responsible for claiming and delivering concrete tasks.

Blocked and Escalation Protocol:

1. Claiming and Starting: Upon claiming a task, update the associated Notion task status to In progress and commence execution.
2. Blocker Circuit Breaker (Blocked): When unable to proceed due to any of the following reasons, faking execution results or endlessly retrying blindly is strictly forbidden:
   • Missing required configuration, environment dependencies, or authentication credentials;
   • Logical contradictions or insufficient context in requirement specifications;
   • Consecutive execution failures exceeding [your configured threshold] times.
3. Trigger Escalation: Once blocked, you must take two sequential actions:
   • Step 1: Change the task's status on the task board to Blocked;
   • Step 2: Send a message in the project channel adhering to the format: @Human Lead [Brief description of blocker]. Missing information required: [Specific list]. Wait for the human's response before resuming execution.

Takeaways for Everyday Work

As Eric reflected at the end: The deeper you build this multi-bot collaboration system, the more it mirrors the system originally designed for humans—a task board, a dispatch manager, a roster of specialists claiming work, a prominent Blocked column, and a dedicated communication channel.

For readers looking to deploy persistent agents in real-world workflows, this experimental framework offers three practical takeaways:

1. Move past the myth of the all-in-one chat box: Avoid stuffing every project background, coding standard, and business objective into a single lengthy conversation. Break complex initiatives into separate "project channels" to naturally isolate context noise across different workstreams.
2. Make implicit state completely external: The greatest danger of running background agents is the black box. By externalizing tasks onto a visual board with four standard columns (Todo, In progress, Blocked, Done), you can see team-wide status at a glance anytime.
3. Explicit blockers provide the ideal human-agent handoff interface: Humans should neither act as full-time babysitters nor remain entirely hands-off. Having agents clearly raise a red flag (Blocked) and call for help when stuck represents the most sensible seam balancing automation and reliability today.