Grok Bot Day 2 Live Report: Cupcake Game and Multi-Bot Workflows

# Grok Bot Day 2 Live Report: Cupcake Game Development and Multi-Bot Collaboration

During the early hours of September 17, 2026 , I followed part of the second day of Grok Bot's livestream, “Grok Bot builds a Game Studio LIVE.” The team was iterating on Cupcake, a card-battle game prototype, while using specialized bots to connect tools, organize work, make ads, research recruiting contacts, and draft cover letters.

These are observations from part of Day 2, not a complete account of the entire day. The broadcast had ended by around 07:55, and a replay was available at the original link: Watch the livestream replay. (https://x.com/i/broadcasts/1PKqrNyvmYwGb)

The practical workflows are collected in a field guide at the end. Product statements made on stage, visible demo results, and audience anecdotes are distinguished throughout. Promotions and usage-limit claims were not independently verified.

## Around 03:06 — Still on the break screen

Earlier samples showed the player marked LIVE while the main screen stayed on “Grok Bot Galaxy — Be right back.” Chat was already discussing the goal: building the shape of a studio rather than presenting a finished game. Viewers said a working prototype had been demonstrated earlier. One suggestion was to establish a small deliverable loop first: make a cupcake, play once, see a result, repeat, and only then add the surrounding metagame.

There was no product demonstration on the break screen itself. The substantive demo returned in the next observed segment.

## 03:12–03:22 — Cupcake returns: pick, place, fight

Cupcake's home screen offered NEW MATCH and Manage bots. Its pitch was Pick. Place. Fight. Import a bot, assemble a three-member team, and try to counter the opposing lineup over four quick rounds.

The team screen displayed Choose your captain and Your team. Players could drag cards to change battle order, reroll the lineup, and confirm it. The management interface included Hire and Import Bot. Meanwhile, the task panel was adding marketplace imports to the picker and adjusting the floating debug bar, captain/random labels, level visibility, and the action button's wording from prototype to Play. Natural-language assignments were driving interface and code changes.

In the Chief of Staff workspace, Image Gen was asked to explain mechanics and remake skill icons in the existing visual language. A weekly priority board appeared on the calendar at 09:00, Monday through Friday.

The rules screen showed a triangle: CHA over INT by about 22%, INT over DEX by about 22%, and DEX over CHA by about 22%. It explicitly framed this as an advantage, not a guaranteed win. Another heading read Order decides everything. Actions included Hustle, Scheme, Rizz, and Critiquito. One result screen showed WIN, 3–1, and +18 ELO; the rating appeared to move from 1258 to 1276, although those digits were not fully clear.

The stage then shifted to explanations. Krista Letz and Mark Wright were identifiable, with Enterprise GTM / SpaceXAI labels. The agenda included Demo, What we learned, Q&A, and Build. An AI Maturity Curve slide moved through Ask (chatbots), Do a task (copilots), Delegate outcome (bot), and Staff function (team of bots).

The product pitch emphasized familiar messaging, always-on agents, access to the user's tools, focused bots with automations or routines, shareable templates, and retained context and memory across interactions.

The initial team examples were Olive as Chief of Staff, PG for outbound prospecting, Echo for updating slides during customer calls, Customer Expert for strategic accounts, product signals, Slack threads, and feature requests, and Engineer for technical questions. Sales use cases included pipeline generation, customer expertise, engineering support, GTM coordination, and forecasting or pipeline maintenance.

Audience suggestions included proving the playable loop inside the engine before adding a studio layer, making the loop inspectable and preferably public, shipping something rough before polishing it, and writing each bot's role into its description and telling the Chief of Staff. A viewer described an Onshape Scout that could access their Onshape account. Others reported slow responses or trouble adding bots. These were audience reports, not stage claims. A QR code appeared briefly; I did not scan or follow it.

## 03:47–04:00 — Three working habits and a marketplace link

The first What we learned slide offered three concrete starting points.

First, connect the tools you already use: CRM, Gmail, Calendar, Slack, and Notion. The point was to prepare customer context, draft inside those tools, and bring meeting information into the workflow.

Second, hire one bot for one job at a time. Start with a Chief of Staff or a focused responsibility such as meeting preparation, inbox drafts, or prospect research. Describe the workflow as you would to a colleague, and save demonstrated workflows as skills. Clear briefs matter more than elaborate prompting.

Third, put recurring chores into routines: scheduled meeting preparation, overnight inbox follow-ups, and prospecting drafts that can continue after the user closes the laptop.

One Q&A instruction was directly actionable: right-click a bot on the desktop, choose Move to new group or Move to new section, and create a folder. Viewers said the marketplace was also accessible near the bottom-left of the desktop app, above the username. The official @bot account posted the marketplace address. (https://x.ai/bot/marketplace)

Chat asked about usage, limits, and comparisons with Cursor Cloud Agents. I did not see an authoritative answer in this segment. Claims that growing context increased usage were audience reports, not published policy.

## 04:01–04:19 — A Starbase challenge, interviews, and audience examples

After another short break, a challenge slide invited users to show how they used Grok Bot at work for a chance to win a trip to Starbase. The visible steps were to quote the challenge post on X, describe the bot's job, include a shareable bot template link, and follow @Grok. A QR code was shown. The full terms were not independently verified.

A two-person interview followed. Matthew Berman's name and Future Forward branding were visible in the close-up lower third.

Audience examples included a game bot making forms, website themes, and HubSpot pages; bots connected to DoorDash and Instacart for orders, pickup, menus, and budgeted shopping; and group chats where bots introduced themselves and proposed roles, workflows, and routines. Other viewers mentioned a restaurant Bot Boss producing daily reports, job-search and application bots, Spotify playlist organization, and video editing. One person said Grok Bot could create skills for Cursor Cloud Agents covering research, computer use, and file or image generation. These were audience anecdotes, not confirmed on-stage demonstrations.

Usage anecdotes included a meter moving from 12% to 48% in four hours and reaching 100% after ten to twenty-four hours. Questions about marketplace approval, data and intellectual-property sharing, and a $300 monthly tier received no authoritative answer in the observed segment.

## 04:20–04:37 — Everyday chores during the interview

The interview continued. Chat later said the guests would take a break and the builders would return; the player still showed LIVE.

More audience reports described an email assistant monitoring an inbox, clearing unwanted mail, flagging messages requiring attention, and drafting or sending only when instructed. Others mentioned clearing a nearly full mailbox and dealing with water bills. One viewer described generating clips in ComfyUI and assembling them in Resolve, with the machines connected through Tailscale.

Other examples included a multimodal “paper” bot for organizing archives while leaving judgment, taste, and approval to people; an appliance-manual assistant called The Keep, fed photographs of labels, readings, dates, controls, and instructions to help plan maintenance; and bots for health encouragement, meal planning, shopping, and morning or evening reminders. A viewer said a bot had annotated a 59-page contract. Someone asked about analyzing property photos, researching comparable listings, publishing listings, and replying to inquiries. No pricing or allowance answer was visible.

Team invitations, whether Cursor Agent was required, SDR sessions, and community-bot approval also remained unanswered in this segment.

## 04:37–04:53 — Recruiting research meets login walls

Recruiter Finder / Alumni Database Email Finder showed an ongoing research loop: work in batches of roughly ten to twelve people, revisit or skip candidates, consult sources such as LinkedIn and Apollo, classify addresses as valid, risky, or invalid, maintain a list of confirmed identity matches, and export CSV files. The operator could pause or resume discovery and receive milestone or blocker updates.

Failures were visible too. LinkedIn encountered Cloudflare or security restrictions, so the workflow stopped after a short run to cool down. The Stanford alumni directory displayed “You are now logged out” and required a fresh login. I deliberately did not transcribe personal names or addresses. The demo mentioned batches of twelve and ten people, six addresses found in one pass, and five new addresses plus revisits in another. Those were individual demo results, not guarantees.

A Cursor interlude appeared before the stream returned to the Grok Bot Galaxy table. Chat asked whether Bot plus Cursor could cover ASIC design and verification, how to share bots and workspaces with a team, and whether Cursor Cloud Agents could combine research, coding, and file generation. No authoritative answers were visible.

A viewer posted a Day 2 schedule labeled September 16: Sales Engineering at 9:00–10:30, Sales at 12:30–2:00, SDRs at 2:30–3:30, and Customer Support at 4:00–5:00. This was an audience-shared schedule, not independently confirmed on stage; I did not establish its time zone. Other anecdotes concerned dictating ideas in Grok, checking the plan before delegating, selling services using Bot plus APIs, and producing application, rejection, or welcome letters. An extraordinary “$250,000 net profit tomorrow” prompt claim in chat was unverified and is not evidence of capability.

## 04:53–05:10 — Cover letters, Remotion ads, and repository changes

A Cover Letter Writer thread showed a cloud agent drafting letters while a Critic scored them. Revisions were requested only when the Critic called for a rewrite. The operator could pause individual letters, resume the queue, and track handoffs. The visible concurrency cap was 7 in flight. Job sourcing and letter writing were separate responsibilities, with the résumé and job requirements supplied to the writing workflow. This was a demo-specific setting, not a platform-wide limit.

The Chief of Staff received an advertising brief: use existing scratch assets to make branded motion pieces, beginning with a square stacked-card hero composition before other aspect ratios, without inventing a new brand. A Remotion marketplace/plugin installation appeared, describing skills for programmatic animation, audio, captions, and 3D or best practices. The weekday 09:00 weekly-priority-board routine remained visible; other health-check routines were paused.

The code view showed .cursor, assets, docs, scratch, game-loop, index.html, and README.md. The agent reported editing three files, exploring one file, and running five commands, along with PR management, artifact copying, and validation steps. This was one of the clearest implementation sequences in that hour.

Chat continued asking about custom company MCPs, SMTP MCPs for multiple inboxes, attendance workflows, memory, enterprise activity, and team workspaces. No new official usage figures appeared.

## 05:11–05:24 — A square Remotion hero, then a broken preview

The agent switched to main in the cupcake repository and checked installed Remotion skills. It would use what was already on main rather than unmerged PRs, then render a proof slice for Thursday's shipment.

It read the Remotion skills, the Cupcake prototype, and the create, markup, and render documentation before scaffolding. It refreshed the main branch and chose a showcase mint with one card of each rarity instead of seed-42's all-common loot pile, preserving real names, values, rarity, and the holographic logo.

Remotion Studio then showed a cream-colored square composition with a CUPCAKE title and stacked collectible cards. A local preview on port 3000 initially failed. The agent attributed the connection failure to having deleted Composition.tsx and index.tsx before connecting the new hero composition. It restored the composition and continued. A visible status was approximately three files edited, +280/-5. Later, the composition rendered in Studio with its card layout visible.

Another status noted that scaffolding had unintentionally introduced Tailwind; the agent planned to remove it and produce the 1080×1080 hero using the prototype's cards and design tokens. These were live implementation details, not a promise about product reliability.

## 05:25–05:40 — Fidelity review and the maturity curve

The Cupcake/Remotion work entered a styling review. The agent removed an invented rule line, card shadows, and holographic glare, tightened the three-card stack's borders, and inspected BotCard.tsx. The criticism was specific: some details had been invented and did not match the square promotional reference. This was a visible review-and-revision loop.

A separate creative demo turned public profile or website concepts into collectible-card visuals, including profile cards, multiple-card collections, and QR-code ideas. It was illustrative building, not a general performance guarantee; I did not transcribe personal names.

The maturity curve returned with slightly different wording: Ask (Chatbots), Do a task (Copilots), Automate job (Bot), and Staff function (Team of Bots). The product slides described role-specific bots, colleague-like messaging, retained context and memory, and signing bots into the user's tools. They repeated the themes of easy messaging, 24/7 availability, directed work, automations or routines, and shareable templates.

The SDR slide grouped use cases into prospecting, sequencing through maintained CSV/XLS lists, account research using signals such as job postings, and drafting account-specific copy through connected email tools. These were presented use cases, not measured outcomes.

## 05:40–05:55 — A multi-bot workspace and human pipeline decisions

The team slide introduced Simon Bot as Chief of Staff, Shakespeare for email, Web Search for web research, Customer Bot as a Gong connector, and Simon Soldier as an agent army: one role per bot.

The demo moved through a dark workspace with named bots or workflow channels on the left, messages and tasks in the center, and a roster with statuses on the right. It showed coordination between roles rather than a set of benchmark results.

Viewers characterized the setup as a Chief of Staff coordinating email, search, customer/CRM context, and an agent army to reduce window switching in an SDR workflow. That was audience interpretation, not an official benchmark.

## 05:54–06:09 — End-to-end work and bot-to-bot communication

The selected Simon Soldier workflow showed multiple bot channels and member/status lists. A dense, dark prospect table appeared next, suggesting batch research feeding the workspace. The fields were too small to read confidently, so I do not supply names or figures. A viewer proposed a human handoff: research enriches the table, while a person decides what enters the sales pipeline.

The later What we learned slide offered three principles:

- Go End to End: connect multiple steps into a workflow; assess success by how much prompting and intervention remain.

- Be Intentional: bots should communicate with one another. A user should be able to own bots they never directly talk to.

- Think Systematically: consider when a new bot is warranted and the value of preserved context. The lower part of the slide was obscured by the speaker, so I do not reconstruct it.

Simon Lackowski then answered questions on stage. Chat requested monthly-token information and a replay link. No new official figures were visible.

## 06:09–06:24 — A promotional slide and a Cupcake task board

A Want free Grok Bot? slide offered one free month, presented as a $200 value, to the first 1,000 users. The visible instructions involved copying or creating a bot using erggbot and scanning a QR code. This was a livestream promotion, not independently verified. Chat repeatedly asked how the cutoff and redemption worked; the observed material did not resolve those details.

The demo returned to Cupcake's team screen and then the desktop. The Chief of Staff coordinated product planning, Notion tasks, and reading Cupcake specifications. A time-bounded task board prioritized Clerk login/JWT, backend and API wiring, season or match/playlist startup, a playable template, and blocked work. Other ideas were explicitly deferred.

The checklist still identified a gap along web Clerk → Go JWT → /api/me → seasons/match/auth. The interface was supposed to use real API requests rather than local data.

The routines panel explained that scheduled recurring tasks could be created by asking the bot in chat. A dedicated founding engineer bot was brought in to watch the repository and help with features and releases. A Slack bot was proposed to listen for mentions, reply with appropriate topic tags, and update the Notion board. Later, Remotion/Cupcake cards labeled DR EGGBOT and TRABOT appeared.

## 06:24–06:39 — 1Password, Slack wakeups, and three aspect ratios

The promotion gained no clearer eligibility, date, or regional terms. A mock X post instead announced that Grok Bot could use 1Password: share a vault, approve each fill, and keep secrets in the password manager. Visible options included Autofill password and Full login with 1Password. This was an on-screen product statement, not a separately tested integration.

Slack was shown connected, with a mention listener/routine enabled so the bot could wake when mentioned. The Chief of Staff arranged Cupcake tasks as a Kanban board and planned to ping colleagues once Slack was ready.

The Remotion composition explicitly targeted 1:1 at 1080×1080, 9:16 at 1080×1920, and 16:9 at 1920×1080. Review changes were to carry across all three formats.

Knowledge Base Manager listed Creative Director, Cupcake Eng, Founding Eng, Growth Eng, Host Finder, In-Game Ads, Slack Mentions, Remotion Ads, Operator Research, Lead Capture, and several routines. In-Game Ads separated admin, client, and API tasks and stated what was outside the MVP. No new public pricing appeared.

The stream returned to the signed-in Cupcake home screen, offering New Match and Manage your team, with DR EGGBOT and TRABOT still visible.

## 06:40–06:54 — A playable round, Slack DMs, and engineering merges

Cupcake briefly reached a playable Round 1, then returned to design and engineering work. The mechanics notes described a captain plus two unknown cards, ordering before battle, no peeking, and a teaching/reveal loop. The small text did not justify inferring additional rules.

Marketplace bot details showed Share, Uninstall, and a skills list, without new pricing or eligibility terms.

The Ping routine was configured for both Slack mentions and one-to-one DMs. It was described as waking with sender and conversation context and replying in Slack. Cupcake mechanics/design documents were also passed to specialized review bots, Dr Eggbot/Cirt, as context.

On the engineering side, web replay-tape playback appeared as PR #30 and was later marked merged in the demo. A gap check still flagged client/API wiring and earlier playable-loop/card work that had not shipped. These were workspace claims, not independently verified release status.

Paper Stadium's arena shell was marked complete. Its PR summary showed approximately 39 changed files, +2,471/-14, and the result was recorded in the Cupcake plan using Notion as the source of truth. A CSS/Three tape-clash prototype PR was running, with a request to collect a demo video. Vercel-Go API scaffold #32 was also in the plan, with HTTP/E2E work still tracked.

## 06:54–07:07 — Tape Clash wins and an audio bot joins

The Vercel-Go scaffold remained a prerequisite, with the first API deployment PR still pending. Replay-tape work was described as merged. Tape Clash visibly advanced from ready to a second-round clash, a win, and Round 3. A task card labeled the CSS 2.5D prototype Done and referenced a demo/PR. Again, that was a demo-workspace status, not an independently verified release.

The mechanics bot, Cirt/Dr Eggbot, was connected to Lauren's Cupcake review card. The team was told to keep Notion current as the source of truth. A new audio bot named Tone received responsibility for exploring and prototyping game sound effects, linked to a Notion audio task. The stream and chat mentioned an 8-bit SFX prototype; a later status said Tone was working.

The free-month slide returned with the same $200 value, erggbot instructions, first-1,000-user limit, livestream-only framing, and QR code. No date or additional eligibility terms were supplied. The stage then cycled through the agenda, product introduction, rationale, and customer-support use cases, apparently recapping rather than adding new material.

## After 07:08 — Recaps until the broadcast ends

From about 07:08 to 07:55, the player remained LIVE while previously seen customer-support use cases, team introductions, Notion knowledge bases, Slack support threads, marketplace views, and rules screens cycled through. I recorded no new rules, figures, or eligibility information.

At approximately 07:55:49, the page reported the stream had ended “2 minutes ago,” with the replay available. That is the observed page status, not a precise independently established end time.

## Field guide: workflows drawn from the demo

The following steps extract the better-supported parts of the recording. They describe what was shown and how its workflow could be reproduced; they are not a current product manual. Audience reports and unverified promotions should not be treated as official specifications.

## 1. Playing Cupcake: pick, place, fight

1. Start with NEW MATCH; use Manage bots to manage the roster.

1. Bring bots into the picker with Import Bot or Hire. Marketplace import was still being added during the demo.

1. Assemble a three-member team and choose a captain.

1. Drag cards in Your team to set battle order; reroll if needed, then confirm.

1. Play roughly four quick rounds. Demonstrated actions included Hustle, Scheme, Rizz, and Critiquito.

1. Consider the attribute triangle: CHA over INT, INT over DEX, DEX over CHA, each by about 22% on the displayed rules screen.

1. Treat that as an advantage, not a guaranteed win. Battle order matters.

Later notes described a captain and two unknown cards, ordering before battle, no peeking, and a teaching/reveal loop. I do not fill in rules that were too small to read. The 3–1 win and +18 ELO were one observed result. The later Tape Clash sequence is recorded alongside the four-round explanation, not used to rewrite it.

## 2. The two sets of working principles

The earlier slide, screenshot 25, recommended connecting the existing tool stack, hiring one focused bot at a time, and moving recurring chores into routines. Explain the job as you would to a colleague; preserve workflows that have actually worked as skills.

The later slide, screenshot 79, emphasized end-to-end workflows, deliberate bot-to-bot communication, and systematic decisions about new bots and retained context. Its obscured lower text is not reconstructed here.

An audience suggestion complemented these principles: prove an inspectable, playable loop in the engine first, then add the studio layer; write roles into bot descriptions and inform the Chief of Staff.

## 3. Dividing responsibilities among bots

The maturity curve was Ask/chatbot → Do a task/copilot → Delegate outcome or Automate job/bot → Staff function/team of bots.

The sales/customer examples were Olive for Chief of Staff, PG for outbound prospecting, Echo for in-call slide updates, Customer Expert for account knowledge and signals, and Engineer for technical questions. The SDR team used Simon Bot, Shakespeare, Web Search, Customer Bot, and Simon Soldier for coordination, email, research, Gong context, and agent-army work respectively.

Cupcake added creative direction, several engineering roles, hosting research, ads, Slack listening, operator research, lead capture, mechanics review, and sound effects. The organizing pattern was one job per bot: the Chief of Staff maintained plans and routines while specialists worked with their assigned repositories, documents, and assets. In prospecting, viewers advocated keeping the final pipeline decision with a person.

## 4. Marketplace access and grouping

1. The official account posted x.ai/bot/marketplace. (https://x.ai/bot/marketplace)

1. Viewers also described an entry near the desktop app's bottom-left, above the username. That location was an audience report; check the interface you actually have.

1. Right-click a bot, select Move to new group or Move to new section, and create the folder.

1. The detail page showed Share, Uninstall, and skills. The recording did not settle community approval, data sharing, or intellectual-property arrangements.

## 5. A Chief of Staff board and scheduled work

1. Give the Chief of Staff coordination duties rather than making it simultaneously handle art, sound, and backend code.

1. Ask it in chat to create a routine. The demo used a weekday 09:00 weekly priority board.

1. Request a time-bounded task board with ordered priorities: Clerk/JWT, backend APIs, season or match startup, a playable template, and blockers. Defer the rest explicitly.

1. Designate Notion or an equivalent document system as the shared source of truth, and have specialists read specifications and update the board.

1. Assign repository work, features, and PRs to a dedicated engineering bot; keep the Chief of Staff focused on plans and blockers.

1. Put real API usage into acceptance criteria. The visible gap was web Clerk → Go JWT → /api/me → seasons/match/auth, rather than simply displaying local data.

## 6. Slack mentions and direct-message wakeups

1. Establish an active Slack connection.

1. Enable a mention listener or routine.

1. Configure Ping to handle both mentions and one-to-one DMs.

1. Include sender and conversation context when the bot wakes, and reply in Slack.

1. Supply mechanics documents or design cards as context for specialists instead of retelling everything in the chat.

1. Keep progress linked back to the shared Notion board. The demo also proposed topic-tagged replies and a Chief of Staff Kanban view.

## 7. Remotion ads in three formats

1. Brief the bot to use existing brand assets, starting with a square stacked-card hero before other formats.

1. Install the Remotion plugin and confirm the relevant animation, audio, and caption skills.

1. Work from main with merged skills; read the product prototype and relevant documentation before scaffolding.

1. Choose representative cards that preserve real names, values, rarity, and logos. The demo used one of each rarity instead of an all-common pile.

1. Check a Studio timeline preview, then local playback. The live failure involved missing Composition.tsx and index.tsx; restoring the composition allowed work to continue.

1. Review fidelity against the reference. Remove invented rules, shadows, or glare that do not belong, and check the card component.

1. Carry approved changes across 1080×1080, 1080×1920, and 1920×1080 outputs.

The accidental Tailwind dependency was a live debugging detail, not a requirement for reproducing the workflow.

## 8. Recruiting research and a writer/critic pair

For recruiting research, work in batches of about ten to twelve people, allow revisits and skips, validate addresses as valid/risky/invalid, keep confirmed identity matches, and export CSV. Provide pause/resume controls and milestone or blocker updates. Expect third-party sessions and security restrictions to interrupt the process: that happened in both the LinkedIn and alumni-directory sequences. Six addresses in one run and five new ones in another were demo outcomes, not promises.

For cover letters, separate job sourcing from writing, supply the résumé and job requirements, and have a Critic score the draft. Rewrite only when the Critic requests it. Allow individual letters to be paused and the queue resumed, and track handoffs. The 7 in flight cap belonged to the displayed workflow, not an established platform-wide allowance.

## 9. The demonstrated 1Password flow

The mock post described putting the required items in a vault and sharing it with Grok Bot, approving each autofill or full login, and leaving secrets in the password manager rather than in chat. This was a product statement shown on the stream; I did not independently test it.

## Promotions, challenges, and claims that remain unverified

Free month: the slide offered the first 1,000 users a month of Grok Bot, presented as a $200 value, through erggbot and a QR code. Repeated appearances did not clarify the cutoff, regions, eligibility, subscription compatibility, or whether the flow remains available. This report does not establish current offer terms.

Starbase challenge: the visible instructions were to quote the challenge post, explain the bot's role, include a shareable template, and follow @Grok. The complete official post and rules were not independently checked.

Usage and pricing discussion: comparisons with Cursor, a $300 monthly tier, approval rules, data sharing, and usage percentages came from audience comments where noted. I did not observe authoritative answers that would turn those anecdotes into official policy.

The original replay remains the source for this account. Where the recorded screen was unclear, I have left the uncertainty visible rather than filling in the gaps. (https://x.com/i/broadcasts/1PKqrNyvmYwGb)