Five Bots Work Through the Night and Deliver One Screen of Briefing in the Morning

Dep shared a demo in his tweet: a lead bot with specialist bots runs the full morning workflow before the investment committee, in 25 minutes. You only get a message when something actually changes.

Most Grok Bot setups do not make it past Thursday. Dep writes in the article that on day one he spun up seven bots, with every login connected and routines firing every few minutes. By the weekend, six had no one watching, one had done something no one approved, and the quota was gone too. His setup is deliberately boring: five bots, one responsibility each, working overnight inside rule fences. Opus 5.5 runs code on branches and does not touch main. Another bot is responsible only for checking the first four before he wakes up.

Why Not a Chat Window

Models only answer. The outer layer decides what it can touch, what it can see, who checks the output, and when to stop. Grok Bot provides this layer: each bot has its own cloud computer, browser, files, and terminal, and the work does not run on your laptop. It keeps running even when the lid is closed. Bots retain memory and can run on a schedule or trigger.

Opportunity and risk come together: a bot that sleeps for you will also make mistakes for you. So three things: fences, a reviewer, and real code tasks.

Five Bots, One Responsibility

Build order: reviewer, scout, lead. Once these three have survived a week, add coder and metrics.

The Rules Block

Dep's rules block is pasted at the very top of every bot. The core 7 rules:

1. Any action that sends, pays, publishes, deletes, or changes an account becomes a draft. The bot does not do it itself.
2. Before reporting any number or conclusion, reopen the source and include the link. No link, no conclusion.
3. Use only the logins the responsibility requires. If you hit a login wall, stop and leave it to a human. Do not let the user paste passwords into chat.
4. Overnight runs do not wait for approval. For steps that need approval, write a draft, log it, and continue.
5. If the same step fails twice, stop and write down what failed and what was tried.
6. Append one log line to every run: date, time, what was done, what changed, what was skipped.
7. If nothing has changed since the last run, write 'no change' and stop.

Several of these are the key ones: Rule 1 asks whether something can be undone. Small actions can be permanent; large actions can be turned into drafts. Rule 4 exists because anything that needs your nod at 1 a.m. will just wait until you wake up. Rule 6 exists because the app keeps only the last 20 runs; your own log is the evidence at 9 a.m. Rule 7 exists because without it, a research bot will drown you by day four.

The Schedule Is Deliberately Slow

01:00 coder, 02:00 scout, 06:00 metrics, 07:00 reviewer, 07:30 lead.

Choose the slowest schedule the work can tolerate. Every routine wake-up costs money, whether or not anything changed. Gipp calculated that a routine every 5 minutes wakes up 8,640 times a month, about $400 in compute at Grok 4.6 API prices; once an hour is about $33. Same bot, same model, same prompt. Only speed up when a real miss proves it is too slow. For narrow tasks that can use triggers, use triggers.

How to Fit Code Tasks In

Dep mentions that after the October update, Grok Bot picks the backend model for a task itself, and Opus 5.5 is one of them. There is no selector, so users cannot force it. To make sure Opus is used, go through the terminal. The Coder bot runs Claude Code in the terminal, using your own Claude subscription, and works on your repo. Refactors, tests, dependency checks, and small fixes go overnight. Note that all bots share that computer, and every bot can use that login. So the fences need to be tighter.

Allow reversible work: read, edit, test, lint, commit. Ask first for pushes or new dependencies. Deny catastrophic operations: recursive deletes, force-push, hard reset, .env, bare network calls. Deny takes precedence over allow, and broad rules cannot open a wall. Put another short rules file in the repo. Coder does only one task per night, on a new branch night/[date], does not touch main, and does not push. Stop after two failures and write MEMORY.md: what changed, what remains, and what needs your decision.

The Reviewer Is the Only Bot That Does Not Take Sides

Every bot can be confidently wrong. The post linked by Scout says something slightly different from what Scout summarized. Metrics copies yesterday's numbers. Coder's summary does not match the diff. A bot checking itself passes every time.

Reviewer is the only bot with no stake in 'the other bots must be right.' It opens every link, reopens every number, and checks the coder's summary against the branch diff. Failed items do not go into the briefing; they show up as fail plus the reason. Once a week, have Lead ask each bot what it believes about its own setup and correct outdated memory. Memory carries good habits into next week, but it also carries Tuesday's wrong assumption into Friday.

Pitfalls You Will Hit First

Starting too many bots on day one. Three that survive beat seven that do not.

Clock too fast. A 5-minute routine burns quota even when nothing happens.

Overnight approvals. Anything waiting for your nod in the early hours will wait until you wake up.

Shared connections. Every bot shares the same computer, files, and logins. Connect only what the work needs.

No model selector. You cannot control when Opus 5.5 is used inside Grok Bot. The terminal route is the guarantee.

Third parties reading data. The model handling the task will read what the bot reads. For some work, that is a hard blocker.

Coder scope creep. One task per night. A branch too big to review over coffee is too big.

When you do not need this setup: if you mostly ask questions and read answers, ordinary chat is enough. If you cannot describe the task to a new employee in one paragraph, fix the description first. If you have only one repetitive task, this setup needs three or four tasks before it starts paying off.

The Short Version

Five bots, one responsibility each, build the reviewer first. One rules block: drafts instead of sending, a source for every conclusion, stop after two failures, write a log for every run. The slowest schedule, and no overnight waiting on you. Opus 5.5 through Claude Code, overnight branches, deny list behind it. Draw the fences once, look at one screen in the morning.

Dep's postscript: build the reviewer first. It is the bot everyone skips, and the bot you check first every morning.

Sources: Dep's tweet https://x.com/0xDepressionn/status/2118796246265585813 and article https://x.com/i/article/2113653510596169728. Gipp's cost data comes from his routines article. This only summarizes the key setup and does not replace the original.