Jonathon's AI Wiki

Grok Bot — Running a Business on an Agent Team

13 min read

Source: raw/Making_with_Grok_Bot.md (Greg Isenberg’s Startup Ideas with Billy Howell, ~35 min) + raw/11_Grok_Bot_Use_Cases_That_Feel_Like_Cheating.md (Matthew Berman, ~20 min) + raw/9_AI_Techniques_You_Probably_Haven_t_Tried.md (The AI Daily Brief, technique #7)

Grok Bot is xAI’s agent-team product: named, avatared bots that each hold one job, run on cloud virtual machines, connect to services through plugins, and can be put on schedules (“routines”). It arrived roughly a week before these three sources and all three reached the same structural conclusion independently — one bot per job, a chief-of-staff bot as the single human interface, and a hard cap on how many bots you create. Two of the three are running real businesses on it.

Key Takeaways

  • The chief-of-staff topology is the whole design. One bot is the entry point; it delegates to specialist bots and rolls their reports back up. Berman talks only to a pinned “Chief of Staff” from Slack or Telegram; Howell interfaces through his and drops down to a specialist only when he wants to give direct feedback, the way you would skip a layer at a real company.
  • The constraint is a feature. Bot identities are shape × colour combinations — Howell counts roughly 76–88 possible unique bots. His argument is that this forces mission-orientation, where a chat product’s infinite gray threads produce abandoned projects. “Colour and shape is all the human brain needs to differentiate something.”
  • Pick one project. Howell is blunt: you do not have enough tokens to run four businesses at once, and mixing a newsletter, a Twitter account, and receipt-sorting into one workspace produces context bleed that makes every bot worse. Running one newsletter heavily, he finished week one with ~10% of his usage left.
  • Earn the right to create an agent. Have the chief of staff do the task once. Review it. Then say “create a bot that does the thing you just did.” Creating a bot per imagined job is how you burn tokens and stall.
  • Delegate for context, not just for labour. Howell’s reason for not letting the chief of staff post to Instagram: “you wouldn’t have the CEO going in and making Instagram social posts every day… like a real person, it takes up mental bandwidth for that agent.” Context window is the mental bandwidth.
  • The biggest pitfall is letting agents make your decisions. Howell lost three weeks to an agent that could not choose between Notion, local files, and Google Sheets for content storage. “At some point you’re the person that has to make the decision, not the agent.”
  • Build → execute → automate. Once a workflow is proven, remove the ambiguity. Business-critical steps get deterministic automation, because models are black boxes and may write it differently tomorrow — and because it frees tokens for building.
  • A plugin may only be skills for using a service, not write access. Howell’s Shopify example: the built-in integration could talk about the store but not act on it. The fix is to install the vendor’s CLI on the bot’s own cloud computer.
  • It sits between chat and a coding agent. Berman’s positioning: a bridge between Q&A with a chatbot and Codex or Claude Code — “if you’re not technical and you don’t want to think about using some of these coding agents, Grok Bot is such a nice middle ground.”

The three-week cadence (Howell)

The single most transferable thing in these sources is a schedule, not a feature.

Week 1 — build the team from an audit. Start with a chief of staff. If you have an existing business, give it your existing docs (his: Notion, Slack, Gmail) and ask it to take stock and name the top three agents to create first to drive revenue. State the mission as revenue explicitly. For the Arlington Bagel — a local newsletter to 6,000 subscribers every Thursday — the answer was a research agent, a sales agent, and a Beehiiv-expert agent. That third one is the pattern worth stealing: when the business depends on a platform, give the platform its own bot so the chief of staff does not have to be an expert in everything. Editorial was deliberately deferred; the chief of staff edited issue one.

Week 2 — no tinkering. No new agents, no fiddling with skills, maybe a connection or two. Execution only. “Run the damn ball. Run with that team for a week and see what you can get done.”

Week 3 — expand where the gaps showed, then automate. Only now add the bots the week revealed you needed (inbox, merch shop), and only now ask the chief of staff: “based on how we ran this week, what routines could we set up to make progress while I’m not working on this?”

Anti-creep, on a schedule. Re-run the audit periodically: what agents can we add, what can we remove, what should become a routine or a skill. Howell on introducing novelty: “I only add an agent if we really need it. I’m so anti idea-creep and agent-creep, because that’s how you burn tokens.”

The five-line end-of-day brief

Most of Howell’s bots have a daily, weekly, or bi-weekly routine with the same instruction: look at your current to-dos, what did you create today, what blockers do you have — write a quick five-line report and send it to the chief of staff. The chief of staff then rolls the reports into what shipped, what’s stuck, and what needs you.

The five-line cap is deliberate: “more than that, you’re just going to be burning tokens and context.” This is the cheapest legible-fleet mechanism in the wiki — a status protocol, not a dashboard.

Adversarial QA panels

Howell’s method for getting work product from ~50% done to ~90% done without reviewing it himself, which he frames as a general agent pattern he uses in Codex too:

Once you’ve done this once, create a panel of subagents — the chief of staff or other agents on the team — and have them do an adversarial review of your work. Do that in three rounds.

And the compounding step: once you have given a bot good feedback in a thread, “take what we did in this thread and turn it into a skill that another agent can use when it’s reviewing, so it reviews exactly like me.” Your taste becomes a reviewer.

Berman’s eleven jobs

The specialist bots he actually runs, with the mechanics that generalise:

  • Email triage. A 7:30am pass that batches (a) obviously archivable mail — 14 out-of-office auto-replies from his newsletter, notifications — behind one archive button, then (b) low-effort mail he must read but need not answer, batched into a few sentences, then (c) per-email deep reads that pull the whole thread plus prior interactions with that person and propose the next action. Connected HubSpot and Google Drive so it can check contracts and notes before proposing. It learns: tell it “anytime you get an email like this, don’t even ask me.”
  • Email classification. Sponsorship emails get a lead score — a heuristic he built up in OpenClaw and ported over wholesale — so spam auto-archives and the rest sort. About a dozen labels.
  • Calendar. Negotiates meeting times, checks for overlaps, and creates events from emails containing multiple dates. He never talks to it directly; the chief of staff does.
  • Browser use, in the cloud. Sign in once and the session persists. Shopping, returns (it hands back the QR code), gym bookings, doctor’s appointments, DMV registration. He notes agents can browse Amazon freely since the Amazon-vs-Perplexity suit was thrown out.
  • Meeting summaries. Fathom records and transcribes; Grok Bot checks Fathom’s API every 30 minutes for new recordings, ingests the transcript, writes a summary plus action items split by who committed to what, and pushes it to Slack or Telegram. You can address the bot out loud during the meeting and it will pick the instruction out of the transcript.
  • School bot. Scans the personal inbox at 7pm for mail from his kids’ schools, extracts what he must know, summarises the rest, creates the calendar events it finds, and invites his wife.
  • Computer cleanup. The guardrail is the lesson: “I told it, do not delete anything,” and instead categorise into low / medium / high risk. It returned 90GB low-risk (caches, unused Docker images, npm) and 380GB medium — including 100GB of git worktrees — for him to approve item by item. Scheduled weekly.
  • Publishing. A one-line “publish this” that returns a public or private URL in seconds, via a plugin.
  • Food ordering, via a partner CLI where available and browser control where not.
  • Telegram bridge. Not native — you create a bot via Telegram’s BotFather, hand Grok Bot the token, and it wires the rest. Voice notes work.
  • Coding, below.

Routines are cost control, not just convenience. His classification routine runs every 30 minutes between 8am and 7pm on weekdays with a batch job first thing — “so it’s not just burning tokens when I don’t really need it.”

Grok Bot as a coding front-end (reported)

Berman relays a workflow he says came directly from engineers at Cursor, and is explicit that he has not run it himself:

  • A bot per project, and per workstream within a project.
  • Kicked off from Slack; the bot delegates to the Cursor Agent CLI and can launch Cursor cloud agents.
  • The bot holds the surrounding context — Notion, email, Slack, GitHub — and, per those engineers, “collects and persists that context apparently better than Cursor can directly.”
  • It follows up on the agents it launched: look at the PR, and if CI isn’t green, keep going until it is.
  • You read brief summaries instead of the full agent transcript, and can ask for detail on demand.

Treat the “better context persistence” claim as second-hand and unverified — it is a report of what a vendor’s engineers said, not a measurement.

The economics of not using your best agent

Howell writes his newsletter blurbs with a cheap external automation rather than Grok Bot, and the reasoning is the clearest statement of this trade-off in the batch:

“If you have a high-performing employee, I don’t want to waste it writing little two-sentence summaries every week for a hundred items that I may or may not use.”

The pipeline: the research bot fills Notion cards twice a week with candidate stories; Grok Bot filters and keeps the best ones; a cheap deterministic automation writes the two-sentence blurb in a fixed format. Judgement is the expensive part and stays expensive; formatting is the cheap part and gets made deterministic. His caveat is essential — “I got here because I stood up the process and did it manually with Grok Bot first.” You cannot automate a step you have not yet proven.

Sales without boiling the ocean

Grok Bot found Howell a sponsor by monitoring his inbox and surfacing a missed inbound from a local bagel-shop owner, with a recommendation to follow up and pitch a specific ad slot. The sales bot had already priced every ad slot against market rates and newsletter growth, and produced a sales sheet.

His outbound rule is a routine, deliberately small:

Monday: add five prospects to the list. Then pick the top three, build an ad package custom to each, draft the outbound, and send it to the chief of staff.

Everything still lands in front of him for a final edit. “You’ll make more progress doing that, I promise you, than doing 200 outbound emails at a time.”

Try It

  1. Choose one business or one project. Not two. This is the source’s single strongest warning.
  2. Run the day-one audit. Point a chief-of-staff bot at your existing docs, state that the mission is revenue, and ask for the top three agents to create first.
  3. Do not create a fourth bot in week one. Prove each job through the chief of staff before it earns its own bot.
  4. Give every bot a five-line end-of-day routine reporting to the chief of staff, and have the chief of staff roll it up as shipped / stuck / needs-you.
  5. Take back one decision. If a bot has been comparison-shopping options for more than a few days, make the call yourself and tell it the decision is final.
  6. Add an adversarial QA panel to your highest-stakes output, three rounds, before you review it.
  7. Turn one round of your own feedback into a reviewer skill so the next round does not need you.
  8. Check whether your plugin can actually write. If it only knows how to talk about the service, install the vendor CLI on the bot’s computer.
  9. Guardrail anything destructive with categorise-don’t-act — the “do not delete anything, sort into low/medium/high risk” pattern.

Open Questions

  • Pricing. Isenberg describes it as “300 a month” and Howell reports finishing a heavy first week with ~10% of usage left, but neither states the actual plan tiers or limits. Verify against xAI before budgeting.
  • Whether bots really share one VM. Howell says “they all live on one computer in the cloud” and immediately hedges — “I’m pretty sure on that.” Unconfirmed, and it matters for the context-bleed argument he builds on it.
  • The Cursor-team workflow is entirely second-hand. Berman explicitly has not run it. The context-persistence claim especially needs first-party confirmation.
  • The 76–88 agent cap is Howell’s own arithmetic from shape and colour combinations, and he notes custom avatars are possible — which would break the cap. Not a documented product limit.
  • No Android app at time of recording, iOS only, with Android “coming soon” per hearsay. Telegram is the documented workaround.
  • How do you keep an agent team from converging on its own loop? Isenberg’s proposed answer is a dedicated “idea agent” generating creative direction for the other bots. Howell is openly sceptical and offers only the periodic audit instead. Genuinely unresolved between the two.

Graph View

Backlinks