Four Grok Bots Team Up to Build. Why Didn’t Handoffs Break Down?

Multi-agent collaboration has a common failure mode: context is lost during handoff.

The backend Bot says the API is done, but the table schema, error codes, and which cases are not handled all remain in its own thread. When the frontend Bot takes over, all that’s left is one sentence.

Akshay’s solution: state lives on disk, not in chat messages. He used Grok Bot to build a four-person engineering team. Four roles, one shared cloud computer, one file-based task board, and they shipped a real feature: password reset.

Four roles

Piper is the project manager. She breaks requirements into tasks, maintains the task board, and checks every handoff document. She doesn’t write application code. Her most useful behavior is rejection: if a handoff document lacks file paths, API contracts, or a list of unfinished work, it gets sent back rather than passed along.

Bay is the backend developer. It handles the database, APIs, server-side logic, and the InsForge backend itself. It doesn’t touch the UI, and at the start of every task it asks “what is actually there now?” instead of relying on memory.

Fin is the frontend developer. It builds the interface according to the contract Bay wrote. When the contract is missing or vague, it stops and asks Piper instead of guessing field names. It also doesn’t change server-side contracts. When it needs a new API, it marks the task as blocked instead of working around it.

Tess is testing. She writes test plans against acceptance criteria, files issues as separate files, and sends them back to the corresponding role. She never fixes bugs she finds herself: a tester who secretly fixes bugs will soon stop reporting bugs.

All four Bots run the same model; the differences come from role definitions, context, and skills, not from a model selector.

The key is files, not prompts

A defining feature of Grok Bot is that all Bots under one account share one always-on cloud computer. Files, browser login state, and command-line credentials all live on that machine. A file written by one Bot is read directly by another.

Tasks, project context, and handoff notes are all stored as files. Messages only carry paths. After the backend finishes, the table schema, error codes, and unhandled cases are written into a handoff note; when the frontend opens the file, it gets the full context. The next Bot never starts cold.

The task board is a directory: board.md is the index, each file under tasks/ is a ticket, and handoffs/ holds handoff records. Only Piper writes board.md, avoiding two Bots writing the same file at the same time and silently losing updates.

The backend doesn’t guess

In this team, Bay uses InsForge to operate a real backend. InsForge is an open-source backend platform providing Postgres, auth, storage, edge functions, and a model gateway. Unlike a traditional dashboard, agents can use the CLI to read the current environment directly: npx @insforge/cli metadata returns table schemas, RLS policies, auth configuration, and deployed functions in one command.

Traditional backends have three problems when used by agents: documentation retrieval dumps everything into context; there is no complete view of state; and error messages are returned raw, so when an agent sees a 403 it guesses the cause, and if it guesses wrong it retries. InsForge’s skills load only descriptions at startup and load full text only when matched to a specific task, so installing all four skills won’t blow up the context.

A real run

The first feature the team ran was password reset. The requirement said “expire in 30 minutes, revoke old sessions,” but after checking the project Bay found that this was only an assumption in the requirement; the project did not actually have this configuration.

Bay did not guess a value just to make the task pass. It didn’t write a handoff document, marked the issue as Blocked, and sent it back to Piper. Piper passed the issue back to the human user for a decision. After confirmation, the task was reopened with an explicit requirement not to invent a TTL.

After Bay implemented it, the handoff document clearly stated that “the actual expiration and session behavior are platform defaults,” without making up numbers. Fin continued according to this document, and Tess also noted during verification: 30-minute expiration and old-session revocation were not tested because they had been moved out of scope.

From requirement to launch, the whole feature actually took a few minutes, with only one human decision in between.

Boundaries and questions

Someone in the comments asked: if Bay changes the API after Fin has already developed against the contract, can Piper catch it during handoff, or will it be dragged all the way to Tess’s stage? Others argued that having agents review each other is exactly how a wrong schema starts shipping with confidence.

These are real boundaries. Akshay’s approach works only if every handoff document is specific enough, and document quality depends on the person who defines the document format. He summed it up in one sentence: handoff quality is a file-format problem, not a prompt problem.

The full prompts, setup steps, and InsForge configuration are in Akshay’s original article. InsForge is open source on GitHub under Apache 2.0: InsForge/InsForge.