14 Bots, Only 4 in the Conversation: Multi-Agent Teams Get Stuck on Handoff Files

One easily misunderstood point about Grok Bot is that the Bots look like independent employees, but they actually all run on the same persistent cloud computer under one account. Akshay Pachaar demonstrates this in a video and a long post: he created 4 engineering Bots and has them take requirements, write the backend, write the frontend, and run tests like a small company. The video is above, and the long post is here. The video chapters cover computer use, connectors, teaching skills via screen recording, routines, and how to scale from 1 Bot to 14 Bots.

First, some background. Grok Bot is a SpaceXAI product. Each Bot is a named role with its own conversation thread and memory. All Bots under an account share one cloud computer; files are written to /workspace, and a file saved by one Bot can be read directly by another. Each Bot has its own screen and can do computer operations in parallel, but a single Bot runs only one computer-use task at a time. An account can hold up to 50 Bots and group chats, and group chats usually contain 2 to 6 Bots. In another guide, Avi Chawla compares the shared computer to an office: Bots are colleagues, each with a desk, sharing a filing cabinet and keys.

The problem is also here. The most common failure in multi-agent systems is that context is lost during handoff. The backend Bot says the API is ready, but the data structures it chose, the error codes, and the edge cases it did not handle all remain in its own thread. When the frontend Bot takes over, it sees only one sentence. Another approach is to cram everything into one Bot; the thread gets longer and longer, early decisions get pushed out of the window, and the Bot starts fighting with its own earlier choices. Akshay's judgment is that these two failures have the same root: messages are carrying state, and chat messages are not suited to that.

Grok Bot's structure happens to avoid this. State lives in files on disk, and messages carry only paths. The incoming Bot opens the task file, reads the API contract, checks what the previous owner marked as not done, and then starts. Akshay validated this workflow with four roles:

• Piper is the project manager. She breaks down tasks, manages board.md, orders tasks, and reviews handoff notes. She does not write application code.
• Bay is the backend. It owns the API, data models, migrations, server-side tests, and the InsForge backend. It does not touch the UI.
• Fin is the frontend. It owns components, client state, and integration with the APIs exposed by Bay. It does not change server-side contracts.
• Tess is testing. She writes test plans, runs verification, and files bugs. She does not fix the bugs she finds.

The rules are strict. Only Piper can write board.md, because the four Bots share a filesystem and may run in parallel; if two Bots edit the same file at the same time, edits can be silently lost. One file per task. The template includes owner, status, depends_on, blocks, goal, acceptance criteria, and which context to read first. Handoff notes must include exact file paths, the complete API contract, every unspecified decision that was made, and everything that was deliberately not implemented. If any item is missing, Piper sends it back. There is also a reason Tess does not fix bugs: if a Bot casually fixes its own findings, it will under-report problems, because the fastest way to make tests clean is to quietly fix them.

The setup order is not complicated, but there are many details. First create the four Bots, use a fixed description to have them write their names, roles, and rules into their profiles, then have them read it back to confirm they did not take shortcuts with a summary. Next, have Bay log in to the InsForge CLI, create a project, link tables, and install skills. For every task, Bay first runs npx @insforge/cli metadata to see the current real state rather than relying on memory. Then Piper creates the project directory, board.md, the context folder, tasks, and handoffs. The context folder contains architecture.md, conventions.md, and glossary.md. Akshay says this is the highest-leverage twenty minutes of the entire setup, because everything the Bots no longer need to ask about is here.

The first message in the group chat is also critical. Grok Bot does not automatically know that the four Bots are on the same project. In the group chat, Akshay spells out who is responsible for what; by default, conversations go back to private chats, and the group chat is used only to announce handoffs, raise cross-layer blockers, and answer direct mentions. If you are not mentioned, you do not need to reply. Then have Bay build the backend first and Fin do the frontend, with Fin going to Bay directly for the table schema. There is a detail here: coordination is not created by the task board; the task board just makes coordination orderly. Once the code exists, Piper writes the context from the actual code, not from the plan. Finally, create the task board and templates and run the first complete feature: password reset.

The most illustrative part of this example is that Bay stopped. Akshay wrote 30-minute expiration and invalidation of old sessions into the requirements, but the project's actual configuration did not have these two items. Bay did not guess a value to make the task pass; it handed the problem back to Piper. Piper moved the task to Blocked and asked a human. After the scope was confirmed, Bay recorded the platform's default expiration and session behavior without inventing numbers. In the notes, Tess finally stated that 30-minute expiration and old-session invalidation were not tested because they had been moved out of scope. The system did not pretend everything went according to plan; it exposed the assumptions.

Akshay calls this a state machine: the board holds state, handoff notes are transitions, and Bots are workers that read and then act. His conclusion is that handoff quality is a file-format problem, not a prompt problem. That judgment is worth remembering. To make multi-agent systems reliable, first specify what a note must contain, then make the skill refuse to write incomplete notes.

But do not rush to build 14. The video title mentions 1 to 14 Bots, [but he] only talks to 4. In the comments, someone asks how you know when the other 10 quietly stall; someone else asks how fast 14 Bots burn through the weekly limit. Akshay replies that with the $30/month plan he can last 7 days, and he hands a large share of coding tasks to Claude Code, which already has a subscription. Avi's guide warns that a shared computer means shared browser sessions and command-line credentials, and Bots are not a security boundary. It is fine for running experiments, but be cautious about cramming production projects into the same account. Avi also compares it with Hermes: Hermes turns memory and skills into readable files, offers stronger isolation, and requires you to operate the machine yourself; Grok Bot turns collaboration into a product capability, with less maintenance and weaker isolation. The choice depends on what you are willing to log in to a computer you cannot see.

If you just want to try it, start with one narrow Bot, run one real task, revise it until the output is reviewable, then save it as a skill, and only then make a routine. If you assemble 14 Bots on day one, you will most likely get 14 employees who quietly stop. First make it possible to send handoff notes back, then talk about a company.