Most teams do not fail at AI because they lack a chatbot. They fail because the work still requires a human to click through UIs, validate that something actually runs, skim logs, and chase the same inbox, Slack, and GitHub loops every day. That is the bottleneck the speakers were trying to remove on launch day of a 72-hour company build at the Grokbot Galaxy event in San Francisco.
What they recommend you set up is a Grokbot software factory: named bots with jobs, recurring tasks (or event responders), and tight feedback loops so agents can implement, verify, and playtest work with far less babysitting. They used that pattern overnight to land on the order of 160–170 PRs while standing up a game studio and preparing to launch.
The method is the same whether you ship software or not: break human workflows into pieces, decide what an agent should own, pass it the right context, and close the loop with checks before anything auto-merges or reaches a customer.
Watch the walkthrough later if you want to see the bots coordinating on screen. You do not need it to execute the setup below.
Key results you can use immediately
- A recurring task is the first real unit of Grokbot value — email, Slack, GitHub issues, or any other loop that eats your day.
- Specialized bots with jobs beat one general assistant. Their factory had implementers, verifiers, a playtest bot named Play, an audio bot, a 3D prototyping bot, and chief-of-staff bots running the show.
- Potato mode in Pstack (a Cursor plugin and Grokbot plugin) is the rigor layer: it teaches bots to orchestrate other bots.
/potato modeplus “full autopilot this plan” breaks a plan into small phases and stands up a mini factory. - Auto-merge is only as safe as verification. Their autopilot path implements small PRs, runs the app, fuzzes it by clicking around, and merges when checks pass.
- Pass context so you are not the clicker, the log-reader, or the QA intern. If CI is green, a playtest bot can drive the product end to end and comment before merge.
- Do not let an agent send your email. Let it kill spam, unsubscribe you, draft replies, and surface only what you need to look at.
- Launch is not walk-away. They planned load tests, UI polish, a user-feedback loop stored safely and serviced to the team, plus stretch work on Suno music and 3D.
Who this is for (and who should skip it)
This is for a founder, operator, marketer, or ops lead who already has — or will open — a Grokbot account and has at least one repetitive workflow worth a daily or event-driven routine. The software path assumes GitHub-style PRs, a CI suite, and enough comfort to let bots open small pull requests. Pstack and Potato mode assume you will use that plugin in Cursor and/or Grokbot. Non-engineers can still use the email / Slack / GitHub-issue pattern without merging code.
Skip this if you need a tool-agnostic SOP that does not depend on Grokbot, or if you came for Grokbot marketing operations. The speakers were about to cut to that talk; this session does not teach it. Also skip if you want guaranteed load, security, or revenue numbers — they had not proven the launch under traffic yet.
How a Grokbot software factory actually works
The point is not a metaphor. Lauren (Potato) and Roshan spent the previous night brainstorming game mechanics with Grokbot and Cloud Agents, then turned the plan into an army of Grokbots that implemented UI, backend, security, and polish while people slept. Lauren does not love the word factory. She uses it anyway because it is the closest analogy for something highly automated, and because the same idea applies outside engineering.
Break down all these human workflows, isolate them, and then figure out how you can have an agent that does all this stuff that an agent should do.
Isolate the human workflow before you add bots
You are trying to find the manual steps that currently sit between “work exists” and “work is trusted.” In their software loop those steps were: click through UIs, validate that things work, and look at logs. In ops, Lauren’s example is email — she avoids the inbox because of spam, replies, and not knowing what needs a response.
Prepare a short list of loops you already dread. The speakers’ examples: searching through email, watching GitHub issues, looking at Slack, reviewing PRs, playtesting a product, collecting user feedback, and (for a live show) running an agenda. Good looks like a list of jobs, not a list of tools. Failure looks like asking one bot to “be the company.”
Give every bot a job, not a personality overlay
Name the bot after the work. Play’s job is playtester: any good game needs QA; they had an intern the day before and did not have one on launch day, so the bot filled that seat. Implement agents own small PRs. Verify agents run the application and fuzz it. A chief-of-staff bot (Steve / Steven) ran production: live agenda, notes on screen. Cupcake was another named bot on the crew. An audio-engineering bot existed for sound design; a separate bot did 3D prototyping for animation.
What good looks like: you can point at a bot and say what it does when a PR opens, when CI goes green, or when an error hits. What failure looks like: untitled bots and no owner for the output.
| Use case | Bot / tool | Input needed | Output | Owner |
|---|---|---|---|---|
| Ship small product changes | Implement agents in the factory; Potato mode / Pstack | A plan broken into phases | Small PRs | Engineering |
| Trust the change | Verify agents | The PR and a running app | Checks, fuzz clicks, bugs found | Engineering |
| Playtest before merge | Play (QA bot) on a recurring / event task | PR that is green on CI | End-to-end playthrough and change requests | QA (bot), human merge policy |
| Inbox triage | Grokbot recurring task | Your email | Spam gone, unsubscribes, drafts, only what you must see | You — do not auto-send |
| Watch Slack or GitHub issues | Grokbot recurring task | Those channels / repos | Attention on the loops that steal time | Whoever owns that queue |
| Run the day | Chief-of-staff bot (Steve) | Agenda / production notes | Live run-of-show | Ops / production |
| Audio / 3D stretch | Audio bot; 3D prototyping bot; Suno for tracks | Design intent | Music and 3D animation experiments | Product, after core launch |
| User feedback | Collection loop into the factory | Feature requests, likes, dislikes | Stored, serviced to the team, then implemented if important | Product |
Recurring tasks and event-driven Grokbot routines
Download Grokbot, create an account, create a bot, and set up a recurring task. That sequence is the on-ramp the speakers kept repeating — including as the condition for a live new-user month of their highest tier (they described that month as about $200 of usage). Even without the promo, the operating rule is the same: a bot that is not on a schedule or an event is just another chat window.
Prepare one loop you already do badly or slowly. Lauren’s bar is simple: things that take a lot of your time are the ones to automate. You can tell Grokbot to check your emails every day and let it set the routine up. Potato planned to tweet examples: searching email, watching GitHub issues, looking at Slack.
- Pick one repetitive source: inbox, Slack, or GitHub issues / PRs.
- Create the bot and attach a recurring task, or a responder that fires on an event (their Play bot watches PRs).
- Tell it the job in plain language: what to scan, what to ignore, what to bring back to you.
- For software, point the same mechanism at CI: when a PR looks green, the QA bot jumps in.
Good looks like a bot that shows up without you opening the app — Play commenting on green PRs, an inbox pass that happens daily. Failure looks like a bot you only remember to ping when you are already drowning.
Potato mode, full autopilot, and overnight PRs
This is the software-specific core of the Grokbot software factory. After the first version of their game felt like a 1v1 rock-paper-scissors Elo / leaderboard toy and was not fun, they used Grokbot and Cloud Agents to craft a new plan, then ran it through Pstack. Pstack is Lauren’s personal set of skills, available as a Cursor plugin and a Grokbot plugin. Inside it, Potato mode teaches bots to be more rigorous and better at orchestrating other bots.
Break the plan into small phases
Type /potato mode and tell it to full-autopilot the plan. The speaker’s claim is that it will break the plan into lots of small phases and set up a mini factory: some agents implement the small PRs, others verify. You are trying to avoid one giant change nobody can check.
Good looks like many small PRs instead of a monolith. They talked about a UI rewrite (PR 124) that still needed rebases, plus backend upgrades, security work, and load-related changes. Overnight they were in the 160–170 closed-PR range (live counts moved from “more than 100” to 145, 160, 170). Treat those figures as what they saw on the board, not as a benchmark you must hit.
Verify, fuzz, then auto-merge
Verification is why they were willing to let PRs auto-merge in full autopilot. Verify agents run the application. They fuzz it — they click around, test it, find bugs — and that is what creates “a ton of trust.” Without that, autopilot is just unsupervised commits.
Prepare: a running app the bots can exercise, and a CI suite whose green status means something. Steps: implement small PR → verify / fuzz → only then auto-merge. Good looks like merges you did not babysit because checks already played the thing. Failure looks like merging on compile-green alone, or hoping the database “can handle the load” without tests. They still wanted load tests before going wide.
Add a playtest bot on green CI
Play watches each PR. Using a subscription / recurring task that can also respond to an event, it looks for PRs that are green on CI, then playtests: drives the UI, plays the game end to end, knows how the engine works, and leaves feedback on what should change before merge. That is the replacement for the missing intern.
Good looks like QA comments arriving while implementers keep moving, which is what they showed as bots coordinating. Failure looks like shipping CSS clipping, scrolling bugs, and login errors because nobody drove the product. They hit an X / Twitter login failure on stream and treated it as work for the next hour, not as a vibe check.
Use the same factory pattern for email, Slack, and GitHub
Matt’s summary, which Lauren signed off on: set up really good feedback loops so agents can do work themselves. Remove the manual steps. Give the agent the right information and context. The same way you do that for software, you do it for email and other business operations. That, in their framing, is what it means to build a company with AI.
Maybe an agent shouldn’t be sending emails for you but it can get rid of all the spam.
Prepare the policy first: what the bot may do unattended (filter, unsubscribe, draft, summarize) versus what you still send. Then attach a daily recurring task. Good looks like a shorter list of messages you actually need to see, plus drafts. Failure looks like an agent talking to customers as you.
They also used the factory on the product itself after the mechanic pivot: a card-based battler (code name cupcake) with guest mode, Twitter sign-in, a global leaderboard, matchmaking, a shop, gold they might rename to tokens, and a pool of characters. Fun fact they called out: the in-game bots were real bots from the Grokbot marketplace — at least 70 — with generated avatars. That is optional flavor, not a required step. The transferable move is: when the first design is not fun, re-plan with Grokbot and Cloud Agents, then let the factory polish instead of starting from zero in the morning.
Keep a human in the loop after you launch
They were not going to launch and walk away. Off-camera plan for the next hour: UI polish (feel of the game), backend load tests and security confidence, and a user-feedback loop — submit feature requests, likes, and dislikes; collect that information; store it safely; service it to the team; implement what matters. Collecting feedback, they said, is essential to product development. They already had a long roadmap: revisit the audio bot and Suno tracks as a stretch goal (“we promise we won’t make it annoying”), and revisit 3D prototyping for characters and animation.
When an error appeared (login with X down on Matt’s side), the move was not only to stare at it. Look at the server side, then pass it to Grokbot. Lauren’s add-on: you can tell Grokbot to open that. Good looks like errors becoming bot tasks. Failure looks like the human becoming the integration layer again.
If we’re not embarrassed by it, then we’ve launched too early.
Prompts, bot instructions, and workflows
The session did not include long system prompts. These are cleaned, copy-ready reconstructions of what they actually told people to type or set up.
Potato mode, full autopilot (as spoken):
/potato mode full autopilot this planDaily inbox routine (reconstructed from the speaker’s description):
Check my emails every day. Go through my inbox, get rid of spam, unsubscribe me from lists, and send me only the messages I need to look at. Help me come up with a draft reply where one is needed. Do not send email on my behalf.PR playtest bot (reconstructed from how Play was described):
Whenever a PR looks green on our CI suite, jump in and playtest it. Drive the entire product end to end. You know how the game engine works. Provide feedback on what might need to be changed before we merge.Error handoff (reconstructed from the speaker’s description):
Open this error. Look at what is going on on the server side and fix it.Recurring-task starters they named out loud: search through email; keep an eye on GitHub issues; look at Slack. Keep the instruction that specific. Do not expand the bot into “run the company.”
What “working” looked like overnight
The speakers did not give hours saved, cost per PR, support-ticket deflection, or lead counts. The checkpoint they used was throughput plus willingness to auto-merge: more than 100 PRs overnight, then live counts around 145–170 closed, including a UI rewrite and backend / security work they hoped would hold load. They also noted they would have to see how much Grokbot usage the build actually burned against that highest-tier month.
Qualitative checks they cared about: bots coordinating in public, Play commenting on green PRs, guest mode so anyone could try before signing in, Twitter sign-in working, a leaderboard with tiers (including a platinum tier they wanted players to chase), and a path to put player feedback into the same factory. Database load, scrolling, clipping, and login were still open risks, not claimed wins.
Where Grokbot automation fails if you skip the loop
- Auto-merge without verification. Full autopilot is justified in their telling only because implementers are paired with agents that run the app and fuzz it. Skip that and you are merging hope.
- Agents that send as you. Spam, unsubscribes, and drafts are in bounds. Sending the email is called out as something an agent maybe should not do.
- No QA owner. When the intern is gone, someone still has to drive the product. If you do not assign a Play-style bot to green PRs, CSS and login bugs ship.
- Launching past embarrassment. They still had scrolling issues, clipping, a sponsorship form to move, art that did not fill the card, and an X login error. Polish and load tests were the next hour, not optional flavor.
- One bot, no jobs. The factory works because Play playtests, verifiers fuzz, implementers take small PRs, and a chief of staff runs the agenda. A single untitled agent does not replace that.
- Walking away after ship. They already had a roadmap and wanted feedback stored safely and serviced to the team. A factory with no intake loop just ships the first idea forever.
- Assuming load and security are done because bots touched them. They said fingers crossed, then scheduled load tests. Until those pass, treat capacity as unknown.
Human stays in the loop for: anything customer-facing that sends, launch go / no-go under load, what feedback is actually important, and brand feel (UI, audio that should not be annoying). Bots stay in the loop for: repetitive scans, small PRs, verification, playtest passes, and opening the error you just found.
7-day plan to stand up your first Grokbot factory
This follows their sequence — account and one routine first, then named bots and closed loops — not a generic agile sprint.
Day 1. Download Grokbot, create the account, create one bot, and attach one recurring task. Use email, Slack, or GitHub issues — whichever you already avoid. Write the policy in the task: what it may filter or draft, and that it must not send as you. Confirm it actually runs without you poking it.
Days 2–3. List the human workflows you still click through. Name bots after jobs (playtest, implement, verify, chief of staff, feedback intake). If you are shipping software, brainstorm the plan with Grokbot and Cloud Agents the way they reworked a not-fun prototype into something they were willing to launch. If you use Pstack, turn on Potato mode and feed it the plan; do not skip the phase breakdown.
Days 4–5. Close the software loop: small PRs, verify/fuzz, Play-style bot on green CI, auto-merge only after those checks. In parallel, run the boring ops routine daily and tighten what it brings back. If you are putting anything in front of users, do the load and security testing they refused to skip, and practice the error handoff: see it, pass it to Grokbot, tell Grokbot to open it.
Days 6–7. Add the post-launch loop they treated as essential: a way for users to submit likes, dislikes, and feature requests; store that safely; service it to the team; implement what you judge important. Keep updating instead of walking away. Only then consider stretch bots (audio via Suno, 3D prototyping). If you are not embarrassed by the UI, you probably shipped too early — keep the polish factory on.
The business outcome is not a clever dashboard of agents. It is fewer hours lost to inbox dread, PR babysitting, and missing QA, with enough verification that work can move while you sleep. Stand up one Grokbot, one recurring task, and one named job this week — then watch the video for the walkthrough of the factory coordinating in real time.
Grokbot software factory FAQ
What is a Grokbot software factory?
It is a set of specialized Grokbots plus recurring or event-driven tasks and verification so agents can do the work you used to click through yourself. In the session that meant implementers, verifiers, a playtest bot on green CI, and ops routines for email, Slack, and GitHub. The speakers used it to ship on the order of 160-plus PRs overnight while building a game studio in 72 hours.
Do I need to be an engineer to use this?
No for the ops path. Lauren’s pitch is that even if you do not do engineering work, repetitive tasks — email, Slack, GitHub issues — are fair game, and you can tell Grokbot to check your emails every day. Yes for full autopilot PRs: that path assumes a plan, small pull requests, CI, and bots that can run and fuzz the app. Non-engineers should start with one recurring task, not Potato mode auto-merge.
Potato mode vs a normal Grokbot chat?
Normal chat is you asking a bot to do something once. Potato mode, inside Pstack, is a skill that makes bots more rigorous and better at orchestrating other bots. /potato mode with “full autopilot this plan” is what they used to split work into phases, implement small PRs, verify, fuzz, and auto-merge. Use chat to think; use Potato mode when you want a mini factory, not another conversation.
Should Grokbot send emails for me?
The speakers say maybe not. Their recommended split is: strip spam, unsubscribe you from lists, send you what you need to look at, and help with a draft. That still leaves you as the sender. If your first recurring task is inbox, write that limit into the task so the bot cannot “help” by talking to people as you.
Do I need Cursor and Pstack, or is Grokbot enough?
Grokbot alone is enough for account, bot creation, recurring tasks, and event responders like Play on PRs. Pstack is Lauren’s skill pack — a Cursor plugin and a Grokbot plugin — and Potato mode lives there. If you are not shipping code, you can skip Pstack. If you want the overnight PR factory they described, you need that rigor layer, not only a chat thread.
One general bot vs a factory of named bots?
They did not run one omniscient assistant. Play playtested, other agents implemented and verified, a chief-of-staff bot ran production, and separate bots touched audio and 3D. The factory concept is job isolation plus feedback loops. If you only have one bot, give it one recurring job first; add named bots when a second loop appears.
What recurring task should I set up first?
Whichever loop you already dodge. They named email, Slack, and GitHub issues, and they required a recurring task even for the live new-user promo. For a product team, a Play-style responder on green PRs is the software equivalent. Do not start with music, 3D, or marketplace avatars — those were stretch or game-content moves after the core loop existed.
When does this fail on a customer-facing launch?
When verification is weak, nobody playtests green PRs, load is untested, and you walk away after ship. They still had scrolling, clipping, and an X login error, and they would not claim the database was ready. Keep a human on send, on go-live, and on which user feedback gets built; let the factory take the repetitive scans and the small, checked PRs.