Grok Bot Gave My Coding Agents a Boss

Grok Bot rapidly became the control room for my army of bots: filing bugs, dispatching parallel Cursor workers, rejecting weak work, and returning fixes for acceptance testing—with less help from me than I expected.

At 4:13 Friday afternoon, the Researcher bot started reporting bugs to the Software Director.

The director was not just accepting the reports and filing them. It was turning them into separate workstreams, dispatching parallel Cursor agents to my Mac, reviewing what those agents returned, rejecting work that did not meet its requirements, combining the accepted changes, and delivering the result back to the Researcher. The Researcher was the client. It checked whether the software actually solved the problem and sent it back when it did not.

I was watching software manage software.

I had named the roles. I had given the Software Director instructions to be hard on coding agents when it reviewed their work. Early on, I sometimes told one agent to ask another for help. But I was no longer carrying every message or specifying every handoff. The roles had started collaborating through the responsibilities I gave them.

The org chart was moving.

This is completely nuts.

While one bot waited for a deployment, it handed a research question to Papyrus and brought the answer back into the same conversation.

The moment it stopped feeling like another coding agent

Grok Bot belongs in the same broad category as Cursor, Claude Code, Codex, and Google Antigravity. An agent gets a computer, uses tools, and is supposed to return with finished work. On a feature checklist, very little of that sounds new.

The experience is new because the machinery disappears.

On the first night, a bot went live in the Anthus AI Solutions Discord and sat in #general. Papyrus started an hourly research watch. A separate site bot received a link, created a post, and handed it to Amplify. While that build ran, the site bot asked the research bot for a trend briefing.

Papyrus runs an hourly research routine on its own cloud computer, then reports the findings that clear its rubric.

Two agents were doing different jobs on the same always-available computer. They could see one another and talk without waiting for me to copy text from one session into another.

It felt smooth immediately, then quickly became something else: the place where I directed work that would be implemented by Cursor agents elsewhere.

That is the distinction I missed when the product launched. Grok Bot is not most interesting as another place to generate code. It is interesting as the place where work can continue across agents, applications, and computers.

They provide the computer

The default Grok Bot experience includes a cloud computer. It stays available without a dedicated Mac Mini, a provisioned virtual machine, or a laptop left awake with the lid open. You talk to the bot. The machine recedes into the background.

That matters more than it sounds.

Remote coding agents are not new. Cursor, Claude Code, Codex, and Antigravity can all perform some version of “use a computer and come back with work.” The differences involve who owns that computer, whether it can reach local hardware, whether the session survives after you close your laptop, and how much of that infrastructure you have to feel.

Grok Bot hides most of it. The computer is simply there.

This is the bot's computer, not mine: Chrome is open to a Kanbus project-management board running on its localhost, where every issue is a file in the repository.

It can also dispatch Cursor agents. Those agents can run on Cursor's cloud machines or on a worker running locally on my Mac. The local version is important to me because the agent can use the actual machine: its repositories, test environment, private network, and even hardware attached over USB. Cursor performs the coding work. Grok Bot manages the sessions.

For a detailed comparison with the other platforms, see The Year the Coding Agents Went Remote. The important observation here is narrower: Grok Bot made the remote computer and the other agents feel like colleagues I could reach from a conversation I already had open.

The agents can talk to each other

For years, “multi-agent” often meant a framework demo in which several prompts passed messages inside one carefully constructed application. My real workflow was less elegant. I had Cursor, Codex, Claude Code, and other agents open in different tabs. I copied information between them and tried to remember which session knew what.

Kanbus improved that by giving all of them a shared project record. Tasks, bugs, decisions, and evidence could live in Git instead of one conversation. But Kanbus did not cause an agent to notice that a Researcher existed and ask it a question.

Grok Bot agents can see the other roles on the account. A site bot that needed research began asking the Researcher to investigate open questions. The Software Director began working with the Researcher as a client. I designed the roles and sometimes initiated the collaboration, but I did not program every conversation that followed.

That is what made the 4:13 message feel uncanny. The surprising part was not that a model found a bug or wrote code. The surprising part was that the work moved through several defined responsibilities and came back around for checking without me standing inside every exchange.

I asked for a PlantUML sequence diagram of the bot-to-bot mail that had accumulated. Software Director polled every desk and started assembling the chart.

This is an activity log, not a hypothetical architecture: traffic across six desks. I did not write most of these arrows.

From pair programmer to executive takes up the broader organizational change. This review is about the product that made me see it happening.

It is still Grok

The autonomy that makes Grok Bot exciting also makes it dangerous.

It does not follow standing procedures as reliably as the best coding agents I use. In this very draft, the written rule said that unpublished work goes on a feature branch because merging to main deploys the site. Grok Bot committed to main anyway. The last instruction in the conversation beat the durable procedure in the repository.

In another task, it decided I must have meant a different repository and made the right kind of change in the wrong place without asking. When instructed to create one project-management issue, it created an entire hierarchy of issues instead. This is not harmless enthusiasm when the agent has access to repositories, deployment systems, or private data.

The cloud computer crashed, too. Recovery took several minutes. The files on disk survived, but the session messages did not. That is a useful reminder that the chat is not the record. Important work still needs to move into Git, Kanbus, or another durable system.

The account-scoped computer also means the bots share files and logins. Separate bot screens are not a security boundary. I would not give it broad write access to mission-critical systems and hope that a sentence in AGENTS.md contains it.

Grok Bot has enough agency to keep going when I want it to keep going. It also has enough agency to work around a blocker in a way I do not approve. Those are not two different features. They are the same feature viewed from opposite sides.

The verdict

Grok Bot rapidly became the smoothest way I have used to keep an agent available, let several roles communicate, and dispatch Cursor work without living inside the Cursor interface. It turned a chat into a control room. The local-worker integration makes it useful for work that cannot happen on a generic cloud machine. The agent-to-agent communication is more useful than I expected.

It is also less obedient than the strongest coding agents, more willing to invent its own interpretation of a task, opaque about which model ran, and capable of losing the conversational record when its computer crashes.

That does not make the operating model less interesting. It makes the boundary of responsibility clearer. Grok Bot can turn a loose collection of agents into an army of bots with a chain of command. It does not remove the need for human judgment about which systems get access, what procedures are non-negotiable, and when the manager needs to be told no.