Pivoting to a game studio and
building with a fleet of botsA technical account of Galaxy Day 2

Team introductions and a look back at yesterday

Matt introduces themself as SpaceX's developer experience lead and Roshan as the product lead. Lauren introduces themself as "also known as Potato" and says they work on Grok Bot at SpaceX AI.

They spent yesterday on account setup, brainstorming, and agreeing on a direction. They chose an experiential pop-up business, and look back on time spent confirming the concept, setting up the environment, and prototyping and demoing.

Why they dropped the pop-up idea

Lauren says the pop-up turned out to be more than they could handle. After hearing from yesterday's guests about the difficulty of San Francisco's regulations and permits, they felt that showing that work on stream would not be interesting.

Matt explains that overnight they had a bot research the idea, and the result that came back was that it could not be fully pulled off in 2 days. Lauren sums it up as "the bot recommended the pivot."

• They also cite the judgment that building something viewers can use together would be more fun as a reason for the pivot.

The new idea: a game built on templates

Roshan says they want to build a system where viewers and attendees can make their own Grok Bot templates and play with them. They pick a game company as the most fun form, and set the goal of having everyone play with their own bot in the first game.

They lay out a plan to spend 20 to 30 minutes in the morning drawing on the whiteboard, have Lauren explain the MVP plan, and then keep building between talks.

What a Grok Bot template is

Lauren explains that a template is a mechanism for sharing a bot you made with other people. It includes skills, routines, and some memory that has been generalized so it does not leak anything confidential, and examples line the in-app marketplace.

As an example, they note that if someone builds out a bot that is strong at PM work and shares it, someone else can use the result. Anyone can make one starting today, by building a bot and saving it as a template.

Turning a template into a battle character

Roshan draws the flow "Grok Bot Template," "Character in a game," "Compete head to head" on the whiteboard. A template turns into a character, which battles characters other people have made.

Following games they like, they set the stats as 3 kinds: charisma, dexterity, and intelligence. They also design each bot to have 1 ability that draws on one of the stats. Lauren says "charisma ability" sounds too technical and they want a cooler name, and Roshan gives the example of giving their bot, Dr. Eggbot, a flavorful skill name.

A team starts as 3 bots: the imported lead bot plus additional bots. In Lauren's example, the 3 were Dr. Eggbot, a chatbot, and an outbound sales bot with a long name.

Assigning stats deterministically

They make the conversion deterministic, so the same template always produces the same stats. They propose splitting a total of 100 points across the 3 stats by having an LLM read the bot's description text to decide the allocation. For instance, a role that brings people together would score high on charisma, and a role that connects to many services would score high on dexterity.

In the discussion of a minimum value, they start with a proposal of 10 since 0 would be odd, then end up lowering it to 1, allowing for a split like "1, 1, 98."

Rarity changes the total

Roshan says they want to bring in the rarity system found on items in action RPGs like Diablo. The base total is 100, and rarity modifiers increase the total. The whiteboard reads base 100, rare 125, ultra 150, legendary 200.

They leave the exact numbers for later, treating this as a rough guide for now.

Avoiding pay to win in monetization

Lauren says, "if we're pivoting to a game studio, we need revenue too," and asks how to earn money without becoming pay to win. Roshan dislikes charging for mechanics that just pull people back the next day or limit the number of tries, and lays out a policy of charging for fun extras rather than for strength.

As ideas, they list cosmetics, unique visual items made with the Grok Imagine API, and access to different arenas. Matt proposes ad slots that don't affect the game, like stadium ads in sports, and shared replays that let people watch a battle afterward.

They agree to prioritize growth and layer monetization on later, once the product's shape is clear.

• The whiteboard's "monetization" column reads cosmetics and unique items, stadium ads.

The core of a battle is matching stats

Roshan sketches a simple form where a bot with a charisma ability faces off against a bot with an intelligence ability, and stats are matched up to decide the fight. The content of an ability is generated by an LLM, and a special bonus rolled at creation time adds variation to each battle.

You set the lineup for your own team, get matched against an opposing team through light matchmaking, and watch the result back as a replay. The plan is to expand from this simple version toward static upgrades, ability changes, and arenas with different characteristics.

What's left to do as a business

Matt lays out that even though the product is a game, the other parts of building a company don't change. They list the stream itself as a distribution channel, along with SEO and AEO, a landing page, and ads, and mention the possibility of getting help from the guest coming after the next break.

For customer support, on top of email and phone, an idea comes up to pull in X chat so they can hear directly from viewers. They plan to put growth-oriented bots on customer support and operations in general. The whiteboard's "product needs" lists ads, marketing, more team members (interns?), seed funding?, figure out distribution (hey chat), call us.

Narrowing the MVP flow to 4 stages

Roshan redraws the bottom row as 4 steps: "Grok Bot Template," "Draft your team," "Set your lineup," "Compete!" The algorithm work of balancing battles and creating a reason to come back remains.

They explain this is designed to start small while leaving room to grow, and say they also want to use this material to show off the development workflow built around their plugin, pstack. Their view is that the same steps apply to the surrounding work of an app or a physical store.

Lauren's plan document, and the switch to a talk

Lauren had been writing a rough plan during the discussion, using pstack's planning playbook. pstack is a plugin Lauren built as a collection of engineering skills, and it produces a long plan that includes a verification checklist and pseudocode for types and function signatures. The screen showed docs/plans/01-mvp.md, "Cupcake v1 program plan," on GitHub.

Partway through the explanation, Matt announces that the first talk for sales engineers is starting on the main stage, and the stream switches to the talk.

Day 2's schedule and the shape of the talk

Amrita introduces themself as a field engineer at Cursor, and explains that day 2 has 4 workshops, for sales engineers, sales, SDRs, and customer support, plus following along with Matt, Lauren, and Roshan building their company.

In this talk, they show 3 bots they use regularly. 2 are set up for the demo, and 1 is a bot they actually use every day to build case study slides for customers. The venue's tables have coasters with QR codes that load templates.

From a chatbot to a team of colleagues

Using the maturity slide also shown the day before, they explain the idea of moving from one-off requests to a team of bots that work through tasks together. Grok Bot returns "finished work," keeps running while you're on vacation or asleep, and can be talked to from your phone like a colleague.

They recommend the Android, iOS, and Mac apps, and introduce a layout similar to iMessage with bots lined up on the left of the screen, along with long-term memory that remembers earlier feedback.

A computer dedicated to each bot, and admin controls

Because each bot has its own computer, users don't have to connect every service themselves. They cite examples such as the Google Form creation from the day before, and logging into MongoDB to check a database, which they heard about from an attendee.

Users can take over a bot's computer and operate it directly, and a company's admins can block access to specific sites or downloads.

Automation, routines, and sharing

Amrita uses a routine every morning that pulls AI newsletters and podcasts from email and sends a summary to Slack. A morning Slack recap of what was missed overnight is also a common use. They say that on a distributed team, this means not having to wait on other people or tools.

The coaster's QR code is a public marketplace bot, while internally they use the sales team's bots and bots shared by the engineering team. They also cite the benefit that, once a bot is shared, sales bots don't end up referencing conflicting materials.

Why Grok Bot

It's easy to get started, since the bot asks you what you want to use it for. They preview that today's demo will show how a bot can spin up another bot.

Because it runs continuously in the cloud, it finishes work without stalling on approvals. The point they stress is that by the time you come back, you're in a state of polishing finished work.

4 uses for sales engineers

The slide's 4 uses are "Engineer," which answers technical questions, "Competitive Intel," which tries out and compares competing products, "Echo," which updates materials during a deal, and "Customer Expert," which looks at customer usage. They leave the details of Engineer for David's later customer support talk, and the demo of Echo for Krista and Mark's later talk.

Sherlock is the technical bot that can read Grok Bot's repositories, tuned to avoid leaking IP and to phrase things so a non-technical audience can follow. Serena Williams, named after the player who studies opponents, is the competitive research bot; it uses competing products on its own computer and reports the differences from their own product.

Having Mimi build a case study slide

Mimi is the research bot for customer proof slides, and it has access to a Google Slides deck that collects SpaceX case studies. The case studies are unified in a problem, solution, result, quote format, and it had just made a code review case study for Jellyfish.

In the demo, they hand over the URL of a blog post where Salesforce wrote that it "cut legacy code coverage work by 85%," and ask for 1 slide in the same format. Mimi edits the slide on its own computer, pulls the logo from the brand page, and returns a screenshot.

The fictional airline FlyLo, and Sherlock

Switching to a different account, they introduce FlyLo, a booking site SpaceX built for the demo. It has a frontend, a backend, a web app, and an internal app for crew, and Sherlock has been given an explanation of it plus access to the repositories.

When asked the day before what happens if the same seat, or the last remaining seat, is booked at the same time, Sherlock looked into it, found that the protection lives in Postgres, and that proceeding to payment holds the last seat for 10 minutes, and even prepared wording to tell customers. It uses a Cursor cloud agent for the research.

• They explain that if you have it send an answer straight to email or Slack, you can require approval before sending.

Having Serena try competitors' booking screens

Asked which competing products are worth comparing to FlyLo, Serena first sends Sherlock a message asking about the current baseline for booking features. Amrita picks Southwest and Spirit from the candidates, and Serena starts working through Southwest's booking flow on its own computer.

Partway through, they add an instruction to also check whether it has an AI travel agent feature. Serena doesn't stop its original work, and folds the added question in as it proceeds. At the same time, on Sherlock's side, cloud agents had started up on the backend and frontend repositories.

Putting the 2 bots in a group chat

Mimi is stuck on a login problem, so they resend the request. Sherlock and Serena get put into a group chat so their exchange can be seen in 1 place. The wrong participant gets added at first, so they redo it.

When asked which decisive differences from competitors could be implemented with low effort, both bots bring their own context and start discussing it. The result can be turned into a PR or a product doc and handed to the technical team.

Not stopping just because there's no plugin

The marketplace has plugins for things like Google Docs and Atlassian. For a tool with no MCP or plugin, like Microsoft OneNote, the bot logs in and uses it on its own computer.

Citing Power BI and MongoDB as examples, they repeat that not having an MCP or API is not a blocker.

Teaching a task by recording the screen

One private skill was taught the day before, for slide animation. In the demo, they take over Sherlock's screen, start "Teach a task," and record the steps of opening Expedia's tech blog through Google, finding AI-related articles, and reading them.

After the recording, they add by voice, "find AI-related articles from competitors, I want to keep our AI features current," and Sherlock learns it as a skill. A skill can be created on any bot, and every bot can then use it.

The group chat's conclusion

Sherlock points out that, from the code's perspective, the lowest-effort, highest-impact item is "booking management": the backend already has retrieval by PNR and email, sessions, and cancellation, but /trips is still a stub. Next, it names the "flexible date calendar," which the frontend is wired up for but never calls.

Serena replies that round trips and baggage matter a lot for competitors but aren't low effort, and asks Sherlock back which of Southwest or Spirit felt more inconvenient. The bots can be seen tagging each other with questions.

Having a bot build the bots it needs

Amrita asks Sherlock to think up and launch bots useful for its competitive analysis with Serena and for sales engineering. Asking a Chief of Staff bot tends to produce inbox management and scheduler bots, but this time they wanted to see what the technical bot would choose.

For a sales engineer just starting with Grok Bot, they recommend having Grok Bot itself suggest bots that fit your own workflow.

Mimi's slide is finished

Noting that "there was an outage early today," they check Mimi and find 2 Salesforce slides done. The logo is small but the right one, and the slides follow the problem, solution, result, quote format. They then hand over a case study article on Grab and ask for 1 more slide before Q&A.

To avoid ending up with the same purple, AI-looking slides, they recommend passing along a template, memory, and context. They also introduce a workflow of requesting several case studies at once and hiding the slides that don't fit a given prospect.

The 3 bots Sherlock made

Battlecard Blair combines Serena's field research with Sherlock's code knowledge to produce short comparison materials. Demo Drake writes demo scripts and talk tracks that map a customer's problem onto FlyLo's actual flow, and it is set up to always ask Sherlock for grounding before making a claim.

AI Radar is set up to find AI-related articles on competitors' tech blogs, using the skill taught earlier. Amrita remarks that it might overlap too much with Serena. They also cite, as an advantage, that Grok's models say clearly when they can't do something.

Q&A: bot detection, MCP versus computer use

Asked whether bots get blocked on sites like Facebook, they answer that on some sites they can't get through. They recommend that at a company, admins block sites that aren't needed for work.

Asked whether MCP becomes unnecessary as computer use spreads, they answer that MCP is "an API for agents," is fast right now, and is easier to manage in terms of what's allowed and disallowed. They expect computer use to get faster going forward.

Q&A: changes to production and approval settings

Asked on X what guarantees production won't be changed if a bot can access internal systems, they answer that this is handled through Grok Bot Enterprise's protections and rules enforced by skills.

Turning on the "Auto review" setting lets you choose "check first" instead of "allow automatically" for conditions such as deploying to production or using internal systems.

Q&A: tools that don't run on Linux, and tokens

For a tool with no MCP that doesn't run on Linux, they answer plainly that "there's no way to do it right now." A bot's VM is Linux, so it can only use tools that run on Linux.

Tokens get consumed both by conversation and by a bot's computer use. They say their understanding is that Grok 4.6, released a few weeks ago, is cheap and high-performing, and is the foundation for Grok Bot. Their whole set of talk materials cost about $20 to $30, versus 4 to 5 hours if done by hand. Telling a bot to cut down on how wordy its replies are also cuts consumption, but they answer that the amount of computer use can't be tuned down.

Lauren's screen goes down, and Matt takes the wheel

Lauren is "currently offline," so they switch to Matt's screen. They settle into a "backseat driver" setup, with Lauren explaining how to do things from the side and Matt doing the actual operating.

Matt has the same setup as Lauren: Dr. Eggbot, which builds bots, and a founding engineer bot in charge of the landing page.

Sharing the plan doc to have the landing page designed

The MVP plan document Lauren wrote in the bot's context is in the repository, so Matt shares the information with their own bot by pointing it to that document. They ask, "the first goal is the landing page. It's a monorepo, so read the plan and use the project planning skill to propose a structure for the lander."

The project planning skill spells out ready-made scaffolding to use for a new project (T3 or TanStack, Expo for React Native, Next, or Vite for something simple), plus UI and style guidelines. On top of that, they use a skill called "make interfaces feel better" to polish the details. The author is someone on X whose name they can't recall, and they leave it out rather than risk getting it wrong.

• OG meta tags and site metadata go in every time, since they change how a page looks in search results and social posts.
• Following a "subtract before you add" principle, Grok Bot drops the waitlist and returns a revision narrowed down to v1.

How Grok Bot and Cursor split the work

Matt breaks it down as: Grok Bot is the lightweight work environment, and Cursor is the coding environment. Grok Bot handles conversation and back and forth, and Cursor handles the actual implementation, and since both run in the cloud, nothing is happening on the local machine.

On terminology, they explain that typing "/potato-mode" in Grok Bot, or writing "use potato mode," is understood by any bot that has the pstack plugin.

The creative director and the asset playground

For working out the look, they use DialKit (spelling estimated from the audio), an open-source tool for adjusting UI, and build a playground where sliders move flat SVG pieces. Matt has never made a game and only knows the name Phaser, so they have a bot research it and work backward to the technology.

For visual reference, they cite Super Auto Pets, which Lauren recommended, aiming for a light, fun look.

Giving the engineer bot's spec by voice

Lauren advises that if your main bot (in Lauren's case, the Chief of Staff bot, Steve) already has the context, it's best to go through it to Dr. Eggbot. By voice, Matt says, "have Dr. Eggbot build an engineer bot. It launches a cloud agent with pstack and Potato Mode, and its role is to supervise and check the results. Keep the first stage focused on fast, lightweight prototyping. We don't need login yet, since we don't even know if the game is fun."

Matt adds at the end, "don't make it purely for prototyping, give it enough durability to hold up for more serious work later," and closes with Lauren's preferred pattern: "repeat it back in your own words before you start."

Tuning the look and constants with sliders

They ran the asset playground locally on Roshan's screen. Abstract shapes line up as bots, and an idea comes up to give colors meaning. Lauren says building this alongside the prototype at the same time would make things complex, so the basic prototype should be made touchable by everyone first.

Roshan says that being able to change in-game constants, like a rock-paper-scissors-style relationship between CHA and DEX, or a 22% bonus, in real time in this playground and replay them means not having to wait on an agent. They frame it as a tool for "shortening the time to fun."

Preview deploy, Slack emoji, and the Notion update

On Matt's screen, the founding engineer bot is working on a preview deploy, and Dr. Eggbot is in the middle of repeating the earlier instruction back in its own words. A growth-focused engineer bot is also doing separate work.

As an aside, Matt mentions that earlier in the morning they had Grok Bot fetch Bufo meme emoji from a distribution site and register about 1,200 of them on Slack using computer use. The knowledge base bot writes the pivot to a game studio and the product plan's core loop into the Notion company doc. Next up is the landing page, SEO, A/B testing, and an ad foundation.

A break caused by a hardware problem

The whiteboard diagram also goes into Notion, as a reference bots built later can use to learn the business. While they're deciding whether to talk tech while waiting on the bots' work, a screen problem hits, and at the 1:41 mark they announce, "we have a technical problem, so we'll step back for a bit," and go to break.

Recovery and sorting out roles

Roshan restates that "we're building a game studio and its game in 72 hours" and switches to Lauren's screen. Lauren positions Cursor as a coding tool and Grok Bot as a bot for knowledge work, and says engineering iteration goes through Cursor.

Because the local agent does not hold as much context as the bot, Lauren has it read the documentation placed in the repository and restate the game's content. It comes back with key points: a short battle loop, a 3-bot roster, a lineup order hidden from the opponent, battles against separate accounts, and an Elo rating.

Thinking about Elo and matchmaking

Lauren, who has no experience designing matchmaking, said the plan is to reference public materials on games like Marvel Rivals. Elo works like a chess rating: it rises when you win, and the amount depends on the opponent's strength, and for now they keep it simple.

Instructions for the prototype

There were 5 instructions. For the prototype, skip sign-in and focus on the game loop. Use Potato Mode's prototyping procedure. Build multiple prototypes so there is a choice. Local only, no database needed. Add a debug panel with sliders and input fields to quickly change the game's variables and constants.

Use part of xAI's bot marketplace for the default bots. The reasoning given: if the game isn't fun, nothing else matters, so strip it down to just the core loop and check whether it's fun by changing values and replaying in real time.

How Potato Mode works

Potato Mode is a "routing skill" without detailed instructions of its own; it points to the skills and principles to use for each situation. Among pstack's principles is "experience first" (user delight over implementation convenience, features must be justified, ship less but better, and keep prototypes as throwaway HTML to make design decisions cheap).

The agent planned to build the loop from simple in-memory objects and marketplace seeds, and then the "architect" skill started having 4 models compete on design proposals. 4 candidates lined up on screen: Claude Fable 5.1, GPT-5.6, Cursor's Grok 4.6, and Composer 2.5. Different models were strong in different areas, Lauren explained, which helped catch constraints that got overlooked.

• Since a prototype does not need competing designs, Lauren said "skip architect" and moved ahead with Grok for the first prototype.

The design document: plain HTML and state transitions

The design Grok returned called for building a disposable prototype in plain HTML, CSS, and JavaScript, keeping state in memory, offering 3 switchable UI options, and pulling the marketplace's bot list as mock seed data.

It even wrote out data shapes and types and the state transitions, which were close to a state machine. Potato Mode's skill placed weight on data structure, and Lauren said "that decides almost everything." The "Alternatives considered" section gave reasons for rejecting an approach that kept each page independent and one that recalculated without snapshots.

Watch closely, or hand it off

In answer to Roshan's question, "when do you check the output, and when do you hand it off," Lauren said that on a mature codebase, like Grok Bot itself, architecture is where the time goes, without watching the agent closely. On a new project like this one, though, Lauren wants to stay in the loop to watch for mistakes the agent repeats.

Running the first prototype

A bot pool, lanes, and a debug panel appeared on screen. Lauren picked Dr. Eggbot, the other 2 were random, and all 3 were common. While discussing the lineup order, Outbound Prospecting turned out to have 72 CHA but a DEX-type ability called "Hustle," while Dr. Eggbot's ability was "Riz."

They noticed a bug where the total did not add up to 100 and asked for a fix. Reloading brought it to 100. The debug panel has a slider for the affinity bonus, but the slider's own motion was off; using design mode in Cursor's browser, Lauren pointed directly at the element and said, "this input is off and doesn't slide right, fix it."

Battles resolve instantly, presentation comes later

Lauren laid out that the game's visuals and logic do not need to block each other: once matchmaking finishes, the result resolves instantly, and the animation can be shown afterward. Roshan agreed with a design where, once the lineup order is set, it resolves automatically.

When they ran a battle, Dr. Eggbot lost round 1. On the DEX versus INT matchup, Projects Manager's INT rose to 18.3 with a 22% bonus and won. There is also a feature to run multiple simulations, and the 3 of them confirmed the basic logic held together.

Exploring screen mockups with image generation

Since a look like a Kanban board is not playable, they referenced Super Auto Pets and had image generation make mockups. In parallel, Matt showed a separate, personally "vibe coded" prototype. It had a binder of bots with rarity, a reorderable lineup, a battle screen, and a results screen with Elo change and a replay ID, and Matt called it "all fictional."

An Icon Coffee user story

The stream cut to a pre-recorded segment interviewing Marcel, co-owner of Icon Coffee, a coffee shop in San Francisco that Matt frequents. Marcel started organizing the flood of email from Marcel's son's school, using a Grok Bot given access to the parent portal.

At work, Marcel gave a bot named Rex API access to the POS system, and asked it from a phone or PC for comparisons against 2 years ago and growth rates, and handed it photos of the menu to review which items were not selling. Marcel said it "gives back 1 to 2 hours a day."

Generated screen concepts and hologram-style CSS

The images that came back had too much text and colors that were too strong, but some ideas looked usable, like bot cards with ribbons. Lauren suggested a gacha-style reveal animation for pulling bots, and an idea to color-match a team.

When they layered on a CSS library that adds a Pokemon-card-style sheen, every card ended up glowing rainbow, way too much. Lauren admitted, "I went off on a tangent and gave the agent the wrong instructions," and redirected work back to the visual prototype.

Turning thinking blocks into skills

Lauren has a habit of opening and reading collapsed thinking blocks, and says realizations like "why did it decide that without even looking at the code" have been the source of many of Lauren's own skills. Matt described putting into practice the advice that when an agent reasons incorrectly, rather than just moving on with the next instruction, a skill should be created or updated to prevent the same mistake.

How to balance rarity

Lauren pointed out a problem: if a bot's stats are fixed at creation, then the moment someone shares a legendary bot, everyone uses it. Roshan proposed decoupling rarity from the bot itself and rolling it randomly each time a bot is imported, so that even with the same Dr. Eggbot, only the person who rolls legendary gets the stronger version.

There was also a view that this could lead to a metagame of hunting for the best bot and give people a reason to build new templates, and they left it undecided at this point.

Is there strategy in lineup order

When they went full screen, they realized the lineup section should be split into its own screen, so in design mode they circled the area and asked, "move these lanes to a separate page." They ran the round 1 battle again with Dr. Eggbot (common) and won.

Lauren pointed out that as things stand, there is no reason to care about the lineup order, and weak bots just do not get used. Roshan raised ideas to vary how stats matter by arena, and to carry HP over across multiple rounds. The card-flip animation went over well. They took a 2-3 minute break for the next guest.

Introduction and current bot lineup

Roshan introduced Karen, a creative technologist with over 3.5 million followers, showing Karen's Cursor projects (the rotary phone and Vestaboard) and the Grok Bot newspaper on slides. The moment Karen came on, the first line was a joke, "Grok Bot, can I get some water?", and a staff member brought water.

Karen's bot names are not fancy, 1 per task. Besides a Chief of Staff, there is package tracking, reality-show tracking, and about 30 newspaper bots made while testing templates. Karen used to rely heavily on Cursor, but often felt "I don't actually understand this" looking at the code, and moved to Grok Bot, which makes decisions on Karen's behalf and hides what does not need to be shown. Behind the scenes, Grok Bot runs Cursor to write code.

A newspaper that prints overnight

The newspaper posted to X last week is personalized for Karen and prints overnight. The goal is to start the day without touching a phone in the morning. It pulls meetings, expected package arrivals, weather, and to-dos from the calendar and email, turns subscribed newsletters and Substacks into a reading section, and builds a comic based on that day plus a crossword drawing hints from Karen's own life.

Karen showed the camera the actual copy printed that morning. The comic happened to be about that day's event, depicting Karen getting an Uber discount code, heading to the venue, being there, and heading home. The avatar is made to resemble Karen, and glasses or outfits can be specified in text.

The template's setup steps and printing

The template is about 30 pages of prompt, the first half being the questions asked during setup and the second half being layout and design rules. It asks for name, where you live (for weather and local events), calendar and email connections, avatar, and wake-up time, and starts working 1 hour before that. It works, in Karen's words, as a "newspaper alarm clock," and Karen sleeps next to the printer.

Once setup is done, the bot looks for a printer on the network and starts printing. When a friend tried it, printing started suddenly, surprising the friend. By default, it is set not to put dollar amounts or medical details on the page. Roshan called it "real magic" that all Karen had to do was ask it to find a printer on Wi-Fi and print.

Trial and error on the layout, and how it's distributed

The first version looked bad, and after repeated rounds of feedback, the bot came to choose CSS and fonts suited for print. The finished template's PDF and CSS are hosted on Cloudflare, and loading the template pulls the fonts and files from there. Users only need to press "import bot."

A phone built in Cursor, and package tracking built in Grok Bot

The project on the left of the slide is the "world's dumbest smartphone," built in Cursor before Grok Bot existed: ask a question on a rotary phone, and after hanging up, the answer appears on a split-flap display. Connecting the APIs took a long time, and every time Karen was asked to commit to GitHub, the feeling was "I'm not a developer."

In Grok Bot, Karen built package tracking. It checks a separate email for packages 2 times a day, checks more often once something is out for delivery, logs into Amazon to send a screenshot of how many stops away the driver is, and also checks DoorDash. Connecting to Vestaboard was just pasting in an API key, and the display started moving 2 minutes later. Karen says, "writing code became invisible to me."

What's next, and where the ideas come from

Next, Karen plans to connect a robotic pen that has an API and have it draw a full-size newspaper, which will be the next video. Karen says this past week has brought too many ideas to allow for sleep.

The ideas come from Karen's own problems. Last year, 1-2 times a month, Karen ran an experiment going screen-free from Friday night to Sunday morning, but it was inconvenient, unable to even check a store's closing time. From the experience of glancing at Instagram with one eye in the morning and having the whole day fall apart, the idea of printing only the necessary information was born.

Other bots, and requests

A restock bot that checks daily for out-of-stock colors and sizes sends a notification when just 1 item comes back in through a return; it can auto-purchase, but was set to manual since Karen is traveling. A show-tracking bot reports on renewal decisions and air dates. Karen also built a conditional branch operating iMessage, sending a friend a screenshot every 2 minutes once an Instacart driver comes within 10 minutes.

The request was fixing the problem of logins for various services dropping on the VM, which Karen said happens often with the bot that tallies up subscription costs. Karen can be reached as Karen X Cheng on each social network and at newspaper.karenx.com, and the template is also in the personal category of the marketplace.

The screen flow drawn in tldraw

During the break, Lauren opened tldraw in Cursor's browser and sketched the game screen (working title Cupcake), the match screen, captain selection, and a team page. The captain is a bot you pick yourself, and the other 2 are assigned randomly. An idea also came up to record who first imported a given bot.

Asking the agent to "look at the browser" makes it screenshot the mockup and pull it in as context. Lauren said the first prototype looked like trading cards, which isn't the game Lauren wants to play, so the aim is a look that is big, minimal, and fun.

Showing relative strength instead of numbers

The flow is: pick a captain, drag to set the order, confirm, search for a match, and reveal 1 bot per round against the opponent (in the example, @mattyp's Matt bot). A stats-heavy display like "random 2 uses Riz at 37%" isn't fun, so strength is shown conceptually, for instance with a number of arrows.

Roshan proposed splitting stats into 4 tiers, and Lauren proposed hiding the numbers to test the feel of it. They settled on legendary bots staying hidden from the opponent and being revealed only the moment they're used, for extra impact. Both acknowledged the win/loss presentation needs design help.

The second prototype comes in

The prototype arrived, including a mockup they had not asked for. The login is fake, and it shows a tier like Diamond instead of Elo. The idea is that "Diamond" is more engaging than "Elo is 1372." It came with a large LOSS screen and a summary screen listing every bot, which can be used to review strategy or to share.

In design mode, they circled the whole screen and said, "this doesn't match the mockup, make it 3 cards: a big one for captain selection and 2 more." It reached the stage of deciding lineup order with Lingxi's Engineer Bot as the lead.

Fix requests for the battle screen

The round ended in an instant. Saying "ship it and fix it later," they still asked for fixes: show only the avatar instead of the whole card, remove the stats row, advance automatically to the next round after a few seconds, and automatically search for a match if there is no input for 5 seconds.

For showing tier changes, "Diamond -5" was hard to read, so they settled on placing a medal like Bronze next to the name and showing the number on hover. Roshan had been pushing straight to main without opening a PR, and while saying "there's no time for PRs," Roshan said they would switch to PRs once all 3 of them were touching the code.

The animation approach and the leaderboard

Matt had it research animation frameworks for games and considered code-driven, procedural animation. Lauren pointed out that Grok Bot's avatars are 2D but look 3D through rotation, so the decision was to build in 2D first and swap it out later.

Lauren recalled the leaderboard and replays as bragging material, and kept v1 as just an Elo-sorted list. Since Dr. Eggbot's stats are weak, Lauren also showed off a "cheat": using the debug panel to switch its ability to CHA at 43, and decided to hide the debug panel at deploy time.

Bots in code, icons via Grok Imagine

Matt showed the procedure of an image-generation bot built before the pivot. It generates artwork with Grok Imagine, removes the background with fal's RefNet v2 (estimated from audio), and turns it into a transparent PNG icon. However, a PNG does not play well with JavaScript animation.

After discussion, the decision was to represent the bot body itself in code, so it can handle state flexibly, and use Grok Imagine only for ability icons. Matt's Chief of Staff was tasked with explaining the game's mechanics to Cupcake Eng, the image-generation bot, and asking it to make icons that follow the existing design language.

Keep descriptions from being overly specific

Lauren explained that a bot's description is close to its "soul" or "system prompt" and affects behavior. Dr. Eggbot's description is written thick, making it a specialist focused on 1 job.

But Cupcake Eng's description was tailored too closely to this conversation's specific problem and was hard to reuse. Agents tend to write the details of whatever just happened into skills or rules, and left as is, that turns into "a grab bag of unrelated examples." So Dr. Eggbot was asked to reread Potato Mode and rewrite the description in the form of principles. The labels are cosmetic for now, and Lauren's bots are named after food, like tater, mash, and hashbrown.

Comment Sicko, and polishing

pstack has a skill called "Comment Sicko" that removes comments. The reasoning is that agents tend to explain a workaround in a comment instead of fixing the root cause, and left unchecked, that makes the codebase unmaintainable. The rewritten Cupcake Eng description came out cleaner, but had parts that repeated Potato Mode's content, which they decided to trim later.

Roshan polished the locally running prototype in design mode: pinning the header to the top, fixing a problem where numbers on a rotating card drifted away from the card, and running several fixes in parallel using "multitasking." On the idea of putting the debug menu behind a feature flag, Lauren pointed out that "a runtime check still ships with the code and can be tampered with from the console," and confirmed battle logic will eventually be decided server-side.

What to do about the landing page

Matt was fixing up the landing page using Grok 4.6's low-reasoning, fast setting together with design mode, removing the placeholder wording and fictional bot names and replacing them with real marketplace bots such as Dr. Eggbot, Tradbot, and Overheard.

Lauren pushed back, saying, "we don't need a landing page at all, visitors should go straight to signing in with X." Roshan said having an entry point felt more natural, and they compromised on keeping only a hero deck of cards and a large Play button that leads to signing in with X when pressed. A QR code for installing Dr. Eggbot was also shown on stream.

Splitting up the work before the break

With 10 minutes left, the team decided on the split: Lauren takes authentication, getting all 3 of them able to sign in and battle; Matt moves forward on assets, a short tutorial, and ability icons; Roshan works out the flow across rounds 1 through 3, a framework for placing ads in the stadium, and a server-side anti-cheat design.

Elo persistence is working, and Roshan dropped to 1258 after a losing streak, then won once. For the problem of mashing the reroll button to chase a legendary, the plan is to keep reroll while hiding the 2 randomly assigned bots first. At 3:58 the session wrapped with "halfway through," cutting to a sales-focused talk.

Speakers and format

Krista and Mark, both from SpaceX AI's GTM team, run through introductions, the case for sales, use cases, Krista's demo, lessons learned, Q&A, and hands-on time, in that order. Mark explained that they moved from one-off Q&A a few years ago, to tasks, and now to handing over goals like "build a pipeline" or "get a meeting with that company."

Mark listed the traits of Grok Bot: an iMessage-like look, one bot per job, memory, telling it a lot about yourself, staying signed in the same way, automation with routines and skills, and sharing templates. Mark said Krista used it heavily first, and sharing Krista's templates got the team moving faster.

Sales use cases

Mark listed pipeline, technical questions that come up in sales, Echo, Chief of Staff, and forecasting. Engineering questions no longer have to bother a sales engineer, since you can just ask your own Grok Bot. Forecasting used to be manual work, but it can become a routine.

Krista's team

Olive (named after Krista's dog) handles day-to-day work, PG builds outbound leads, and Echo reflects use cases discussed in discovery calls into materials. The customer expert tracks pre-renewal usage, product trial signals, and Slack activity for strategic customers, and matches the shipped changelog against requests from a month ago to create outreach hooks. The engineer bot is used instead of asking a colleague on Slack.

In the demo, Krista showed Olive preparing for a morning meeting during a bus commute, and drafting an email card in response to a customer's request for a one-pager. Krista said routines are kept to 1 or 2 runs a day, since more than that gets noisy. Krista also asked Echo to translate a slide into Japanese.

PG: picking up personal openings

PG is based on a PG skill from the marketplace: it picks 5 companies from Salesforce (100 also works) and ranks contacts. Company-level facts like "we raised funding" are the kind of thing everyone sends, so it picks up personal openings instead, such as a CTO's X post about a software factory or a CEO's story about a new product.

It watches podcasts and webinars for Krista and pulls quotes from what the other person said. Krista used to listen to 45-minute webinars during a commute, but couldn't keep it up. Before sending, it learns from Krista's own Gmail, Slack, and X writing to "de-slop" the generic LLM style. Krista said meetings with executives have increased.

• Krista recommended connecting the X API. Krista cited Apple's CEO joining X as an example, framing it as a place to follow executives' recent posts.

Salesforce updates and the Notion customer database

From Granola and Gong call recordings, it drafts the Salesforce next steps using Krista's own format: initials, date, customer outcome, and next step, and Krista reviews it before it's applied. When Krista asked the room who likes updating Salesforce, the reaction was that no one does.

The customer expert bot uses Notion as its database, and after calls updates the account plan, signals, renewal date, stakeholders, and projects. It asks about the top 20 power users, gathering feedback or having them try new features before a renewal.

The engineer bot and a partner that gets things done

The engineer bot is connected to the codebase. During a deal, Krista asked it to "write up the cloud agent setup steps for a customer, and add outcomes from Amplitude and Fair (a guess from the audio)," and it returned steps and customer outcomes in a form that could be pasted into Slack.

Krista said that at first, they asked it to look things up like a chat, and it sent back a webinar link, so they pushed back with, "watch it yourself, and write the email." The lead-generation bot processes a long list overnight, and the emails are ready by morning. Krista adds about 20% more work each day, such as LinkedIn copy or 10 more people. They also use it for travel and expenses, an X bot via the X API, and learning new topics.

Lessons learned: the stack, 1 bot 1 job, routines

Mark added that the engineer bot sped up next steps in deals. Three takeaways: connect your CRM, Gmail, calendar, Slack, Notion, and Granola or Gong. Instead of a vague "help with sales," set up a Chief of Staff or a single-job bot, explain it the way you would to a colleague, or show it once and turn that into a skill. Turn meeting prep and overnight drafting into routines, so all that's left in the morning is to review and send.

Q&A: tokens, where to keep knowledge, and how to split bots

For saving tokens, the suggestions were: cut back on routines (someone had set one to run every 15 minutes), go directly to a specialized bot instead of routing everything through Chief of Staff, use MCP wherever it's available, and reserve computer-use for tools that have no MCP. Mark, by contrast, said the load runs heavier through Chief of Staff and routines, and Mark asks Grok Bot itself for optimization advice.

For knowledge-base questions, the answer was to connect the places where company knowledge lives (Notion and Slack, Salesforce, Databricks) and use Grok Bot as a cross-cutting retrieval layer. Delegating to Cursor is as simple as saying "launch a cloud agent" in natural language. Whether to split bots by major customer is a matter of preference: Krista runs one bot per strategic customer, while Mark splits a per-customer bot from the one that builds demos.

Q&A: templates, other teams, rolling out to a team, and how Echo works

Off-the-shelf skills and templates can be edited for personal use, and Krista shares templates on X. Interaction with other departments is still through Slack, but Grok Bot can be set to track specific channels. For team rollout, the growing pattern is that each person uses it first, then role-specific templates get handed to new users. You can build and share these inside Grok Bot.

The Echo workflow is: record with Granola during the call, then run Echo after stopping it, and materials update in about 2 minutes. Gong takes a few minutes to load after a call, so it suits the next meeting or sending materials afterward.

The Starbase invitation contest

To close, Krista announced a contest: describe the Grok Bot you can't live without and include a link to a shared template, follow @grok and @bot, and quote the contest post, and you and one guest could watch a Starship launch at Starbase.

Introductions and how production has changed

Matt introduced Berman as a friend Matt has done pop-ups and collaborations with. Berman has made content on AI topics, model evaluations, news, research papers, tutorials, for about 3 years, and spent roughly 20 years in the tech industry before that.

Berman recommends people not use AI for ideation or deciding what to make. On the other hand, in the last few weeks, editors Brian and Alex have started editing video by dictation, letting several edits run in parallel. The behind-the-scenes work, sponsor management, meeting notes, follow-ups, proposals, is automated, and Berman expects human value to shift toward the creativity of building a story.

The family bot

The one Berman uses the most is the family bot. Berman's two kids go to different schools, do several sports and after-school activities, and get 3-page emails from teachers and coaches every 2 days. The bot reads every email, summarizes anything family-related into 1 to 2 sentences, and flags anything that needs action, such as "you need to tell the coach whether you're attending."

It's connected to the family calendar shared with Berman's wife, adds events automatically, and flags conflicts to help with scheduling. Once connected, there's no need to set it up again, and it remembers preferences like "don't book meetings in the morning." Berman's wife accesses the same bot through a shared Telegram, using it without thinking about how the memory works underneath.

How this differs from earlier personal assistants

Berman says the first inspiration for this kind of use case came from seeing "OpenCloth" (a guess from the audio), but early AI assistant software was a lot of work to manage and fix. With Grok Bot, that hassle is gone, it "just works."

Matt summed up this year's personal-assistant trend as mostly people setting up a Mac Mini or a VPS to run their own agent, but running it safely ends up needing the cloud anyway, and Grok Bot provides that with no setup. Berman agreed, saying that when they want to fire off one email on a walk, they don't want to think about what's running underneath.

Selling unused stuff by just sending photos

Berman gathered a PlayStation not turned on in a year and a half, a mountain bike, a MacBook, and other things from around the house, took photos, sent them to Grok Bot, and just asked it to "list these." All Berman did was log in to Facebook and eBay. The bot researched the items and finished the listings, pulled the going rate for similar bikes sold in the past 6 months, and after listing, answered buyer questions automatically, checking with Berman on anything it couldn't answer or on offers to lower the price.

The PlayStation and MacBook sold. The mountain bike is still being negotiated, since the buyer wants an in-person handoff, and a new offer came in even during the conversation. Matt said personal problems like this take almost the same shape as work problems like negotiating with a supplier.

Sponsor proposals and information search for a new hire

At Berman's company, Forward Future, Grok Bot knows the types of ad slots, prices, inventory, and past deal relationships. It pulls a transcript from the meeting recording in Fathom and produces the proposal at the end, so Berman only has to fix small details.

Matt joined Cursor, then moved to SpaceX around the time of the acquisition, and used Grok Bot, then still in development, to search for information as a new hire. Having it look up things like "who owns this" or "past cases where this got stuck on permissions" from Slack and Notion brought the number of questions sent to Matt's manager and colleagues down to almost zero. Berman pointed out that this cuts not just "context switching" but "context searching," and touched on how it differs from the criticism Microsoft Recall received.

How credentials are handled, and reviewing an electricity plan

Matt explained that in some earlier demos, passwords showed up in plain text, but in Grok Bot, credentials go into a vault, and the agent itself never sees the password.

Berman took a screenshot of a 3-page plan-change notice from PG&E and gave it to Grok Bot, asking it to "look at 12 months of usage and the bills, and decide which plan to switch to." All that was needed was logging in to PG&E, and it found that a plan suited to overnight EV charging would save about $1,000 a year. Berman had it check the calculation 2 times and switched that morning, before the conversation. Berman said it took about 60 seconds of attention.

• The discussion turned to how even low-value chores become worth doing if they don't cost your attention. Examples raised included canceling an unused $9.99-a-month subscription, and having it look into a confusing medical bill.

Many agents and cognitive load

Berman said, "more work gets done than before, and I'm busier than before," and admitted to struggling with the load of switching between results while kicking off many agents and coming back to them.

Matt introduced the pattern Lauren had described earlier in the stream: use Chief of Staff (Lauren calls it "Steve") as the single point of contact, pair it with Dr. Eggbot, which builds bots, and only talk to that single point of contact, letting it gather results. Berman said they're the type who splits bots by topic and checks each one individually, but that they've started wanting to funnel summaries into Chief of Staff. Matt closed with, "running 10 cloud agents makes you a permanently overloaded manager. We're at the stage of learning how to handle that as an industry."

The Nokia customer video

The stream cut to a video of an SVP from Nokia's product development organization describing a plan to use Cursor as the foundation for agents and roll out specialized agents per role. The SVP said that analyzing a monolithic codebase of over 50 million lines, which would normally take a dozen or so specialists several months, was done by 2 people in a few weeks.

There are more cases of running root-cause analysis on customer-impacting defects across a large volume of service requests, and the SVP described a plan to next use Cursor as the foundation for deploying and governing multiple agents, shifting engineers' roles toward supervising agents.

Introducing the intern, and 4 paths to a job

Matt (the Matthew from earlier in the stream had left by now, so, as they put it, "only 1 Matt was left") and Roshan welcomed Shardul, a third-year Stanford computer science major who had been arranging coffee for the venue, as "the first forward-deployed intern." They said Shardul uses Grok Bot heavily enough to burn through a usage cap in half the usual period.

Shardul named 4 approaches: cold applying, finding a listing and applying within a few hours (big companies get 200 to 500 applications), startups looking for people who can ship fast, direct outreach that turns a coffee chat with an employee into an introduction to a recruiter, and pitching on a livestream. Roshan pointed out that this has the same shape as lead generation in sales.

Collecting emails from recruiters and alumni

Recruiter Finder searches for recruiters in a browser running on the bot's VM, confirms them on LinkedIn, checks whether an email address exists using the Apollo browser extension, and writes the results out to a CSV. It targets software engineering roles at tech companies.

Alumni Database Email Finder searches the university's alumni directory for "alumni who work at Google, Microsoft, or SpaceX AI," and collects into a CSV the emails the directory returns. There's no integration involved at all, it's just given access to the directory site and to email. The plan is to connect both to Outlook's MCP and send coffee-chat requests and questions about hiring steps, but that hasn't been done yet.

2 bots that write cover letters, and 1 that checks them

Applying needs a resume and cover letter tailored to the job posting. Cover Letter Writer, built just 10 minutes earlier, has Shardul's resume plus stories about Shardul's experience: an internship at Stanford Medicine, projects, and games. SWE Job Application Bot collects listings from GitHub repositories, Greenhouse, and Ashby and hands over the posting, and Writer looks into the company's values before building the PDF using a "cover letter creator" repository Shardul built. That repository was built with a cloud agent.

Cover Letter Critic is the checker, and sends things back with, "this doesn't sound like you." Shardul said splitting the role that writes from the role that checks is the same idea used in a codebase. Drawing on experience from several rounds of interviews, Shardul strongly recommended never lying on a resume.

Teaching the critic bot Shardul's voice

Early cover letters were full of short, empty sentences like "I want to work on agents." Shardul gave it papers written before 2022 so it could learn a personal style: complex sentences, heavy use of gerunds, and an enthusiastic tone.

The critic checks 4 paragraphs. The first covers the role, why the candidate wants it, and what they want to get out of that role. The second and third each draw on one story from experience, checking that it matches the job and shows results. The fourth briefly sums up the 2 stories and states concretely what the candidate wants to build at the company. Matt added that when you spot an agent's mistake, tracking down the root cause and adding one line to a skill lets agents keep improving over time.

A bot for work logs, and game ads

Matt has an agent that looks at Slack, Notion, GitHub PRs, and X posts every day and every week and turns them into a bulleted log, used for standups and explaining Matt's own work. Roshan brought up something Lauren had said the day before, that "a codebase is the best example of memory."

They moved to the topic of go-to-market for games and asked Shardul what makes a game take off. The answer: word of mouth and consistent posting, building a community once a single post takes off, early adopters on X, getting feedback from Reddit communities that don't get much attention, and on LinkedIn and TikTok the first 2 to 3 seconds are key, while Instagram doesn't suit it.

Spinning up the Remotion Ads bot

Matt said motion assets can be built with Remotion, using code as the source of truth, without a video-generation model. Matt asked Chief of Staff: "use Dr. Eggbot to build an ad bot for Remotion. Make it 1:1 for X ads, use the existing scratch assets, and prioritize the lander's hero (the stack of cards)."

Chief of Staff (Steve) found a Remotion plugin and installed the skill. Roshan added that installing a skill someone else has put together improves the agent's behavior. The bot started work as a Cursor cloud agent.

Interview advice, and an existing Remotion project

When Shardul asked how to keep up stamina through final interviews, Roshan named showing technical skill, remembering that interviewers want candidates to succeed, and connecting with people. Matt recommended "putting what you build out online," saying an open-source mindset leads to collaborators and jobs. Shardul talked about the anxiety of posting, and how many people have offered support.

Matt showed an existing project that turned motion assets from the Grok Bot design team, thanking Kenny and Justin, into Remotion code, and explained it's used for video overlays. The generated ad code came to about 6,000 lines across 12 changed files, and since the local port conflicted with another app, Cursor's browser console was used to have the agent fix it.

A square ad video, and converting to React

Shardul said pstack was adopted after hearing about it at the SpaceX office, and pstack commands are now used in Cursor almost every night. During the break, Roshan had been converting a prototype of several thousand lines of HTML and CSS into a React app, getting it ready to connect to Lauren's backend.

Remotion Studio showed the square video using the stack of cards from before. Fixes were layered on, like removing shadows and gloss and tightening the stack, using design mode and Grok 4.6's fast setting. This video came together in about 5 minutes; it's not ready to run as an ad as is, but it can be adapted to a vertical or horizontal ratio. Roshan said Remotion, which puts a code entry point on work like After Effects, fits what agents are good at. Matt's ideal is to also generate document screenshots from code.

Wrapping up, and the Starbase contest

They spelled out Shardul's X handle and vouched for Shardul to recruiters, saying "he's excellent." After a short bit reviewing Shardul's X profile and portfolio site, they repeated the Starbase contest (share a template by September 29 and follow @grok) and moved on to the talk for SDRs.

Maturity, from an SDR's point of view

Simon explained starting by asking a chatbot to draft emails or research a specific account, then moving to a copilot stage where it connected to Gmail's MCP or API and handled sending, and now being at a stage where it gathers context from RevOps and AEs and automates the whole job.

Within Simon's own Grok Bot, there's only one bot Simon actually talks to. Context gets handed to Chief of Staff, which handles interaction with the other bots. Each bot's memory improves the more it's used, so Slack and Gmail get connected to have it learn how Simon talks. What matters most for an SDR is carrying a colleague's methods over as a template, and Simon said, "what works today didn't work 3 months ago."

Why Grok Bot

Because it's always on, Simon can close a laptop, walk out to buy coffee, and give it instructions over the phone. Since Simon has a personal VM, for anything without an API, Simon signs in through the browser and shows it the steps with a screen recording.

For templates, Simon takes in a colleague's and adds personal tone and steps. Simon also recommended showing an imported template to Grok Bot and asking, "what should I add to my own process."

4 use cases for an SDR

For prospecting, at an early-stage startup, the approach works backward from deals the AE closed, or deals that reached stage 1, to find which titles and industries respond well, and builds an ideal customer profile from that. This combines enrichment tools with web search for job postings and funding rounds.

For outreach (the sequencer), a routine keeps updating a lead list kept in a CSV. If someone the AE talked to yesterday said they're "tired of having too many tools," it pulls that context from the Gong recording and changes today's copy. Account research looks at outside signals like PLG power users, funding, and job postings. For copywriting, it's restricted to outbound emails sent to Salesforce accounts Simon owns, and learns with more weight on the ones that got a positive reply, especially recent ones.

Building everyone through Chief of Staff

Losing context every time you switch bots is the most exhausting part, so Simon builds Chief of Staff first, and builds every other bot through it. That way Chief of Staff knows each bot's purpose and end point, and can decide which bot to delegate to and which bots should talk to each other.

The team is Shakespeare (learns email copy in fine detail), Web Search (runs in parallel with an army of sub-bots called Simon Soldiers), and Customer Bot (call context, and what customers responded to in closed deals). As an example, for a FinTech lead, Chief of Staff asks Customer Bot why similar-industry deals closed, and hands that context to Shakespeare to write the copy.

Color coding, and the army's huddle

On screen, bots are color-coded. An orange message signals Chief of Staff running research, a message to Shakespeare means writing copy, and green means delegating to the army. In a group chat called "Army Huddle," Web Search gives instructions to the soldiers, and the soldiers receive whatever context they need. In the demo, they were researching FlyLo, for demo purposes.

The 8 a.m. routine

As an SDR, Simon says it matters that every morning, the day's work is already decided. The most important routine is 50 new leads a day, and Simon has had it learn a personal ranking. For the first 5 Simon will handle, people who reached out and got no reply, or who downloaded a highly relevant resource, Chief of Staff checks the calendar and reserves 15 minutes at 9 a.m.; for the remaining 45, it reserves 1 hour at 1 p.m.

The inbox bot ranks the morning's Slack messages, meeting invites, and outside emails. As a PLG company, it scans every account at 8 a.m. every weekday, picks up signals like new signups or resource downloads, and acts while they're still fresh. The outreach sheet has a Salesforce trigger that stops outreach once an account's stage moves from 0 to 1.

The outreach sheet is Grok Bot's brain

The outreach sheet is a CSV, and Simon admits it's "an ugly UI," but it's rarely checked directly; it's treated as where Grok Bot keeps context. It has outreach, a queue waiting to be added, a lead board, and the day's action items, and email copy even comes with a Gmail draft ID attached. Chief of Staff can also be asked to "score how confident you are that this email is accurate and likely to get a reply."

When copy was first trained, it produced a run of similar emails with just the company name and person's name swapped in. Simon kept going back and forth, having it generate examples, explaining why a given email didn't work, and having it fix it, aiming for a point where not a single email looked templated.

One bot per platform, and 6 research bots

Everything outbound is grouped into a folder, with one bot per platform as the unit that runs in parallel. Shakespeare alone covers email, but a different contact channel or call context needs a separate bot.

There are 6 research bots. PLG Bot looks at Salesforce signups, usage, and lost deals. If a deal was lost over a missing feature that's now shipped, Chief of Staff raises that lead's priority. Amplemarket handles getting and verifying emails to protect deliverability. Company Research uses Sumble to pull the tech stack, job postings, and org chart, for example, who runs the SDR team. Voice of the Customer covers call context, and Web Search connects to X, splitting 200 companies into batches of 40 across the army. Usage Bot uses Databricks to look at GTM's user counts.

The ideal customer profile, turned into a skill

The "prospecting" skill is used for one-off research on a new account. The "Grok Bot ICP" skill holds what's been learned so far about Grok Bot's still-unsettled ideal customer profile, gets updated whenever something new is learned, and can be called by the whole system. Running it produces a CSV with title, persona, owner, and reason, with email and location added from Amplemarket. Orange messages to the bot stream by, making it obvious at a glance that it's in the research stage.

Lessons learned: end to end, with intent, systematically

The first is "end to end." Instead of sending one-off emails, hand over the whole thing: prospecting, enrichment, pulling in context, and outreach. The first round of back-and-forth is painful, but it pays off if you keep at it. The second is "with intent." Don't go straight to each bot; build through Chief of Staff and let bots talk to each other. The third is "systematically." Building a new bot is fun, but making too many creates confusion, so ask whether an existing bot or routine already covers it. This also saves tokens.

Q&A: tokens, the army, and how to get started

The tokens needed to process 50 people a day vary with the number of Gong calls, the Databricks context, and how many people need fresh enrichment, so there's no single answer. It's fine to do 250 on Monday instead of 50 every day, and it's quickest to just ask Grok Bot itself about usage and optimization.

The reason the army isn't connected directly to Chief of Staff, but runs as a group chat with Web Search, is that this lets you check in one place whether each sub-bot's output is flowing correctly, makes it easy to scale from 5 bots to 20, and keeps each soldier's context small. For initial setup, it helps to describe the workflow to Grok Bot at a high level and let it propose how to split up the bots. Someone in the audience said, "I call all my bots soldiers too."

Free Grok Bot invite and progress

Roshan announced a stream-only offer: the first 1,000 people who duplicate a bot with Dr. Eggbot get 1 month (worth $200). During the break, Roshan converted the prototype into a Next.js React app, set up a place for the server side, and split client and server into separate apps.

Lauren said that in a competitive game, players can modify the client to cheat, so the server should decide wins and losses. Authentication is also in progress, and once the server contract is set, they can try multiple clients, such as 3D, pixel art, or an MCP terminal client. They will not ship with more than one, though. A global leaderboard showing only placeholder names was also added.

The Notion task board and dividing the work

Roshan wanted to ship something within a few hours and asked Chief of Staff to "make a to-do list in Notion, read through what's left to implement, and turn it into a plan for the next few hours." Lauren had built a research bot that looks into how other competitive games work, and its findings sat in a separate Notion document.

Bake (founding engineer) uses the GitHub integration to notify them when PRs are created or changed, with Roshan "double-merging" the client and Lauren the server. The remaining big items were publishing the backend, keeping the client web-only, a side path so 3D work doesn't stall, and the ad framework (how the stadium looks, how ads are sold, and pricing).

3 people build Slack bots by voice, at the same time

On the suggestion "let's all turn on voice mode at the same time and build the same bot," all 3 told Dr. Eggbot, "listen for @mentions of my username in Slack and handle things like completed work; Notion tracks progress." Roshan showed that the Notion list Grok Bot had built was a database with a minute-by-minute plan and a page per task.

Roshan usually turns the Notion database into a kanban board, where moving a card to in-progress makes a bot start work. This time, Roshan said a checklist was enough. Both Lauren's and Roshan's Slack bots got named "King" by Dr. Eggbot. They connected Slack with the camera off.

Remotion assets and user posts

Matt showed that since Remotion is code, the same asset can be exported at 1:1, 9:16, and 16:9. They can distribute it per platform, on LinkedIn, Instagram, or X, but it doesn't explain the game. Someone also suggested fitting it into an official Figma device frame.

Among the user posts Matt found: Karen's morning printout (Matt wants a dated diary template printed every morning), an example, as heard, of Lenny Rachitsky paying a parking ticket through a payment-link integration, Alexandra selling on an online secondhand marketplace, and printing math worksheets for kids. Lauren said routines can react not only to Slack but also to Datadog or Sentry events, forming a "factory" where a bot goes to investigate if the backend goes down.

Kanban, sharing to Slack, and a dedicated PM bot

Roshan rebuilt Notion into a kanban board called the "Cupcake board" and had Chief of Staff draft Slack messages to the other two, then sent them. Lauren built a personal PM bot that only handles Notion updates, separate from the Slack bot that handles @mentions.

Experimenting with a 3D client needs the server first, but prototyping alone can proceed. 3D might only need to cover the battle part, and how to translate the bots into 3D remained an open question.

Glow, Crit, and 1Password

Roshan asked Dr. Eggbot by voice for a bot that would use a cloud agent and a Potato Mode swarm in the Cupcake repository to try 3D animation while staying lightweight. The result, Glow, asked "which motion should I start with," and Roshan picked "match and fight." Crit handles game design.

Lauren learned live, during the stream, that Grok Bot had shipped a 1Password integration, and showed the @bot post on screen, saying, "this would have saved 1 day of setting up credentials," and left secrets management as tomorrow's task. Lauren also fixed a problem where a private Notion document was unreadable to the bots.

Fleet pulse, the ad MVP, and explaining to viewers

Roshan's bot had started writing something called "Fleet pulse," a summary that collects only verified facts from PRs the running bots had merged. Matt's ad MVP plan had an endpoint that serves billboards, an ads table, and a data model for advertisers, campaigns, and creatives, but Matt called it "a bit too complex" and moved to trim it.

Answering a viewer question, Roshan showed the current state of the working title Cupcake. Players log in with X, import a bot template that gets assigned stats by rule, pick a captain to set a lineup, battle an opponent who's logged in at the same time to raise their rating, and aim for the leaderboard. On the placeholder leaderboard, Matt's name was in first place, which got a laugh.

Unslopping the AI-sounding critique and making Notion the source of truth

Crit's game design proposal read like AI-generated prose, so on Lauren's advice they had it rewritten using pstack's "unslop" and plain-English skills. pstack can be installed from the marketplace and has more than 40 skills. Roshan had Crit talk to the founding engineer so it would follow the rules. Lauren proposed putting a canonical game design document in Notion that everyone and every bot could reference.

Lauren's Slack bot Ping had a routine for @mentions, and Lauren fixed it to also watch DMs. When repeating the same instruction to bots one by one starts to feel like a pattern, Lauren has Dr. Eggbot fix the behavior of all agents at once (for example, posting to Slack on every decision). Notion cards, such as Clerk, moved to in-progress, and both told their own bot fleets, "Notion is the source of truth, and every bot updates it."

Serverless, deleting tests, and the 3D video

Lauren was rebuilding the backend as serverless functions and said it was a setup being used for the first time. Glow generated a video of a 3D mockup, but on review it still didn't feel like a game engine, with ideas like "2.5D tape collision" and "slam 3D," so someone suggested specifying three.js explicitly.

Tests were failing, but Lauren said, "agents aren't good at tests. Shipping matters right now, so we'll write tests later," and took the approach of deleting all of them for now ("true scrappy mode").

Cursor Projects and full autopilot, then Tone

Lauren showed Cursor Projects, released a few days earlier. A long-running coordinator agent bundles sub-agents together and passes context through shared memory. Her bot Tater ran the project agent, with 5 sub-agents lined up. Potato Mode's "full autopilot" adds a verification agent that runs the code alongside the implementation agent, and at the highest setting, the swarm operates the app and tries it like a user. The project agent started calling "merge" a "mash." The Notion kanban kept moving cards to in-progress and done, and since every agent runs in the cloud, "you can close your laptop and go get boba."

A viewer suggestion turned the conversation to game music, so they added a sound design task to Notion and had Dr. Eggbot create an audio bot called Tone. It explores things like an 8-bit sound, keeps it from being annoying, and puts the results in Notion. They repeated the free Grok Bot offer, then moved on to the customer support talk.

Positioning Grok Bot, and 3 reasons

David described Grok Bot as "an AI coworker you can hand real work to," emphasizing that it keeps working after you send a message. You can start with 1 general-purpose bot, or with a team of specialists; either works.

There are 3 reasons. It runs always-on, without using your own computer, plus routines triggered by cron or events. You can use it in conversation even if you're not comfortable with an IDE. Connectors to existing tools are in a marketplace, and you can have a cloud agent build any that are missing, instead of waiting on a vendor's roadmap.

4 uses in support

Answering tickets expands by "crawl, walk, run." First it reads and produces a summary and the root issue, then a draft, then it attaches the draft as a ticket note, and once there's confidence, it actually sends the reply. Adding evals and traces lets you check its thinking and actions before it goes live.

For notifications, say this quarter's focus is churn: anyone on the team can build a routine that hourly classifies tickets where a customer of 6 months or more hints at leaving, and notifies Slack. For internal Q&A, where existing support products lean toward customer replies, it combines public docs with internal operating procedures to answer coworkers' questions in Slack. Finally, it can review traces or last week's tickets to look for areas to improve.

Start with 1 bot

The 4 bots in the demo are Build, which does the setup, Reply, which answers in tickets and Slack, Alert, which gets contacted by Reply, posts to Slack, and also notifies the person directly, and Tune, which improves the system. But you don't need to set up this structure from the start; David recommended teaching 1 generically named bot 1 procedure, then splitting it up naturally once its scope grows.

The knowledge base, tickets, Stripe, and Slack

The Notion knowledge base held public docs (product, authentication, billing), internal policy (the refund SOP: cancel and refund within 14 days, decline after that), and the rules for the Grok Bot support agent (read the ticket, look for knowledge, decide whether to answer or hand off, act, and leave a note). FlyLo was set up simply, as just a $20-a-month in-flight internet subscription.

Tickets were preloaded in Plain, subscriptions were managed in Stripe, and Slack was also set up. Build has Plain, Notion, Supabase, and Slack installed as connectors.

An easy question, and a question with no grounding

Pointing Reply at Alex's "forgot my password" ticket, it followed the rule's procedure, wrote "can answer with high confidence," "root issue," and "sources referenced" in the ticket note, and answered directly with the steps from the public docs.

Ben's question about SSO and Okta wasn't in the knowledge base. Reply decided, "this isn't in the public docs or internal policy, so confidence is low; hand off," and contacted Alert, flagging that an enterprise customer might be locked out. Alert posted to Slack's #alerts, so important tickets show up in real time.

Processing 2 refunds in Stripe

The setup: Carter signed up that same day (September 16) and qualifies for a refund, while Damon is about 20 days in and doesn't qualify. Given both customer IDs and asked to answer, it told Carter about the cancellation and refund, and in Stripe the status changed from active to canceled, with the payment marked refunded.

It declined the refund for Damon without revealing the contents of the internal SOP, and suggested canceling at the end of the period instead. Damon's Stripe status didn't change. Stripe actions can be set up either to require approval or to run freely.

Tune fills in for questions with no knowledge

Elena's question, "can I share the Wi-Fi password with someone else," wasn't in the knowledge base. Reply classified the root issue as "password sharing," decided it couldn't answer since it wasn't in the public docs, and recommended that Tune add it to the knowledge base. When David asked, "say sharing isn't allowed and add it to the FAQ," Tune confirmed before acting, then added it to Notion in green.

The design keeps the final call with a human before 100 people ask the same question. After the addition, when Reply was asked to "try again now that there's enough information," it wrote a reply with high confidence and a link to the new section.

Internal Q&A in Slack

When David, a member of the billing team, asked "what's the refund SOP" in #ask-grok-bot, the bot asked for permission to post to Slack, and David chose "always allow." The response was delayed, so David retried 2 times; after showing an example run ahead of time, an emoji reaction and a reply came through.

What they learned

Set guardrails. Expand from read-only to write access, require manual approval for specific actions, and split permissions per bot (some bots can post to Slack automatically, others can't). By the end of the demo, it had ended up more cautious than intended. Start simple. The product is new and there's no single correct pattern yet, so fit the bot to how you work. Build what's missing.

Q&A: cost, traces, and permissions for non-technical people

Cost comes out of usage on a Grok or Cursor plan. With David's current usage, it runs $1 to $2 for medium-to-complex tickets. Bundling simple billing tickets by script and having it answer them in a batch brought that down to about 20 cents. Other support products charge roughly $1 to $10 per resolved ticket. David said this level came from about half a day of tuning.

For tracking problems, Build has Postgres through Supabase and builds the evals and traces tables. Every time Reply runs, it logs the time taken and the files it looked at and chose, writing even for dry runs. Tune reads that to improve. Phone support hasn't been started; David mentioned there's a video showing Matt giving a phone number to Matt's own Grok Bot.

To keep non-technical people from breaking the production database, the first person to set it up should understand the configuration and narrow permissions with a template. Putting the knowledge base on GitHub instead of Notion lets you use PRs, code owners, and branches, have Bugbot and a human approve the self-improving bot's changes, and run evals against the PR branch.

Q&A: bulk requests, and advice for founder teams

A vague request like "reply to Alex" spends tokens pulling every ticket through Plain's MCP and searching by name. Passing the ticket ID is more efficient.

If the 3 streamers were to set up support themselves, David recommended finding the 20% of use cases that generate 80% of ticket volume, getting the knowledge base and SOPs for those in order first, verifying with evals, and only then putting Grok Bot in front.

Listening to Tone's music in the room

Roshan borrowed the mic set up for Grok Bot to play the candidates that the audio bot, built during the last talk, had put in Notion. The lobby track made with Strudel, a live-coding tool, was too quiet, and the bot had only been taught how to write in Strudel.

Next, they tried tracks generated by having it write Suno prompts, and found one too sad, one whimsical and reminiscent of a wizard's adventure, and others rated "good battle music" and "draft room vibe." Notion had entries by use case, such as "01 draft pick" and "02 lineup lock."

Logging in with X works, but bots can't be added

Lauren logged in with a real X account in the app connected to the backend. The leaderboard was still empty, and a new match could be started, but there wasn't yet a single bot belonging to Lauren, and the process for adding one had a bug. Once it works, pasting a link will be enough to import any bot.

Roshan could also log in with X at the same time, and both accounts were created. Once the leaderboard is fixed, the two of them should sit together at Gold 1000. Roshan said the plan for tomorrow is to launch, give the game a real name, and play with viewers.

More bots, and analyzing the bottlenecks

Lauren's bots grew to include Whisk (game design) and Crumb (a playtesting bot that clicks through the app, though it still can't give an opinion on the game), among others. Near the end of the stream, the advice was to ask Dr. Eggbot, "think about my goals from a high level, review every bot to find bottlenecks, and figure out how to tighten the flow." Dr. Eggbot reads every bot's conversations and analyzes them.

One finding was "a serial factory, with a human-merge gate": merges wait on Lauren, and Lauren ends up blocking the bots. Lauren's plan: stay in the loop during prototyping, but once the project reaches the stage of gathering feedback, raise autopilot's share, become a "feature supervisor," and hand implementation, playtesting, QA, and regression checks to the engine.

Carried over to tomorrow

Matt was moving ahead on the ad side, and the ad marketplace is tomorrow's goal. The ad MVP is unverified, with a database check and a rebase onto Lauren's changes still left.

Roshan looked back on going from no app to an app with an engine and a working bot fleet, along with Cursor's multitasking and design mode, the music, and the guests. Lauren will fix the bug tonight and play a few matches to get a feel for it. They repeated the free Grok Bot offer, and the stream ended on a card reading "tomorrow starts at 8:30."