28 August 2026 · 5 min read
How to run a team of Grok bots like a project team
A plain breakdown of an experimental Grok Bot setup that treats bot chats as project channels, with a Notion project manager, staffing rules and blocked tasks.
- #AI
- #Grok
- #Workflows
- #Automation
- #Productivity
A post by Eric Zakariasson on X shares a clever way to stop Grok Bot chats from turning into noise: run them the way you would run a human project team. Instead of one long chat per bot type, create one channel per project and staff it with the right bots.
The problem with separate bot chats
Most people start with a Coder chat, a Writer chat and a Researcher chat. That works fine until you are juggling several projects at once. Context gets mixed, updates bleed into each other and it becomes hard to tell signal from noise. The bot does not know which project you are talking about unless you keep repeating it.
The human team pattern
Human teams solve this with projects. Each project gets a spec, a plan and a channel. Within the project, tasks are assigned to different people. Zakariasson copied that pattern almost exactly.
He created two databases in Notion: Projects and Tasks. Then he built a Projects Manager bot, or PM bot, with a /Project Ops skill. That PM handles the meta work: create a project, open a channel and staff it with the right bots.
One project, one channel, one roster
Each project becomes one channel in the sidebar. That channel contains the PM bot, the specialist bots and the user. The roster is visible inside the channel, so everyone knows who is on the project.
Staffing rules keep the system from getting bloated:
• Reuse existing bots first. Coder, Researcher, Writer or any other bot already on the bench gets priority.
• Propose at most five bots besides the PM. Each channel is capped at six bots total.
• Create a new bot only when nothing on the bench fits, and only after the user approves it. The new bot can be a specialist you reuse later, or an ephemeral one that dies with the project.
How the work actually flows
Once the channel exists, the user scopes tasks with the bot roster. The PM watches progress and keeps the Notion databases updated. When a bot gets stuck or needs input, it marks its task as Blocked and pings the user in the channel.
The result is that the user can often watch cards move without having to intervene on every step. The interesting twist is that the more the system grows, the more it looks like a system built for humans: a board, a manager, specialists claiming tasks, a blocked column and a channel.
Why this pattern matters
This is still experimental, but the underlying idea is practical. AI assistants are becoming good enough that the bottleneck is no longer the model. It is coordination. Treating bots as a team rather than as separate chat windows is a natural next step once you use them for real work.
How to try it yourself
• Pick one real project with several moving parts.
• Set up a Projects database and a Tasks database somewhere you can update easily, such as Notion.
• Define a small bench of specialist bots you already use, such as Coder, Writer and Researcher.
• Create one PM bot whose only job is to create the project, open the channel and staff it from the bench.
• Cap the channel size so it does not become a wall of noise.
• Let bots mark tasks blocked and ask for help, instead of guessing.
The productivity takeaway
The best AI workflows will probably look like the best human workflows. Clear project scope, visible roster, assigned tasks and an explicit handoff when something is stuck. Bots do not need new management theory. They need the old one, applied consistently.
Source: post by @ericzakariasson on X, shared 27 August 2026.
