Every Grok Bot guide so far is about admin. Triage the inbox, chase leads, file receipts, draft posts.

Useful, but it is not what most people reading this actually do. You build things. And the reason your side project has been at 80% for three months is not that the code is hard - it is that shipping something takes six different kinds of work and you only have time to do one of them a night.

This is the setup for that. Six bots, each owning one lane of a build, handing work between them, running while you sleep.

Why this works differently for building

Grok Bot went into beta on 11 August. The mechanic that matters for builders is not the chat window - it is that your bots share one persistent cloud computer, with the same files, the same browser sessions, and the same logins.

That sounds like a small detail. It is the whole thing.

It means the bot that read your issue tracker and the bot that writes the code are looking at the same filesystem. It means you sign into GitHub once and every bot you ever create is signed in. It means handing work from one bot to another does not require re-explaining the project or re-authenticating anything - the context is already there.

For a build pipeline, that removes the step that kills every automation attempt: moving state between tools by hand.

What you need

Grok Bot ships as a desktop app for macOS and iOS at x.ai/bot. Access comes through Cursor Ultra at $200/month, SuperGrok Heavy at $300/month, or Cursor Teams Premium at $120 per seat. Sign in with that account and you are in.

Onboarding asks which tools you use and gives you a grid - GitHub, Linear, Slack, Notion, Google Drive, Gmail and more. Pick your actual stack. Connections are account-level, so you connect once and every bot inherits it.

Setup to first working bot is about four minutes.

The six bots

The split that works is by lane, not by task size. A generalist juggling code, review and deploys is worse at all three and gives you no clean thread to look at when something breaks.

Chief

Owns coordination. Reads the day's work, sets priority, hands tasks to the right specialist, runs the nightly review.

You are my Chief of Staff for this project.

Scout

Owns everything coming in. Issues, bug reports, competitor releases, library updates, anything that changes what should be built.

You are my Scout.

Forge

Owns the code. This is the bot doing the actual building.

You are my Engineer.

Critic

Owns review. Separate bot, separate context - this one never writes the code it reviews.

You are my Reviewer.

Ship

Owns release. Builds, deploys to preview, checks it came up, prepares the release notes.

You are my Release Engineer.

Ledger

Owns memory. This is the bot most people skip and the one that makes the rest compound.

You are the project's memory.

Teach it once instead of describing it

The feature that changes the most for builders is recording.

Open a bot's cloud computer, hit "teach a task", walk through the workflow once, hit stop. It saves the whole flow as a named skill it can rerun.

This matters because the jobs that eat your week are tedious to describe and trivial to demonstrate. "Pull the failing test names from CI, cross-reference the last three commits that touched those files, and post the likely culprit in the thread" is a paragraph to write and forty seconds to show.

Pick your first recording carefully. The best candidate is something you do at least weekly, that touches two or more tools, and where the steps rarely change. Recurring, multi-tool, stable.

Routines: give the work a reason to start

A saved skill still needs a trigger, and you set those by talking rather than building a workflow.

You can also just say "run this every week" right after a task you liked, and it creates the routine from what it did.

Put them in one room

The part that turns six assistants into a shop: bots can message each other and hand off work in a shared thread.

Give the group an objective rather than a task list. A task list means you already did the decomposition and they are just executing your plan. An objective lets them split it, which is the point of having more than one.

// group thread

@Scout the checkout flow has three new bug reports this week. Read them, reproduce what you can, and tell us what they have in common.

@Forge once Scout has a root cause, implement the fix on a branch and open a PR with a regression test.

@Critic review it before it reaches me. Security and edge cases first.

@Ship deploy the branch to preview once Critic signs off, and post the URL.

@Ledger write the decision note when this closes.

One owner per stage. Nothing merges or deploys without me.

The handoff - one bot deciding another owns the next step and passing it along with the context intact - is the thing that did not exist in any tool before this.

The one rule that makes it safe to sleep

Everything above runs unattended. That works because of one line repeated in every charter: nothing irreversible happens without you.

Draft, build, test, review, deploy-to-preview, write notes - all reversible, all fine to finish alone. Merge to main, production deploy, anything sent outside, anything touching secrets or money - those wait.

That is not caution for its own sake. It is what lets you leave the whole thing running instead of checking on it every hour. And when a bot does hit a login, a 2FA prompt or a payment wall, it hands the screen back to you, you clear it, and it resumes on the same session. You never paste a credential into a chat.

Your first week

Do not start with six bots. Start with two.

Day one: create Chief and Scout. Let them read only. Watch what Scout flags and whether Chief's priorities match yours.

Day two or three: add Forge with a small, boring task - a typo fix, a dependency bump, a test that needs writing. Review the PR properly. Do it twice more.

Day four: add Critic. Have it review Forge's PRs before you do, and see how much of what it catches you would have caught.

Day five: add Ship, preview deploys only.

Week two: add Ledger, and put the nightly build routine on a schedule.

By the end of the second week you come back in the morning to a PR that already exists, already passed tests, and already has review notes on it. That is the whole promise, and it arrives about ten days in rather than on day one.

The point

The bottleneck in a side project was never the code. It was that shipping needs six kinds of work and you had time for one.

Six narrow bots on one shared computer, each owning a lane, handing work between them, with the irreversible steps parked for you - that is a shop. It runs at night, and the thing waiting for you in the morning is a decision rather than a task.

Start with two bots and a boring task. Add the rest as they earn it.

I write about Claude, local AI, agents, and the systems that turn them into real work. Follow @88n77n.

Grok Bot for Builders: The 6-Bot Setup That Ships While You Sleep (Full Guide)

Job breakdowns