Article

What Running Thirty Grok Bots Actually Looks Like

By Austin Hoopes · Published October 23, 2026

I run more than thirty Grok Bots. Most days I talk to exactly one of them.

This is a plain tour of how that works: what the bots do, what broke, and what I changed. About a five-minute read.

One job, written down

Each bot has one narrow job, written into its description, usually with the words ‘ONLY job.’ Not “mainly.” Not “and also.”

One triages my inbox. One verifies what my other writing bots produce and reports pass or fail. One runs healthchecks on the other bots’ routines and transcripts. One nudges me to stay in touch with people I’d otherwise let drift. One scouts Lego deals. One makes college football picks. One holds the voice memos I park for journaling. One helps me write articles like this one.

A bot with one job knows when it’s done. A bot with three jobs keeps finding reasons to do a fourth.

The best teams I’ve seen work the same way. Everyone knows their job, and nobody freelances into someone else’s. (More on the idea in What is a one-job Grok Bot?)

One front door

I don’t keep thirty chats open. I talk mostly to one primary bot, and it routes the request to the right specialist. The specialist does the work and hands the result back.

That handoff matters more than it sounds. The specialist doesn’t need my whole day. It needs a short, clean brief: what’s being asked, what’s already known, what done looks like. The primary bot gives it that, and gets back an answer it can pass to me without translation.

I get one conversation. The fleet gets clear briefs. Both sides are happier. (For more on handoffs between bots, see Small AI fleets: handoffs, group chats, and the shared computer.)

The checker is a different bot

The story that sold me on this setup is a fact-check.

One of my writing bots produced a draft about an update to X’s algorithm. It read well. It sounded sure of itself. It had 32 claims in it.

My fact-checker bot went through each one against the commit history of the public code. Twenty-two checked out, some with caveats. Three were only partly right. Four were overstated or contradicted by the code. Two couldn’t be tied to anything in the code. One had no basis at all.

Then, the next morning, a code change made part of the draft wrong that had been right the day before.

None of that is a knock on the writer. Writers write. A separate checker beats trusting the writer, the same way it helps when one person does the work and a second person confirms it. The value comes from them not being the same person.

What didn’t work

The inbox bot that remembered everything. My Gmail triage bot did its job well, and its chat kept growing. Eventually every wake carried that whole history along with it, and every wake got expensive. Nothing was broken. It was just heavy. I retired that chat as an archive and started a fresh, short one for the same job. Same work, much lighter.

The scout that wasn’t worth it. I had a bot scouting X news. It ran fine. What it found wasn’t worth what it cost to find. I paused it entirely. Turning a bot off is a perfectly good outcome; it means the experiment answered the question.

The “nothing new” messages. Bots that wake on a schedule and find nothing used to tell me so. Every morning, a small pile of polite reports saying nothing happened. Now they’re told to stay silent when there’s nothing to say. Quiet is the default. If a bot speaks, it’s because something needs me.

Shared files, not memory

Bots are confident about what they think they remember. I’d rather they check.

So the fleet keeps shared files instead of relying on memory guesses. One example: a ledger of which quote-post moments have already been used, so nothing repeats. Before a bot suggests a moment, it reads the ledger. After I use one, it gets written down.

If it matters twice, it goes in a file. Memory is useful for preferences and standing rules; files are for facts that have to be exact.

The rules that don’t bend

Two standing rules cover the whole fleet.

Anything that sends, spends, or deletes waits for my approval. No exceptions for “it was obviously fine.”

Messages to people come to me as drafts, and I press send. Site pages go out only after a separate checker bot passes them. This article waited for me.

These rules cost me a few seconds a day. They’ve saved me from every version of “the bot did what?” I can imagine, and I’d like to keep it that way.

What I’d tell someone starting out

Give each bot one job and write it down. Put one bot at the front door. Make the checker a different bot from the writer. Let quiet bots stay quiet. Retire chats that get heavy. Pause anything that isn’t earning its keep. Keep facts in files. Keep your hand on the send button.

None of it is clever. That’s sort of the point. The fleet works because each piece is boring and does what it says.

← All articles