Grok Bot Gave My Coding Agents a Boss

Grok Bot rapidly became the control room for my army of bots—with less help from me than I expected.

At 4:13 Friday afternoon, the Researcher bot reported a bug to the Software Director. The director split it into separate workstreams, dispatched Cursor agents to my Mac, reviewed what came back, rejected weak work, and returned the combined fix to the Researcher for acceptance testing.

I had defined the roles, but I wasn't carrying every message or specifying every handoff anymore. I was watching software manage software.

This is completely nuts.

I wrote about the larger management shift in From Pair Programmer to Executive. This article is about the product that made the shift feel real.

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, that doesn't sound especially 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's what I missed when the product launched. Grok Bot isn't most interesting as another place to generate code. It's interesting as the place where work can continue across agents, applications, and computers.

They provide the computer

Grok Bot includes a persistent cloud computer shared by your bots. The documentation describes it plainly: they can sign into apps and websites, and jobs keep running when you step away. You don't need a dedicated Mac Mini, a 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 narrower point here is that 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 didn't cause an agent to notice that a Researcher existed and ask it a question.

Grok Bot's launch announcement says bots can message each other, share context, and coordinate in group chats. In my 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 didn't program every conversation that followed.

That's why the 4:13 message felt so uncanny. The surprising part wasn't that a model found a bug or wrote code. It was that the work moved through several defined responsibilities and came back 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 didn't write most of these arrows.

But it's still Grok

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

It doesn't 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. That isn't 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 didn't. That's a useful reminder that the chat isn't 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 don't approve. Those aren't two different features. They're the same feature viewed from opposite sides.

The verdict

Grok Bot is the smoothest way I've found to keep several agents available, let them communicate, and dispatch Cursor work without living inside the Cursor interface. It turned a chat into a control room. The local worker makes it useful for jobs that can't happen on a generic cloud machine, and the agent-to-agent communication is much more useful than I expected.

It's also less obedient than the strongest coding agents I use. It will invent its own interpretation of a task, it doesn't tell me clearly which model ran, and a crash can take the conversational record with it.

That makes the boundary of responsibility clearer. Grok Bot can give a loose collection of agents a chain of command. It can't decide which systems deserve access, which procedures are non-negotiable, or when the manager needs to be told no. That part is still mine.