Skip to content
Bot jobsJob breakdowns

Bots are Seats. Skills are Shared.

The default move on Grok Bot right now is: new capability, new bot. Need someone to run Codex, Cursor, Grok Build, or another CLI on the shared VM? Hire an orchestrator. Add it to the roster. Tell

Aaron MakelkyImported from X2 min read
theaaronx article
See this runHouse 215 · 00291

Article

Job breakdowns

The default move on Grok Bot right now is: new capability, new bot.

Need someone to run Codex, Cursor, Grok Build, or another CLI on the shared VM? Hire an orchestrator. Add it to the roster. Tell your Chief of Staff to ping it.

That is a seat for a procedure. Procedures should not get seats.

The limit problem everyone is posting about

Grok Bot is good. The rate limit is the part people do not love.

Aaron Makelky's fix shows to install your coding agents on Grok Bot's virtual machine, put a session manager like Herdr in front of them, and give the bot a rule. Conversation stays on Grok Bot. Anything heavier goes to the CLIs. Grok Bot only spends quota on coordination. The coding burns Cursor, Grok Build, or whatever other sub you already pay for.

That setup is right. Wrapping it in its own bot is usually not.

Why a dedicated orchestrator bot is the wrong shape

A bot is a teammate. It has a lane, a personality, memory, and a reason other bots should ping that one.

A skill is a recipe any bot can call. Officially: reusable instructions, available across your bots. A routine is the schedule that tells one bot when to fire. Different objects.

If the Chief of Staff always has to ping "CLI Bot" to touch the terminal, you turned a shared computer into a gated desk. Other bots cannot outsource work without the extra hop. You spend a full bot turn plus handoff chatter to do something that should be a skill.

CLI orchestration has no taste. It does not own a project. It does not need follow-ups. It is: open a session, send the brief, bring back the summary, don't spend Grok Bot tokens redoing the work. That is a skill.

What to do instead

Tell your Chief of Staff to make the skill. Then tell it to argue the hire. Paste something like this:

Don't add a standalone bot just to orchestrate CLIs on the VM. Turn that into a skill any bot can call when it wants to save Grok Bot quota by handing work to Codex, Cursor, Grok Build, or another CLI. Reason first: is this better as a shared skill than another seat in the roster? If it is just a procedure, save the skill.

That is the whole discovery. You do not need a week of testing to see the shape. Bots are seats. Skills are shared. The Chief of Staff should create the recipe and only open a new seat when the work actually needs an owner.

Published on grokbot.sh. Cite the public log, not a prompt pack.

Command Menu