Five Grok Bots on the Night Shift: The First Role to Build Is the Reviewer

Dep posted a night-shift setup on X: five Grok Bots, each doing only one thing, working overnight inside guardrails, and delivering only a one-screen briefing in the morning. The original post and article links are here.

Grok Bot is not just a chat window. Each Bot has its own cloud computer, browser, email, desktop, files, and terminal; it can retain memory and run on a schedule or trigger. It keeps working after you close your laptop. That is where the opportunity is, and also where the risk is: it makes mistakes while you sleep. Dep's setup revolves around three things: guardrails, a reviewer, and real code work. Code tasks go to Opus 5.5, running through Claude Code on a night branch, never touching main.

Dep's judgment is that most Grok Bot setups do not survive past Thursday. On day one you spin up seven, wire up every login, and run routines every few minutes. By the weekend, six are ignored, one has done something nobody approved, and the quota is gone. His approach is deliberately boring: five Bots, one role each, working overnight inside rules.

Five roles:

• Reviewer: checks the outputs of the other Bots, giving each item a pass or fail and a reason. Never silently fixes anything.
• Scout: finds new changes in the niche overnight. At most 10 items, each with a link. Does not report sources it did not open.
• Coder: runs one Claude Code task each night and leaves a branch and summary. Never touches main.
• Metrics: pulls real numbers, one table, plus what moved. Does not report a number it did not reopen.
• Lead: writes the morning briefing and assigns daytime tasks. One screen at 07:30. Never does the specialists' work.

Build order: Reviewer first, then Scout, then Lead. Once these three have survived a week, add Coder and Metrics.

Paste the rules block into every Bot first. Dep puts it in front of every job prompt:

rules for every bot on this account:
1. anything that sends, pays, posts, deletes, or changes an account becomes a draft. you never do it yourself.
2. before reporting any number or claim, reopen the source and include the link. no link, no claim.
3. use only the logins your job needs. if you hit a login wall, stop and leave it for me. never ask me to paste a password into chat.
4. night runs never wait for my approval. if a step needs it, write the draft, note it in your log, move on.
5. two strikes: if the same step fails twice, stop and write what failed and what you tried.
6. append one line per run to your own log file: date, time, what you did, what changed, what you skipped.
7. if nothing changed since your last run, write `no change` and stop.

The key is rule 1: the test is whether an action can be undone. A small action may be permanent; a large action can first become a draft. Rule 4: waiting for your yes at 3 a.m. only means waiting until you wake up. Rule 6: the app keeps only the last 20 runs per routine; your own log is the evidence at 9 a.m. Rule 7: without it, a research Bot will drown you by day four.

Prompts are below too. Adjust times to your own time zone.

Reviewer:

you are my reviewer. your only job is checking my other bots' work before it reaches me.
at 07:00, read the latest output from scout, coder, and metrics.
for each item check:
- open the source link. does it say what the item claims?
- does any number differ from the source?
- is it a duplicate of yesterday?
- for coder: did it stay on its night branch, and does the summary match the diff?
output: a table with item / pass or fail / one-line reason.
never fix or rewrite an item yourself. you have no stake in the others being right.
if everything passes, say so in one line.

Scout:

you are my scout. at 02:00, check these sources for anything new since your last run:
[your sources: X accounts, changelogs, repos, newsletters]
my niche: [one line on what you do and for whom]
keep an item only if it's new and someone in my niche would act on it this week.
output: max 10 items. one line on what happened, one line on why it matters to me, plus a link you opened.
nothing qualifies? write `no change` and stop. log to scout-log.md.

Metrics:

you are my metrics bot. at 06:00, open [your dashboards] and pull [the exact metrics].
compare each with the same day last week.
output: metric / yesterday / last week / change, then max 3 lines on what moved, marked as a guess.
if a source won't load, write n/a. never estimate. log to metrics-log.md.

Lead:

you are my lead and the only bot i talk to. team: scout, coder, metrics, reviewer.
at 07:30, after the reviewer, write my briefing:
1. decisions for me today (max 3), with the draft waiting
2. what moved in my numbers (reviewer-passed only)
3. what's new in my niche (reviewer-passed only)
4. what failed overnight and why
one screen. no item without a link.
during the day, route my tasks to the bot that owns them. hand over the goal, the context, and why, not just the file. if no bot owns it, tell me.

The last line is where most teams leak. The second Bot gets the file but not the reasoning, and answers a slightly different question.

Scheduling is deliberately slow: 01:00 coder, 02:00 scout, 06:00 metrics, 07:00 reviewer, 07:30 lead. Pick the slowest schedule the task can tolerate. Every time a routine wakes up it costs money, whether or not anything changed. Going from hourly to every 5 minutes is 12 times as many runs. Gipp calculated that a 5-minute routine wakes up 8,640 times a month, about $400 in compute at Grok 4.6 API rates, for one job. Hourly is $33. Same Bot, same model, same prompt. Only speed up when real missed reports prove it is too slow. For tasks that can be started by a trigger, use a trigger and narrow the scope.

Opus 5.5 does the code work. After the October update, Grok Bot chooses the backend model for a task itself, and Opus 5.5 is one of them. There is no picker, so you cannot force it. To guarantee Opus, go through the terminal. Coder Bot runs Claude Code in the terminal, using your Claude subscription, on the repo. All Bots share the same computer, and every Bot can use that login. So when a scheduled Bot drives a coding agent, the guardrails need to be tighter. The settings.json Dep gave in the Claude Code overnight article: allow reversible work, read, edit, test, lint, commit; ask before push or new dependencies; deny catastrophic operations, recursive delete, force-push, hard reset, .env, raw network calls. Deny wins over allow; broad rules do not open a wall. Also put a short CLAUDE.md in the repo.

Coder prompt:

you are my coder. at 01:00, open the repo at [path] and start claude code in plan mode.
tonight's task is the top item in TASKS.md.
have it write the plan to PLAN.md first. if the plan touches anything on the deny list, stop and log it.
otherwise work on a new branch night/[date]. never main. never push.
when done, or after two failed attempts at the same step, write to MEMORY.md: what changed, what's left, what needs my decision.
add the summary to your log for the reviewer.

The Reviewer is the most important Bot here. Every Bot can be confidently wrong. Scout links a post whose content is slightly different. Metrics copies yesterday's numbers. Coder's summary does not match the diff. A Bot checking its own work passes every time. The Reviewer has no stake: it opens every link, reopens every number, and diffs Coder's summary against the branch. Failed items do not go into the briefing; they appear as fail plus reason, so you know what to fix.

Once a week, have Lead ask every Bot: what do you believe about this setup. Correct stale information. Memory carries good habits into next week, and also carries Tuesday's wrong assumptions into Friday.

Traps in the order you will hit them: too many Bots on day one—three that survive beat seven that do not; a fast clock; overnight approvals; shared connections, with every Bot on the same computer and sharing files and logins, so only give each one the access its job needs; no model picker; other vendors reading your data, since the model handling a task reads what the Bot reads; Coder scope creep—one task per night, and a branch too big to review over one coffee.

Some situations do not need this setup. If you mainly ask questions and read answers, ordinary chat is enough. If you cannot describe a task to a new employee in one paragraph, fix the description first. If you have only one recurring task, it only starts paying off at three or four tasks.

There is also a reverse approach in the replies. One user said they make the Bots clock off at 23:00. Something discovered at 3 a.m. cannot wait until morning; they would rather read fresh in the morning than wake up to five Bots' backlog. That setup works too; it depends on whether the task can wait.

Short version: five Bots, one role each, build Reviewer first; one rules block—draft instead of send, source every claim, two strikes then stop, one log line per run; the slowest workable schedule, no waiting for people at night; Opus 5.5 through Claude Code on a night branch, behind a deny list. Draw the guardrails once, review one screen in the morning.

p.s. Build the Reviewer first. Everyone skips it, and it is also the first thing you check in the morning.

Original: https://x.com/0xDepressionn/status/2115849254388310207

Article: https://x.com/i/article/2113653510596169728

Quoted tweet: https://x.com/0xDepressionn/status/2113984485137990129