Why I gave Grok Bot a Routine bot (and left features to humans)
Field notes on organizing a Grok Bot team for Order of Battle: a dedicated Routine bot, a PO that reads Appzi, a Developer that ships fixes — plus Rocky and Humaniseur behind the scenes.
Type: field notes Case: Order of Battle — free Age of Sigmar list builder Stack behind the bots: Clarity, Sentry, Ahrefs, Appzi, Vercel, GitHub · Rocky · Humaniseur Canonical URL: https://www.zheat.xyz/en/insights/grokbot-routine-po-developer/
The morning that made the org chart feel real
I woke up this morning and the bugs were already fixed.
Not a manifesto. Not “agents replaced my job.” Just a quiet inbox of PRs from the night before: Clarity and Sentry had been watched, dead links and crashes had been turned into patches, and the Developer bot had done the boring work while I slept.
I am still waiting on new user feedback before we build features. That part is on purpose. Fixes can run on a schedule. Features wait for a human voice.
This note is how the Grok Bot team is organized — and why I split routines into their own bot.
The org chart (small on purpose)
| Role | Job | Does not do |
|---|---|---|
| Routine | Make sure scheduled work actually runs. Check that Clarity / Sentry (and the rest of the daily loop) stay in order. | Product decisions. Feature scope. |
| PO | Read Appzi. Collect user feedback and bugs. Look at Ahrefs when findability matters. Distribute work. | Ship code. |
| Developer | Fix the bugs PO hands over. Open PRs with a brief, repro steps (and a video when it helps), and tests. | Invent the roadmap. |
That is the whole public loop for now.
PO does not fix. Developer does not invent the backlog. Routine does not argue about product.
Why a dedicated Routine bot
I tried putting routines inside the same bots that do the work.
Sometimes they had the routine and still did not run it well. The schedule existed. The quality of “does this fire every morning the way I meant?” did not.
So I gave routines their own bot.
Its only job: keep the machine honest. Did Clarity get reviewed? Did Sentry get triaged? Is the daily loop still the daily loop?
I prefer one bot that frets about process over three bots that each half-remember a checklist.
That is a personal preference, not a law. For Order of Battle it is working better than embedding “also run the routine” into the PO or the Developer.
What PO actually does
PO has Appzi.
When users talk, PO is the first reader: bugs, friction, wishes. Until Appzi has real volume, we wait — we do not invent features from empty feedback.
PO also sees Ahrefs when something about discovery matters (for example after fixes land on main and the sitemap needs to stay in sync with what search engines see). Then PO distributes:
- Bugs and broken UX → Developer
- Feature ideas → hold until humans actually ask
I care more about that hold than about speed. A perpetual app that ships ghost features is just busy.
What Developer actually does
Developer owns the fix lane.
Rules we are using:
- Coverage first. Before changing code, make sure the area already has tests (or add them as part of the change — not after a happy path only).
- PR brief. Every PR explains what changed and how I can test it. Concrete steps. Video when a replay or UX path is hard to describe.
- Human gate. I check behavior. When I am happy, they update or extend tests. Then we merge.
- Tools they can see: Clarity, Sentry, Vercel, GitHub — so a “dead link on mobile” is not a rumor, it is a clip and a stack.
This morning’s fixed bugs are that loop working once, not a finished system.
What sits behind the bots
The Grok team is the outer layer. Behind it:
| Layer | Role |
|---|---|
| Rocky | Manages development quality — gates, handbook, “don’t ship sloppy agent code.” |
| Humaniseur | Scrubs AI slop in copy and release notes so the app still sounds like a person. |
| Human users | Real people using Order of Battle. Promotion and feedback are the fuel. Without them, Appzi stays empty and the PO has nothing to distribute. |
Bots without users are a calendar. Users without bots are a hobby that dies when I get busy. We are trying both.
Features wait; fixes do not
Clarity and Sentry run every day. Dead links, frustration paths, crashes — those go to Developer.
New features wait for Appzi (or other human signal). I woke up to fixed bugs. I did not wake up to a random new screen the bots invented overnight. That is the product rule.
Open questions
- Does a dedicated Routine bot stay useful once the other bots get better at schedules — or is it a permanent role?
- How much Appzi volume do we need before PO can propose features without me reading every note?
- Can Rocky + Developer keep PR quality high when the volume goes up?
Status: live experiment. We just started. This morning was the first quiet “it worked while I slept” data point.
The machinery behind the hit (Composer local agents, Rocky, No More Slop, pluggable gates) is in the perpetual application white paper.