How to Set Up Grokbot for the First Time: Every Official Tip, Tested on a Fresh Account

Grokbot didn't reinvent the wheel. OpenClaw set the foundation, a lot of copycats followed, and systems like Hermes improved on reliability and stability along the way. What Grokbot changed is the friction. Installing, configuring, and managing a team of agents is now trivially easy. It isn't the model. It's the simplicity and seamlessness of getting off the ground.

So I made a brand new account and tested that claim the hard way. From zero, in one sitting, I built three teams: an X growth team, a Gmail workspace team, and an engineering team. While I did it, I ran through all 10 tips published by Ben Lang and team.

Here is what actually happened, including the one place I think the official list is wrong.

The list is out of order, and that matters when you start at zero

The tips assume you already have a working set of bots. When you are starting from scratch, the most important instruction on the list, "make a chief of agents," is buried near the bottom.

Ben, if you're reading this: that one belongs at the top. Think top down. Think org chart. Nevertheless, thanks for the tips and thanks for the video idea.

I ended up working the list out of sequence for exactly that reason, and I flagged it on camera every time I jumped around.

Step 1: Build the chief of staff first

The first bot I created was a chief of staff. I named mine Elon. Then I pinned it, because on my main account I only work with two bots day to day and they delegate everything else.

You can absolutely message any individual bot. But the whole point of an org chart is that you talk to one and it runs the rest.

Then I fed it real context, not placeholder context:

> The responsibility of you and the team is to grow on X. I have a goal this time next year for us to have 100,000 followers. We just grew Clear Mud, a YouTube channel, from zero to a little over 11,000 subscribers in about a year. I'd imagine we need a copywriter, a researcher, an engineer, a creative. Ultimately I want to be able to just message you and you delegate out.

That is the whole first step. Set up a chief of staff, name it whatever you want, and start feeding context. What is your first goal? What is some background on you? What do you want to accomplish? You can go far deeper than I did, but that was enough. It immediately started spinning up agents.

Step 2: Bots as roles

Tip two from the official list is to use bots as roles. Designer, engineer, PM. Each gets its own system prompt and routines.

The bots the chief of staff created were literally named after their jobs: research, copy, studio. When I opened studio, it introduced itself like this:

> Hey studio here. I'll take a brief from Elon and ship the visual, the clip, the thumbnail, or the tool. Something you can post or run, not a deck.

Later I added inbox for Gmail housekeeping, partnerships to track the partnerships alias, and leads to track form submissions to the team alias. Each one gets its own rules so I can attach routines at different frequencies.

Skip the X API key and log in through the bot's VM

This is the first place the demo hit a wall. I added the X connector so research could actually read the platform. I authorized my account, it popped open in my browser, and then: requests use credits, you need to purchase.

That is exactly what I was worried about.

The workaround: instead of funding an API key, open Google Chrome inside the bot's own remote computer, log into X manually, and let the bot drive the browser from there. Less efficient, but free.

One critical follow-up that is easy to miss. Disconnect the API connector afterward. I learned this on my other setup. If you leave it connected, the bot keeps defaulting to it, and on a free tier key it maxes out and cannot do the work.

Credentials are system wide

Worth knowing before you waste time: each bot has its own screen, but they all share one VM under your account with different profiles. Log into an account on copy, and research is logged in too. You do not have to authenticate every bot individually.

Build voice DNA from your own archive, not from an AI's guess

The official tip says to feed your bot examples of your previous handwritten content. I don't write much by hand, so I adapted it.

I asked the team to pull the transcript from every YouTube video published this year, split into two lanes, long form and live stream, and derive a voice profile from there. The reason is simple: I never read from a script. I always shoot from the hip. The way I actually talk on camera is the real source material, rather than an AI sloppy, super generic approach.

The bot corrected the official tip

One of the tips claims name driven behavior: bots act proactively just from the name given at creation, and a legible role name alone steers behavior.

I read that back to my chief of staff to confirm. It said half right, and it was more accurate than the guidance:

> A legible name is the label. It biases how they show up. It does not make them a self-running employee. The description is actually steering. The brief is when they move, and I am the gate. Name plus a write-post description and they started drafting without a job. That's why they're frozen until I send a brief.

The practical version: name the role so a stranger could guess the job, put the rules in the description, and don't expect the name alone to keep them in their lane.

X labels bot published posts "Made with AI"

Here is the most important thing I found in the entire session.

The team posted live before I had set any rules. The post went out, and X labeled it Made with AI. I deleted it immediately and changed the policy on camera:

> Never post on my behalf. Stage the post, save it as a draft. That way I can open it up on my mobile or any other computer, review the draft, make edits, and hit post myself.

Later, after publishing that way, the label was gone. Same content. X detects when a bot hits post, not whether AI wrote the words. A human interaction and minor edits are enough.

I also added a routine on top of it: at the end of every day, compare what the team drafted against what I actually published, so the gap becomes training data for voice.

Rules, approvals, and routines

For anything wired to X or Gmail, the tip is to block write and destructive actions and require approval first. That is genuinely important. In my channels I told both teams directly not to send anything on my behalf until the rules were set.

For local actions I chose "allow once" every single time so I could stay on top of what was being installed and automated. You can see pending approvals from the orange indicator whether the panel is expanded or not.

On frequency: never run a routine every five minutes. That just burns tokens. Hourly or a few times a day is usually enough. The gut check from the list is a good one. If a real human teammate could do this job, build it. If not, optimize it first.

I did build one daily routine I actually wanted: check what is trending on X, cross reference it with Google Trends filtered to YouTube search specifically, and hand me five value driven video ideas. I don't make videos straight off trend data, but you find needles in the haystack that way, and it gives me a daily TLDR when a new model drops that I might otherwise be slow to act on.

Sections and channels are two different things

Creating a channel does not group bots into a section. I made a Gmail workspace channel with partnerships, inbox, leads, and Elon in it, and I still had to create the section separately and drag each bot in. You can also right click and move to. Either way, it's manual.

The payoff is focus. A Gmail session, an X session, an engineering session, each collapsed until you need it.

One rule that matters: put your chief of staff in every shared channel. If Elon wasn't in that room, he wouldn't get the context, and later when I work only with him he wouldn't know what was decided.

The engineering team: Grok as orchestrator, Claude and Codex through the CLI

This was the bonus, and it's the part I run on my real Clear Mud setup.

I built an engineering team any other team can call: a default Grok bot, a codex bot, and a claude bot. The instruction was specific:

> For codex and claude specifically, what I want you to do on your VM is install Codex and Claude respectively in the CLI so that those bots can invoke Claude or Codex in the CLI. Use whatever model is specified, do the work through the CLI, and then report back to their requesting bot.

By default Grok is the master orchestrator, because every bot here runs on Grok. The claude and codex bots are still Grok 4.6 bots. They just invoke the CLI on the machine to reach Fable, Opus, or GPT 5.6. That means you use the subscription you already pay for instead of paying per API call.

The routing rule I gave the chief of staff: engineering work goes to Grok first, and only routes to a specific model when I explicitly name one. Whoever stitches the result together is up to them.

I also set up Peekaboo on the Mac to enable more OpenClaw like local control. That is what made the difference from my earlier video, where I installed Claude and Codex through the VM only. With Peekaboo running, Codex reported "signed in already" on its own. I hadn't done anything and had nothing pending. It had logged in through my local browser. It's also interesting that the official tip references OpenClaw and not Hermes. Respect. Remember who started this movement.

The whole build cost 7 percent usage

Three teams, roughly ten bots, multiple routines, Peekaboo, GitHub, Gmail, CLI installs, all on a Grok heavy account. Total usage burned: 7 percent.

Not bad.

The short version

• Start with a chief of staff and feed it real goals and real context.
• Pin it, and talk to one bot instead of ten.
• Name bots as roles, but put the actual rules in the description.
• Log into X inside the bot's VM instead of funding an API key, then disconnect the connector.
• Build voice DNA from your own transcripts, split by content format.
• Never let bots post on your behalf. Stage drafts, edit, publish yourself, and dodge the Made with AI label.
• Run a nightly drafted versus posted comparison to fine tune voice.
• Block destructive actions on anything touching X or Gmail.
• Keep routines to hourly or a few times a day.
• Use sections plus channels, and splice your chief of staff into every shared channel.
• Build an engineering pod with CLI based Claude and Codex bots so you use subscriptions, not API spend.
• Set up Peekaboo for local control the VM alone won't give you.

If you want a specific use case covered inside Grokbot, drop a comment on the video. Thanks for tuning in.

Watch the full build: https://www.youtube.com/watch?v=szDvF-iX2tY