Grok Bot roles and
development workflowsA technical account of Galaxy Day 1

The purpose of the stream and the three hosts

Matt Palmer works on developer experience and education, Roshan on product, and Lauren on Grok Bot engineering. They begin showing viewers how they build a company from the point of deciding what to make.

Work sessions are interspersed with Grok Bot 101 and workshops on engineering, sales, and go-to-market work. The aim is to let viewers see how other roles use the tool and identify work they could delegate themselves.

• The studio is near Dreamforce in San Francisco.
• The program covers product, sales, and research as well as technical work.

A template challenge for viewers

The hosts announce a Grok Bot Galaxy challenge to share how people use Grok Bot at work. Entrants are asked to quote the official post with a description of their bot and a shared template link. The announced prizes include a Starship launch visit and a SpaceX factory tour.

• The deadline announced on the stream is September 29.
• Entry instructions and conditions are provided in posts from the official Grok and Bot accounts.

Freeing time by delegating tedious work

The hosts give examples such as investigating spreadsheets, finding old messages, preparing documents and designs, and handling manual development tasks. They want to spend less time on these chores and more on work they care about.

Matt regularly creates content, writes code, maintains documentation, and talks to users. He uses Grok Bot as an assistant across those different responsibilities.

• The team will also discuss what they mean by “building a company.”

Turning X bookmarks into working technology demos

Matt describes a workflow in which a bot finds packages and technologies he bookmarked on X, has a Cursor cloud agent build a prototype, and publishes a preview. By the next morning, he receives an introduction and a working demo, making it easier to try technologies that caught his attention.

Roshan notes that the stream lets them work out what to build starting with customer research. He suggests using bots to help with market research, customer interviews, design, and marketing.

• The sequence is bookmark collection, technology selection, code generation, preview deployment, and a morning report.
• Matt describes an existing personal workflow; he does not demonstrate the entire process here.
• People still decide what to prioritize based on customer feedback.

Lauren’s workflow: X replies and development setup

Lauren uses Grok Bot for playful automatic replies to particular prompts on X, as well as daily performance improvements and code changes. She also spends time organizing code and workflows so PMs and designers can make changes without sacrificing quality.

She describes a system where posting a problem in Slack prompts an agent to start fixing it. The team plans to bring bots into the communication and development tools they normally use.

• They use Grok Bot to develop Grok Bot, finding and fixing problems through their own use.
• Their first research task will use the many responses collected on X and internally.

Making something people will use and pay for

The team wants to make something users want, something they would use daily themselves, and something they can charge for. Using it themselves would let them experience and fix its shortcomings.

Whether the buyer is a person or an agent acting for that person, the product ultimately needs to help someone. They consider merchandise, coffee delivery, and local events: businesses where an online action leads to a physical delivery or people meeting in person.

• They have not decided what to sell.
• They mention bots making purchases through Link and consider having both people and bots as customers.
• They also want to make use of the crowds gathered for Dreamforce.

Using Slack and automating development

They discuss starting with Slack for conversation and bug reports, adding issue tracking only when it becomes necessary. An agent might be able to start a fix in the time it takes someone to write a ticket.

Lauren introduces PStack, an open-source collection of her development workflows, and says she shipped many PRs to production the previous month.

They expect to need a database, payments, and infrastructure, and plan to get advice from contacts and relevant companies.

• Slack will be the shared point of contact for people and bots.
• Documents will go in Notion; issue trackers such as Linear may be added as needed.
• The spelling “PStack” is based on the audio.
• The discussion of PRs and pushing directly to main includes joking exchanges.

Adding specialist bots to an empty organization

They have created a Grok Bot team for the stream, accounts with no bots, and a GitHub organization with no repositories. The organization is called ship by Thursday, and the new company will start separately from their existing work.

They suggest making a few simple prototypes to compare ideas. They also consider using the ability to create other bots to give new team members the company’s instructions. They have not decided where company information will live or who will maintain it.

• The plan is to give each new bot a company briefing before assigning work.
• Proposed roles include a founding engineer, an intern, and a researcher.
• Notion is one candidate for storing company information.

Inviting viewer ideas and handing over to Grok Bot 101

The hosts explain that the broadcast will mix planning, workshops, guest conversations, and periods of quiet work. They invite suggestions on X and in the stream chat to help them decide what to build.

Viewers can install Grok Bot and try the same plugins and templates themselves. The stream then moves to Roman and Amrita’s introductory workshop.

• The workshops are part of this free broadcast.
• Schedule times spoken by the hosts are local times. Times on this site are elapsed time from the start of the video.

Keep using a bot as the owner of a job

Roman describes a progression from answering questions in chat, to copilots helping with tasks, to bots owning work, to teams of bots covering a function. Grok Bot is designed around repeatedly returning to a specialist, such as a sales or email bot.

The slide labels the stages Ask (Chatbots), Do a task (Copilots), Delegate outcome (Bot), and Staff function (Team of Bots).

• The idea is that a recurring specialist learns your preferences and remembers previous work.

Memory, a computer, and cloud execution

Roman identifies three characteristics: a bot learns preferences through repeated work, uses its computer for jobs that APIs or MCPs cannot finish alone, and continues working in the cloud when the user closes their PC.

He wants to extend the way developers direct agents to write software into other kinds of work. He recommends starting with simple requests and gradually trying harder ones to find the current limits.

• The conversation interface is intended to feel like messaging a colleague.
• Computer-use examples include older business software, video, and audio.
• Several people working with the same AI colleague is presented as a future area of development.
• The slide lists roles, messages, memory, signing in to tools, routines, and sharing.

Create DataDan and dictate a Google Forms request

Amrita creates DataDan. The bot suggests possible uses based on its name, but she gives it a specific spoken request: make a Google form asking how many cups of coffee someone drinks each day and which San Francisco coffee shop they like.

The plan is for DataDan to collect responses, Slide Sonya to make charts and slides, and Email Ethan to write to stakeholders. Amrita says Google Forms was chosen to show an annoying manual task that requires computer interaction.

A use-case slide lists account health and outbound sales for GTM, performance investigation and bug reproduction for engineering, talent scouting and paid media for marketing, and a chief of staff and expense management for administration.

• Slide Sonya and Email Ethan were created before the demo.
• The demonstrated voice feature transcribes speech. Two-way voice is described as available internally and planned for release.
• Amrita says the approach also applies to form-based work in tools such as Qualtrics.

Open the Linux VM and demonstrate a task

Amrita opens the bot’s computer from the top-right corner to show it working with Google services. She also opens the plugins and MCP list, explaining how direct integrations and computer interaction can be used together.

Using Slide Sonya’s Teach a task feature, Amrita demonstrates adding an animation on the bot’s computer. She selects an object, chooses an animation, tests it, and stops recording. The steps are saved as a skill.

• Amrita is performing these actions herself.
• The saved skill can later be used to add the same animation to other text or images.
• Approval requests also appear while working with the computer and connected services.

Specify approvals, slide styling, and routines

Amrita explains that rules can be written in natural language, such as asking before sending email while allowing slide creation without confirmation.

Slide Sonya has instructions for fonts, colors, editing an existing deck, and returning a screenshot when finished. Routine examples include reporting changes and their authors every day at 9 a.m., or working with Email Ethan to send a weekly report to a manager.

In this workshop, the bots’ computers are described as separate, allowing different actions to run in parallel. For a shared deck, the example assigns different slides to the person and the bot.

• They divide up the slides to avoid conflicting edits to the shared document.
• Instructions specify what to show on completion as well as colors and fonts.
• These are examples of routine setup; their later execution is not verified in this broadcast.

Email Ethan asks the other specialists

An email bot can learn a user’s writing style by reading previous emails. When asked to write about the coffee survey, Email Ethan contacts DataDan. Amrita then asks it to get the details of the 101 presentation from Slide Sonya and opens the exchange on screen.

Bots can be organized by role or by project. Amrita also describes creating a Chief of Staff that passes work to other specialists.

DataDan replies that the new data is not ready, so Email Ethan says it will use existing sample data.

• The user can inspect what a bot asked another bot and the reply it received.
• The data being used here is sample data, not new responses from the audience.

Email drafts, duplication, and sharing

The form takes time to create. Amrita says computer-use speed depends on the model and ongoing improvements. For email, she shows an approval prompt triggered by the sending rule and a draft where the recipient and text can be edited.

She describes duplicating an email bot and tailoring its tone for executives, everyday users, or coworkers. Sharing templates internally or through the public marketplace can also help a team keep fonts and colors consistent.

At around minute 63, she confirms that the form is ready and requests a QR code. Audience responses have yet to be collected.

• Email drafts can be edited or deleted in the app, or sent back for a rewrite.
• A received template can be adapted to the user’s own needs.
• The later Q&A explains how duplication affects memory.

The QR code is ready, but the form will not open

Putting the three bots in a group chat makes their exchanges visible in one place. Amrita recommends using questions and stalled work as opportunities to explain the expected behavior and correct it.

When participants scan the QR code, they report that they cannot access the form. Amrita asks DataDan to check whether the link is public.

• Generating a QR code did not establish that its recipients could open the form.
• A correction should explain what happened and how it should work.
• Amrita says acknowledging a successful fix or check also helps with later work.

Wait for the slides before writing the email

Because the form still has a sharing problem, Amrita asks the group to make a chart from existing coffee test data and add it to the final slide. When told to write the email afterward, Email Ethan replies that it will wait for the deck and screenshot.

She then creates Manager to collect updates from the three bots. She describes checking for blockers every two hours and alerting other specialists when, for example, DataDan is stuck on publishing the form.

• The order is data, slides, then email.
• Manager’s two-hour check is presented as a setup example.
• This section does not confirm completion of analysis of new responses or an external send.

Q&A: repeated approvals and groups with people

Amrita says approval decisions combine Auto Review’s risk assessment with user-defined rules. She says the form is asking for confirmation more often than usual. An audience member asks how to delegate work without having it stop for approval at every step.

She answers that users can teach the bot what it may do, including telling it that future confirmation is unnecessary for a particular action. She also describes multiple people adding instructions to a bot in the same Slack thread.

• The explanation is that explicit permissions and preferences inform future decisions.
• Groups containing both people and bots within the Grok Bot app are still under development.

Q&A: internal tools, recorded skills, and 1Password

Amrita says bots can use internal tools when credentials and the necessary access are provided, citing MongoDB and 1Password. Connections to individual enterprise networks are not tested here.

She explains that Teach a task reads the target and steps from a recording and saves a skill. She opens the animation skill to show the recorded instructions that can be used later.

1Password presents an authentication form within the app. According to Amrita, the credentials entered there are securely stored and used to sign in to the required services.

• Both team-only templates and a public marketplace are available.
• PDFs, PowerPoint files, and other artifacts created by a bot can be saved to the user’s PC.
• She explains that the cloud VM allows the bot to continue working after the user closes their laptop.

Q&A: editing memory, duplicating bots, and getting started

Amrita says memory persists, and users can describe what to forget or change. For example, when a specialist bot is deleted, its manager may need to be told not to delegate to it anymore. She says duplication retains the role and settings but starts fresh with respect to memory acquired through conversation.

She recommends starting with one annoying daily task. Examples include forms, outbound email, cleaning up stale feature flags, and customer support.

• A bot does not necessarily discover outside changes, such as another bot being deleted, on its own.
• The final slide reviews using tools without MCPs, memory and learning from video, and human approval.
• It repeats the example that Email Ethan needs approval before sending externally.
• There is no final confirmation that new audience responses were analyzed and emailed.

Peter Yang joins and reviews the setup

Peter Yang, a former PM who runs Behind the Craft and other work, joins the studio. He says he uses Grok Bot to run his solo business. The team has set up Slack and Notion, but its GitHub organization still has no repositories.

When they suggest putting plans and onboarding instructions in Notion, Lauren points out that fast-changing plans can quickly make documents stale. She wants to keep the necessary explanation while also making prototypes promptly.

• They start in a fresh bot environment with the X plugin connected.
• Screen-sharing problems require some setup repairs during the explanation.
• They decide to begin by creating a market research bot to look for customer input.

Create a research bot and identify the customer’s problem

They use a viewer’s suggested name for a market research bot and ask it to summarize replies to the hosts’ recent X posts. Peter recommends asking who the customer is, what problem they have, and what the business can offer them.

They want to show interesting technology, but acknowledge that building a company also means mundane work such as creating accounts. They agree to make something whose purpose is clear even to people unfamiliar with AI development.

• The provisional company name is ship by Thursday.
• They are still treating the broad audience as potential customers and have not narrowed down a specific group.

X replies suggest local businesses and consumer services

The research bot groups proposals into local businesses, services for nontechnical people, enjoyable consumer experiences, and tools that help others build businesses. Suggestions include painting, small shops, book promotion, landscaping, trading cards, and dinner delivery.

The hosts explain that they can request progress reports every few minutes and send questions or changes while a bot is working. A hardware idea resembling a cooking pot shaped like Grok Bot also comes up.

• These are replies from X, not a statistical survey of the wider market.
• They say they will not build a meme coin.
• They are still generating a broad set of options and have not chosen a product.

From favorite games to discussing working prototypes

A conversation about favorite games leads to the observation that assigning work to bots feels like a strategy game. They discuss the origin of Lauren’s X handle, Final Fantasy XIV, Age of Empires, StarCraft, and console games.

Returning to work, they note that ideas can now quickly become prototypes people can try. Lauren says she routinely asks herself whether something could be fixed or tested that very day.

• The point is to make something usable early enough to discuss it, while still using specifications where useful.

Explore restaurant tasks and the pop-up idea

Roshan says cheaper code does not remove the need to understand what users struggle with. He asks the bot to consider concrete jobs, such as checking reservations and menu changes in the morning or helping an owner respond to reviews.

They distinguish supporting an existing restaurant from helping someone test a new one through a short pop-up, since the needs differ. They also show how a heart reaction to a bot’s reply can inform its next suggestions.

• Other candidates include household tasks, hiring service providers, and volunteer coordination.
• Food-related options include pop-up support, working with a local restaurant, experiential dinners, and ticketed events.
• They dictate thoughts before they are fully formed, then use the replies to narrow them down.

Split up food-provider research and prototyping

The team considers partnering with a local restaurant or chef for a short event and building the software to run it. Event management, registration, payments, time slots, and table reservations are potential features, but the format is still undecided.

They decide to divide prototyping and prospect research. Finding cooks, attendees, and a venue requires contacting real people, so they also create bots to prepare for that work.

• Lauren will prototype, while Matt works on prospects and documenting the plan.
• They later revisit whether to offer reserved seating or counter service.
• Dr. Eggbot is introduced as a public template for creating and adjusting other bots.

Install Dr. Eggbot and request a simple landing page

Ideas such as painting and piano tuning remain in the discussion, but the difficulty of testing them in three days leads the team to proceed with pop-up support for now. Lauren dictates instructions to Steve to work with Dr. Eggbot on a small engineering team and a prototype.

They discuss testing without a full database, perhaps using Google Sheets. A landing page could show whether people sign up. Matt creates a role to find chefs and restaurants, considering X, viewer referrals, phone calls, email, and an application page as possible channels.

• The first test is a simple page to see whether people respond to the business concept.
• The priority is finding restaurants or food providers before recruiting attendees.
• Dr. Eggbot is installed from the public marketplace.

Make Steve the manager and add a prototyping specialist

Lauren asks Dr. Eggbot to turn Steve into her Chief of Staff and executive assistant. She plans to talk mainly to Steve, which will pass work to specialists. The prototyping bot is asked for several simple HTML/CSS options.

They create an empty GitHub repository called pop-up and decide to keep it private for now in case unintended information is added during the stream. They explain that bot names, roles, and delegation targets can also be changed through chat.

• The prototyping bot is named Grok Pot from a viewer suggestion.
• They will need a company name, domain, and email account to contact restaurants.
• Matt also uses AI to organize his thoughts and work out priorities.

Find design references and agree to host a pop-up themselves

Lauren asks for landing-page references and compares several options. The team agrees to run its own pop-up and use the experience to identify which software features are needed.

They distinguish a page selling the software to organizers from one inviting people to an event. Although the food and venue are undecided, they can already start contacting restaurants and chefs.

After a long spoken prompt, Lauren asks the bot to restate what it understood in its own words. This lets her check that the goal and assumptions came through correctly.

• French fries are a suggestion in the conversation, not a confirmed product.
• A summary helps expose contradictions when a prompt includes several people talking.
• They collect design references before requesting generated designs.

Secure a venue and providers before making more pages

Steve replies that the venue, operators, and cooks need to be secured first. The team reconsiders its approach: work through organizing an actual event and discover the necessary software along the way.

A seated dining experience and a counter-service pop-up require different booking systems and amounts of preparation. They keep a simpler format under consideration. Three screen prototypes are ready, but they are only rendered as HTML/CSS inside Grok Bot and are not yet deployed.

• The event format determines whether time slots and table reservations are necessary.
• Writing code alone will not secure the venue or chefs.

Peter’s advice: test payment and automate regular updates

Peter says solo founders should design a business that lets them do more of the work they enjoy. He recommends getting an idea in front of real customers early and checking whether they will pay, rather than continuing internal debate.

The stream’s viewers are not necessarily restaurant owners, so the intended audience for a landing page matters. He also suggests that as software becomes easier to build, difficult work such as finding a venue and chefs may be what people pay for.

In his own setup, bots monitor registration metrics and research prospects, then send numbered reports on Fridays. He replies to individual items and the bots continue working. Before leaving, he requests the ability for people to join the same bot conversations.

• Positive comments alone do not establish willingness to buy.
• Have bots send useful reports on a schedule to reduce the need to check in manually.
• Numbered updates make it clear which item each reply addresses.

Grok Pot prototypes; Tater implements

They tell Steve that the first design is too bland and ask Grok Pot for alternatives. They also create Tater to think about the stack and substantial implementation work. Grok Pot keeps the role of quickly making options they can compare and discard.

The hosts explain the distinction between a model and the environment that runs it and enables it to do work. They plan to create simple HTML in Grok Bot and delegate more substantial code changes to Cursor’s development environment.

• Screen prototypes and production-oriented implementation require different levels of completeness.

Choose technical candidates and write down the purpose

They ask Tater to consider the stack, with Vercel and PlanetScale as leading candidates. They decide to keep moving rather than spending too long debating the details.

Matt writes the current goal in Notion: run a food pop-up in San Francisco and use that experience to build operating software. A brief record of the agreement will help explain it repeatedly to guests and bots.

• They provisionally assign engineering and product responsibilities, with some joking about titles.
• The document is expected to change as the discussion develops.
• They want to provide concise, correct assumptions rather than large amounts of misleading information.

Choose the pink design and put it in the repository

After comparing options, they choose pink for now. They can revisit the final design later; the immediate goal is to put the page in GitHub and deploy it.

They share the repository in Slack and ask Grok Bot to build and push the landing page. A marketing bot is proposed to help with the domain and brand name.

• A shared repository will let multiple people and bots contribute changes.
• Work continues alongside informal conversation, including making signs for their job titles.

Set up Vercel invitations and the GitHub connection

A bot proposes domains, but the name remains undecided. While sharing the Notion company description with other bots, they work on Vercel organization invitations, the GitHub connection, and account creation.

The initial output is a simple index.html with styles in the same file. They switch away from screen sharing while people check invitations in email.

• Accounts and deployment permissions must be prepared alongside the code.
• They plan to add an operations bot and a Creative Director to divide setup and naming work.
• Screen sharing continues to suffer intermittent problems.

The first deployment works, but signups are not saved

The first Vercel deployment succeeds. The page renders, but the destination for signup form data is not implemented. Google Sheets and a Notion database are the first suggestions.

After requesting Notion storage, they change to PlanetScale Postgres to avoid replacing the temporary solution later. Payments are deferred as they narrow the immediate feature set.

• Only page display has been confirmed at this point; signup storage has not been tested.
• The Notion plan is replaced by preparations to connect PlanetScale.

Work on the design while waiting for database access

They recap three parallel tracks: company planning and prospect research, the HTML page, and the database connection. A scheduled guest is unable to join, so they use that time to keep building.

While database credentials are pending, they ask for table design and dependency setup to continue. Tater is told to use Cursor Cloud Agents for future implementation.

• Grok Bot organizes requests and progress, while coding agents handle code changes.

Develop with Cloud Agents and return evidence of the result

The hosts explain that Cursor Cloud Agents have VMs and can start and operate applications, inspect CPU traces, and perform other checks. They can also prepare the environment needed to run an existing repository.

They try creating a Project to retain the history of longer development work and receive follow-up implementation requests. They have not decided whether to keep that setup. Until database credentials arrive, the agents are told to work in the cloud and return a video or screenshot.

• Not every described capability, such as CPU tracing, is demonstrated in this section.
• They continue testing while deployment is pending and ask to see the result.

Buy a company domain and consider a reviewer

The team reports buying a company domain. They consider separate sites for the company and product. Matt has Dr. Eggbot install development skills and integrations as he prepares a company landing page.

After seeing a newly opened PR, Lauren says that for this short experiment they should push directly to main for now. She then notices a large diff and starts considering a reviewer bot separate from the implementer. The stream pauses to address production equipment issues.

• Pushing directly to main is a decision made here to move quickly.
• A diff of roughly 2,000 lines is mentioned, but completion of its review is not reported.

A dashboard for acquisition and sales

The guest, who works in buying, selling, and growing businesses, shows a dashboard being used for a book launch. She says the Vercel-hosted dashboard tracks attendees, paid versus organic traffic, and acquisition cost and order value by channel.

She also introduces another dashboard called Pulse, but part of the audio just after the connection is missing, so its detailed features cannot be confirmed.

• The presentation shows 135,355 registrants.
• This is a demonstration of something already in use, not a new build during the session.

Separate event preparation from willingness to buy

The team says it wants to run a food pop-up and offer the operating software to others. The guest distinguishes arranging a venue and the required procedures from having people actually attend and fill the seats.

The team is considering operations first and still needs to consult on legal matters. The guest recommends trying to sell to three people before committing to the business and thinking about how to reach customers.

• Permits and legal requirements have not been resolved at this point.

Use posts on X to get noticed

The guest points out that the stream’s large audience gives the team a distribution advantage. She considers how to attract customers without that advantage and shows examples of X posts that sparked debate and AI-generated video.

• She goes on to discuss how those responses affected applications and registrations.

Turn responses to posts into applications and signups

The guest shares AI-generated video and posts that express a clear opinion. She says they drew criticism as well as other responses, but also produced job applications and book registrations. She recommends deciding what viewers should do before publishing.

• Look beyond views to whether people apply or register.

Test organic posts before adding ads

At first, neither the customer profile nor the message that will resonate is clear. The guest proposes testing organic posts, learning who responds to which language, and then adding advertising.

She also suggests showing successful posts to a bot, explaining the desired outcome, and asking it to learn how those posts structure their message.

• The reference is the structure of the post, rather than copying its wording.

Review results and improve instructions after delegating

The guest disagrees with the idea that hiring great people means simply leaving them alone. Both people and bots need clear expectations, followed by repeated review and correction. In marketing, she suggests judging the work by sales and results delivered for customers.

• She mentions AOV and LTV as evaluation metrics, but does not demonstrate calculating specific values here.

Customer distribution and a record of results

The guest argues that reaching customers becomes more important as making products gets easier. She emphasizes recurring cash flow and customer acquisition, with building in public as one way to attract attention.

She proposes a Proof vault containing positive customer comments, video views, screenshots, and growth records. Items should be distinguished by whether they have been checked and whether they can be shared publicly.

• The proposal is to use those records when explaining the product or business.

Choose a business goal before creating the bot

When the conversation turns to making a marketing bot, the guest asks for the goal before its name. Because the team has no reservation or payment system yet, they decide to collect prospects’ email addresses first and then test purchase intent.

• A bot named Lead Capture is visible at around 3:09.
• This does not confirm completion of signup collection, reservations, or payments.

Research successful examples and revise the idea

The guest uses “Imitate → Iterate → Innovate” to describe learning from existing examples, making revisions, and developing an original approach. Suggested research includes leading San Francisco restaurant operators, well-designed websites and pop-up pages, and successful examples from other cities in the past 6–12 months.

The host asks a bot that creates other bots to make an Operator Research Bot. He also supplies the company description in Notion so the research focuses on this business.

• Cities, quantities, and time periods are specified in the research request; the research is not yet complete.

Give customers a reason to attend

The guest suggests using early restaurant-brand examples to craft a short headline and a reason to attend. She considers exclusivity, scarcity, timing, and relevance to the customer.

She recommends focusing on what customers receive rather than the company’s desire to display a large logo. In her experience, ads showing natural conversation or a real business setting have performed better than polished corporate advertising.

• The advertising results are presented as the guest’s own experience.

Show small businesses how AI will increase revenue

For selling AI to traditional small businesses, the guest recommends starting with how the shop or company can earn more money. In her view, it is harder to communicate the need for AI when its near-term effect on sales is unclear.

• A figure that appears to concern profit margins is not included because the audio is uncertain.

Offer something useful in exchange for an email signup

The guest proposes a lead magnet: useful information, an assessment, or research offered in return for an email signup. The idea is to test several offers related to the business and continue providing useful material after registration.

• For her own assessment service, she says she combined Claude, Vercel, and Replit.

Turn the conversation into a marketing plan

The host says he wants to give the transcript to a bot and have it produce a marketing plan. The guest closes by recommending that the team plan how to attract customers and sell, as well as how to build a good product. A break begins at about 3:19:30.

Build both the pop-up and its operating software

The team reviews the morning’s research, viewer suggestions, and guest conversation. The idea is to bring restaurants and attendees together for a food pop-up in San Francisco, then turn the experience into operating software others can use. The details of the event are still undecided.

Tater implements and Hashbrown reviews

Lauren describes having Hashbrown review Tater’s PRs. She is preparing a system in which plugins live in the repository for the whole team to use, and PRs posted in Slack are reviewed automatically.

Since the business is still small, she wants to start with the necessary steps and leave room to extend them later.

• The transcript renders the plugin name as “P stack”; its official spelling is unconfirmed.
• The scope of automatic merging has not yet been decided.

Divide page-building work and move to the engineering workshop

Another host will handle the landing page and its visual design. They describe using Grok Bot to develop ideas and Cursor Cloud Agents to implement them, then hand over to the engineering workshop.

Lingxi Li's development process

Software engineer Lingxi Li said he had been using Grok Bot in his own development work for about two months. He described building the mobile version in a short period and introduced his usual process.

Completion, coding, automatic triggers, and supervision

The slides outlined Autocomplete, Ask & Edit, Agentic Coding, Automations, and Autonomous Coding. Even when Cloud Agents can work in parallel and start from events, people still have to supervise multiple agents.

Lingxi assigns that supervision to Grok Bot: checking progress, issuing follow-ups, changing direction, and interrupting work when necessary.

Use dedicated tools to start and supervise Cloud Agents

According to Lingxi, Grok Bot can use dedicated tools to start Cursor Cloud Agents and read their history and progress. Starting a task does not require navigating the UI each time.

If a completion report lacks screenshots or before-and-after performance comparisons, the bot asks the Cloud Agent to supply them. He also mentioned private workers and execution on Macs.

• The overview slide listed four areas: Fully Autonomous AI Agents, Connect to tools you use, Manage Cursor Cloud Agents, and Memory & Routines.

Use connected tools and carry instructions into later tasks

Examples included investigating failed Vercel builds and deploying at a specified time. He said bots remember previous feedback and preferences and apply them to later requests.

One reason to separate bots by role is to limit the information each needs. Avoid loading a single bot with too many unrelated jobs.

• This section introduced capabilities; it did not show the result of an actual deployment.

Keep work running with the laptop closed, and intervene for authentication

Lingxi explained that processing runs on the bot’s computer, so the user does not need to keep a laptop awake. He said the product is available across multiple operating systems and mobile devices.

When login or authentication requires a person, the user can access the bot’s computer remotely. He emphasized making it possible for people to unblock work.

Reviews and bug handling while the user is away

He described monitoring Slack requests and mentions, then reviewing work against predefined criteria. Screenshots and meaningful tests are required; a person can review from a phone when human approval is needed.

For a bug report, the bot checks whether the issue still reproduces on main and opens a fix PR if it does. Bots also communicate to arrange security checks and contact the appropriate reviewer.

• He also mentioned bug reports on X, but the collection process was described alongside Slack integration. The exact routing is unclear.

People still decide product direction and difficult designs

People continue to handle product direction, detailed design, difficult performance problems, and the next architecture. Bots may accept too many requests, so they also need to be told what not to implement and why.

People also unblock tasks held up by authentication. Define what to delegate and which decisions require a person.

Audit and clean up code overnight

Lingxi said his normal audit starts at 3 a.m. Overnight, when changes are less likely to conflict, the bots inspect code quality, insufficient modularization, lengthy comments, and security issues, then prepare PRs.

Automatic merging still requires predefined conditions and evidence that the complete behavior has been checked.

• Later in the demo, he described the template’s normal start time as 4 a.m. That differs from his own routine.

Add TestFlight users through a Slack mention

He used the internal task of adding TestFlight users by email address as an example. A user mentions the bot in Slack and supplies the address to request registration.

This can reduce the need to build a dedicated dashboard, database, and authentication screen. The bot must be given the necessary TestFlight access.

• He described his usual operation rather than demonstrating it live.

Respond to CI and deployment failures

He described a bot that detects failed CI, deployments, or integration tests and starts a Cloud Agent to investigate. After a fix, it merges under the agreed conditions, or alerts the on-call person if the issue remains unresolved for a set period.

• He used ten minutes as an example of the threshold for notifying the on-call person.

Separate roles to keep memory and procedures focused

The team includes a Chief of Staff, Craig for UI, Steve for DevX, Hogan for infrastructure, and an operations role. Even with the same underlying model, each role needs different information and procedures. Separate memories help avoid exhausting a bot’s context.

The person mainly talks to the Chief of Staff, which routes work to specialist engineering bots. This also reduces the implementation detail the Chief of Staff must remember.

Demo 1: an existing bot teaches the new audit bot

Lingxi added Nightly Audit Engineer from the Marketplace and had an existing engineering bot explain how to work. The bots discussed the Notion board, the definition of done, and the stages of the process.

He started an audit immediately rather than waiting for its scheduled time, then moved to a separate bug investigation while it ran.

• He named the new audit bot Steve and the existing bot Craig.

Demo 2: investigate missing access to booked flights

He investigated a report that users could not view previously booked flights on FlyLo. The bot used the browser and reported around 4:26 that /trips, which the navigation linked to, was an unimplemented stub.

Computer use can handle tasks that MCP does not cover. Lingxi cautioned that simply saying “hurry” might make a bot skip steps and guess.

• The fix was not confirmed complete in this section. The automatic transcript also varies in its spelling of the site name.

Demo 3: Ops Bot maintains the shared playbook

He added an operations bot to maintain the Notion playbook. Other engineering bots would not edit it directly; Ops Bot would communicate changes to the team.

Demo 4: check P0 progress every five minutes

For urgent P0 work, he instructed the bot to check the Cloud Agent’s progress every five minutes. It should look for drift from the goal or unnecessarily long waits, and send new instructions when needed.

Craig passed this rule to Ops Bot, which added it to the playbook and notified the other engineering bots.

• He gave sleep 300 as an example of a long wait. The supervision was meant to remove wasted waiting around test completion, not to skip tests.

Demo 5: attach screenshots and performance measurements to PRs

He added a rule requiring screenshots for UI changes and measurements for performance improvements. This lets reviewers assess the result without repeatedly asking for missing evidence.

The nightly-audit bot returned a code-cleanup PR, while another task was still running.

• Some PRs were ready, but not all had been merged.

Use a task ledger to manage parallel work

Repeated interruptions can leave a bot juggling too much work to retain the context. Lingxi records tasks and their stages in the Notion task database included with the Marketplace engineering bot, and has it consult that database when deciding what to do next.

Reviews also use Bugbot and security checks. A Cloud Agent started before the talk had returned screenshots that could be used for review.

• The task ledger avoids requiring the bot to keep the state of every task in its context at all times.

Closing advice: reuse taught procedures and verify results

Explain goals and expected quality as you would to a capable intern who does not yet know the organization. If instructions keep recurring, put them in a playbook or have the bots make the necessary handoffs.

Deciding whether to continue work or merge a PR requires a way to distinguish success from failure. Use verification suited to the task, such as exercising a website or reading measurement signals from hardware.

Trigger PR reviews from Slack posts

Posting a PR link to a review channel triggers Cursor Automations to check correctness, risks, and missing tests. The team says it is currently a simple prompt that will need refinement.

They also prepare a bug-report channel. Eventually they want to collect feedback from places such as X, investigate it, and generate fix PRs. The app is still small and the process is only beginning to take shape.

• Screen sharing sometimes failed to switch or froze, so part of the explanation was verbal.

Review the business goal and each bot’s role

The team wants to bring together attendees and operators for a San Francisco pop-up, then turn the software used to prepare it into a product. Earning revenue by day three is also a goal, but its feasibility remains uncertain.

They connect the GitHub organization and repositories and work on the landing-page design. Following the interview advice, Operator Research Bot investigates similar businesses and restaurants, while Dr. Eggbot creates other bots.

• A person had to handle GitHub authentication and repository permissions.

Give bots tools to verify the app themselves

If every launch-and-click check is left to a person, the work stops until that person is available. The team therefore plans a verification skill that lets a bot launch the app, collect traces and snapshots, and investigate bugs itself.

The skill will include a shared CLI or script for reliable app interaction, plus a feature map documenting how to reach features and use shortcuts. Reusing the same tools can reduce the tokens spent writing separate scripts and make verification more reproducible.

• They asked a Cloud Agent to run create verification skill, but it had not finished at this point.
• The automatic transcript varies between PStack, Peace stack, and other spellings, so the plugin’s exact name is uncertain.

Prototype the landing page and attendee signup form

They simplify the landing page and make email signup the main entry point for prospective attendees. A separate route would collect contact details from restaurants and other collaborators. The form is said to be connected to the database, but they are reconsidering what information to collect.

They discuss checking registrations in PlanetScale and preparing email delivery through services such as Resend. They ask viewers not to submit the current form yet because it is a disposable prototype.

• At 4:52:28, they mention the domain being live. UI, form, and authentication changes continue afterward.

The feature list keeps expanding

They list event names, dates, venues, staff, invitations, attendee management, and permissions for owners, hosts, and attendees. Adding maps and venue research makes the scope broad enough that individual pieces could become products in their own right.

They decide to prepare their own event and build tools for the tasks that prove difficult. Lauren says she takes the same approach to writing skills: do the work manually first, then automate it.

• The minimum feature set and the reservation-slot model are still undecided.

Find contact details for restaurants and collaborators

The team considers having bots research restaurants, caterers, and venues so people can contact them. They mention a previous voice-agent integration, but no automated phone call is completed here.

They tentatively choose October 15 as a reference date for outreach and record it in Notion. They begin researching San Francisco and Bay Area candidates, but later reconsider the timing because of permits.

• Domain, DNS, and email setup proceed in parallel.
• They cannot access a GitHub repository and consider whether the connection or CLI can resolve it.

Prototype a tool for finding and contacting venues

Lauren requests an internal tool to view venues on a map and search by location or cuisine. It might also identify the right person at a restaurant and make contacting them easier. The initial priority is usefulness for actual venue research and phone calls.

After sending a long voice prompt, she asks the bot to restate the request before executing it. Google Maps and OpenStreetMap are discussed, along with how to obtain the keys needed for implementation.

• A venue directory and a record of post-event ratings are also suggested, but have not been implemented.

Restrict the internal prototype to the team

They want only the team to access the venue-finding dashboard. After discussing GitHub and Google login, Clerk, and WorkOS, they choose Vercel deployment protection for the initial prototype.

Creating API keys and configuring connections still require manual work. They note how much of this setup is happening behind the scenes.

Create a bot to collect important information in Notion

A verification PR is ready and a person begins reading it. In parallel, the team creates a Knowledge Base Manager to gather important information from the other bots’ work in Notion.

The initial instruction is to act only when asked and to seek approval before adding information. Later, they notice that important points from the conversation are missing and propose checking with active bots every five minutes, recording only what matters.

• They want to limit what gets recorded so that minor details do not make Notion hard to read.

When should code-quality constraints be added?

They debate whether to add strict constraints such as lint rules immediately or wait while the business idea may still change. Lauren explains that code structure and stack constraints influence what agents write, functioning much like memory.

Rust and Go are discussed, but she eventually says she will stay with TypeScript. The idea is to add constraints and cleanup while confirming what they actually need to build.

• At 5:30:00, they discover that the prototype is plain HTML and JavaScript. This is not a completed stack migration.

What would make someone want to attend?

While writing a flyer headline, they reconsider what they are selling and why people would attend. Ideas include a new experience, exclusivity, merchandise, in-person games and conversation, and good food.

They ask bots for busy locations, flyers, and a marketing plan, but are not happy with the first designs. One suggestion is to use the site’s code as a reference so the flyers follow the same design.

• No results from advertising, merchandise sales, or audience acquisition have been confirmed.

A missing PR video prompts a new attachment rule

They ask for a video of the venue-finding tool, but it is not in the PR. To make the behavior reviewable, they add a rule to apply the verification skill consistently and attach screenshots or video to UI changes.

They also require verification for backend changes.

• Cloud Agents being able to create video does not mean a video was included in this PR. They had to request it explicitly.

Connections and authentication take time

Resend domain verification progresses, but GitHub CLI authentication and connection problems continue. They decide to get the landing page and venue-finding tool running first and improve them afterward.

• At 5:26:22–5:26:24, a speaker says that switching between tasks has made it hard to remember which API key is being configured.

Use capacity, costs, and permits to define venue requirements

They tentatively plan for about 100 people and look for a space where they can control the setting and experience. They name good venues they know and ask the bot to find similar places.

Research into costs, food and alcohol, administrative procedures, and application lead times raises doubts about holding it in a month. They also consider vendors or venues that already have the necessary permits.

• Permit research is still in progress; legal requirements have not been established.
• The date, capacity, and venue are all tentative.

An art exhibition becomes another option

While discussing menus, the team again recognizes the complexity of arranging chefs, staff, a venue, and permits. They propose collecting artworks for an exhibition people could enjoy both in person and online.

After about 5:40, they tell the bots about a possible switch to an art pop-up and prioritize a large warehouse-like space. Payment arrangements and operations are still being discussed.

• They have not yet produced the artworks or held an event.
• Around 5:42, a host leaves to speak in the PM session.

What should the venue-finding tool add?

They consider using existing map search and adding criteria it does not handle well, such as venue capacity. Information gathered by phone could be stored like CRM data and used in later searches.

They plan to compare the tool’s results with the candidates found manually to see whether it actually helps with venue research.

• Storing information from phone calls is still only a proposal.

Prototype PRs accumulate faster than they can be reviewed

Multiple prototype requests produce several PRs in parallel, adding to the review queue. Implementation and review bots are working, but some PRs lack screenshots or videos, leaving it unclear what has been built. They ask Steve to bring the work to a reviewable state.

Work also continues on sending confirmation emails after signup and storing registrations in the database. It has not yet been confirmed ready for users.

• Some spoken PR numbers are unclear, so completion cannot be assigned reliably to individual PRs.

Announce the template challenge and switch to the PM talk

They announce the Grok Bot template challenge and the Starbase visit for the selected winner. They check PR status while preparing to switch to the product-management talk.

• Challenge conditions and prizes reflect the announcement made on the day of the broadcast.

Decide who the product is for and what to build first

Kevin Niparko and his colleague describe their product team’s experience building Grok Bot with Grok Bot. Citing DHH, they argue that everyone building a product must consider what to make, who it is for, how it should work and look, and what to prioritize.

A colleague that can work in Slack and business tools

They say the chat box became limiting as they began delegating work beyond coding. They wanted something like a colleague they could message in Slack who could also read tickets and Notion. This internal demand was the starting point for Grok Bot’s design.

Four properties drawn from how colleagues work

They name working across multiple tools, learning the background of a job over time, and making progress independently with the necessary permissions and environment. They describe giving bots long-term memory and a computer so they can work in similar ways.

The fourth property is being able to send instructions and additional information while work is underway. As with messaging a colleague, users can steer an active task.

Support priorities, research, and product delivery

Users can interrupt with new instructions while waiting for a response or move to another thread. The presenters describe the goal as a colleague that learns the organization, works independently, and returns results.

They introduce three PM uses: comparing how time is spent against priorities, researching customers and usage, and delivering product changes. They say Grok Bot is involved in a double-digit percentage of internally merged PRs.

• The Attention list reviews where time has gone and whether it aligns with the work that should take priority.

Assign data, product, design, and engineering roles

Cora is the Chief of Staff, learning about the PM’s work from email, calendars, and Slack. Emily manages five engineering bots, splitting large requests and coordinating work through verification. Ashley handles SQL, data exploration, charts, and analysis, while PM Pete organizes customer feedback and specifications.

Pixel handles design and Rae handles recruiting. Specialization limits what each needs to remember and makes it clearer to people whom to ask. Users can assign work to several bots at once or let bots consult each other when their responsibilities overlap.

• The whole team is introduced, but not every role is demonstrated.

Analyze Flylo Airlines purchase data

The presenters show a demo environment connected to Notion, Slack, Figma, Gmail, and other tools. Conversations are grouped by purpose, including an engineering group, an Engineering/Product/Design group, and an incident-response group.

Asked to compare the previous day’s web and mobile purchases, Ashley queries the connected data source and returns the result. The demo reports about 1,400 tickets, roughly 58% on web and 42% on mobile. The presenters then request charts of categories such as family travel.

• Flylo and the figures are demo data, not the results of a real airline.
• Databricks and Snowflake are examples of possible connections; the source used by this demo is not identified.

Schedule reports and correct a misread chart

They describe replacing a daily tour of dashboards with summaries pushed by a bot. A product launch might call for more frequent checks. In the demo, they create a chart of family travelers and request an update every morning at 6 a.m.

Looking at the mobile-purchase chart, the people assume the major drop-off occurs at seat selection. Ashley corrects them: the problem is between search and fare selection. They resolve the misreading before proceeding to improvements.

• Report frequency depends on the use case. The later Founders talk also discusses the cost of running routines too often.

Request designs and a prototype in parallel

Ashley passes the findings to PM Pete, who writes P0/P1/P2 requirements in Notion. The aim is a specification that makes priorities clear enough to start prototyping.

They explain that proposed improvements to fare comparison and presentation need human input and comments in Notion. For the demo, they move quickly and ask Emily to prototype while Pixel works on designs.

They also introduce Teach a task, which records complicated operations so a bot can learn them. The procedure can be refined through repeated use.

• The demo moves forward in one pass; actual work may require repeated review and revision.
• Changes can also be requested through comments in Notion or Google Docs.

Send the selected option A to Emily

Pixel has been taught the Figma design system, colors, fonts, and UI placements to avoid. It can work to the company’s standards without being briefed from scratch each time.

Pixel produces two mockups, and the audience chooses option A by applause. That choice is sent to Emily, who is already prototyping, with a request to update the work. Human decisions can be added while a task is running.

Emily divides implementation and coordinates checks

Emily splits the work among specialists and provides the objective and required information. An implementation bot starts a Cloud Agent with a copy of the repository to edit code and prepare the execution and testing environment. The presenters describe confirming that Nova can create a PR and starting the cloud work.

After implementation, the assigned bot can review the result, with QA and managers doing further checks. Human involvement varies with the importance of the change; people can inspect a working prototype or demo when needed.

• Development is still running in the background at this point.
• Provide both an environment the agent can test and evidence people can inspect.
• They suggest the same role structure can manage multiple repositories and complex requests.

Teach the job and notify only when needed

Bots need an onboarding period in which they learn skills, business information, and operations. The presenters recommend keeping a bot in the role and improving it through use.

If a routine finds no important change, it should stay quiet. Work that the bot can resolve should be handled without interruption. They also describe surfacing only urgent or important email, then recap a structure with managers, specialist bots, and coding agents beneath them.

• After announcing the template contest, they answer audience questions.

Q&A: individual memory and a shared memory pool

Asked how bots with overlapping responsibilities manage information, the presenters say there is a shared team memory pool in addition to each bot’s own memory. The bot’s judgment and internal instructions determine where information is recorded.

They say one bot can handle both engineering and design, but separate roles can make complex work easier to manage. Their goal is for users to delegate without constantly tracking context size or compaction.

• The shared memory described here and the shared files described in the Founders talk are separate explanations. Their relationship cannot be established from the broadcast alone.
• A break of about eight minutes begins at 6:33:16.

What to build is still unresolved

Returning from the PM session, the team admits it has not agreed on the final product or the software it needs. Eric from Karat Financial joins and asks again whose problem they are solving.

They discuss the appeal of a pop-up: meeting people directly and enjoying products or experiences available only for a short period. Eric sees it as a way for a brand to stand out rather than get lost among many restaurants in delivery apps or online.

• Karat is the inferred spelling of the transcript’s “Carrot”; the official spelling has not been verified here.

Separate first-time organizers from established businesses

Eric points out that the inexperienced team needs different help from a business that already has a shop or products. He proposes starting with their own case: a technology brand bringing people together.

A generic page for everyone might miss specific needs. For a gathering that sells Grok Bot merchandise, products, registration, and the venue take priority, while the detailed time-slot reservations considered for dining become less important.

• Ideas to encourage registration include showing that friends are attending.
• This direction is provisional and is reconsidered again near the end of the day.

Divide roles and sketch screens in tldraw

Matt creates bots for roles he needs, such as growth, founding engineer, image generation, Creative Director, and Chief of Staff. Broad work is organized by function, while independent tasks such as document updates get a dedicated owner.

Lauren has a bot use the browser to draw rough screens in tldraw. They use the sketches to discuss registration, products, and venue selection. Merchandise is also discussed as a reason for people to gather.

• Product ideas include hats, good-quality hoodies, and plush toys people could grow attached to.

Useful products and things people want for their novelty

Matt says he likes hats and hoodies that are good enough to use himself. A Snorlax plush toy from a friend brought back childhood memories and made him happy. Usefulness and novelty emerge as two criteria for products.

Eric talks about the unusual weight of a tungsten block, leading to the idea of one shaped like a Grok Bot. A quick price check suggests it would be difficult at their imagined selling price. They also consider a small special edition or raffle prize.

• Someone says they would pay $80, while the sphere they look up costs $500. They have not obtained a manufacturing quote.

Chat Q&A: shared templates and a bot’s scope

A viewer asks whether using another person’s bot carries over its previous learning and whether it can be changed afterward. The answer is that a shared template includes the role, instructions, some information, and integrations used to create a personal version. Personal chats and sensitive information are not carried over, according to the explanation.

To judge whether a bot has too much scope, look at whether its replies fit the goal and whether output quality is declining. Narrow its responsibilities or clean up its context when needed.

• They also describe a dedicated entry form for passwords.
• The earlier 101 discussion of duplicating a bot and this discussion of shared templates describe different information being carried over.

Make tickets collectible and turn bots into physical objects

Inspired by the sheen of cards, Lauren suggests making the first Grok Bot event ticket something people would collect. Merchandise ideas include stress balls, hats, and plush versions of individual bot characters.

They also consider letting attendees design a bot and give its physical form simple functions, such as lighting up at a revenue milestone or announcing news. A viewer suggests an experience like Build a Bear.

• Manufacturing methods and prices have not yet been researched.
• Using a partner’s location also comes up as a casual idea, but is neither implemented nor carried out.
• The proposal is to have separate bots investigate tickets, merchandise, and venues.

Prioritize their own event

Asked whether they are still building a general-purpose platform, the team proposes first making the tools its own event needs, with expansion to other users as an additional goal. Products, the event experience, and a venue come first.

When Roshan returns, they explain the three areas—products, venue, and tickets—and the ideas discussed so far. They also send the conversation to a bot through voice input and update the documents so everyone has the same information.

• The current emphasis is on a merchandise-oriented event.
• They judge products by everyday quality, novelty, and enjoyment.
• One idea is to turn the Grok Bot characters they use into plush toys or other objects.

Research suppliers and narrow the range to feasible products

Grok Imagine generates merchandise concepts, but the logos and eye shapes are wrong and need correction. The team discusses checking what suppliers can make and choosing two or three well-made products.

Other ideas include selecting a favorite product during registration, viewing it in 3D, and exchanging a commemorative ticket at the venue. Printing companies and venues need research, and the venue list is shared in Notion and Slack.

• A venue list exists, but no booking has been confirmed.
• Researching suppliers on sites such as Alibaba and negotiating quotes are proposed; sourcing is not complete.

Build for the first customer, then consider expansion

Eric explains that his company first built banking and credit services for creator businesses, then expanded the common parts to other businesses. It also runs activities such as gatherings for creators to help customers with their work.

The pop-up software might similarly begin as a tool for the team, with common features later offered to other organizers. They say they want AI to serve a broad range of small businesses, including people without technical expertise.

• The financial services are part of Eric’s description of his own company, not proposed features for this event product.

Start by delegating work whose results can be checked

Eric says creative quality is difficult to assess, while the steps and results of brand-partnership work are easier to verify. He gives an example with separate roles for finding candidates, contacting them, negotiating terms, and preparing proposals.

He recommends finding a complete task in one’s work whose outcome can be judged and assigning it to a bot. The discussion ends and the broadcast moves to the Founders talk.

• The example outreach and negotiations with brands are not performed during the broadcast.

Delegate necessary work to leave time for product decisions

Shub describes keeping a bot in a role long enough to accumulate experience, then forming a team of bots with different specialties.

Founders need to handle many messages while keeping production moving and making decisions. Delegating necessary work that does not require their highest priority reduces the information they must personally review.

He says routines, webhooks, and event-triggered work can make the intensive individual attention given to early customers repeatable.

• He presents these uses as relevant to department leaders as well as founders.
• The main uses are customer acquisition, checking product changes, competitor research, and responding to customer requests.

Close Bot: research the person and their usage before a call

Close Bot researches the company, product, and usage history of the person being met, then prepares talking points. The demonstration uses the fictional company Northwind to avoid revealing confidential customer information.

For a free or trial customer, the presenter wants to know quickly who they are and what they use. He describes reading meetings from the calendar and doing the research in advance, leaving him a short briefing to read before the call.

• The bot needs access to previous usage metrics and meeting information.

Inspect the website and carry lessons into the next meeting

The meeting brief is an HTML file containing website screenshots, usage trends, suggested questions, and risks. Identifying a concrete bug, such as a cookie banner covering a submit button, can provide a useful opening for the conversation.

After the meeting, the bot reads the Granola transcript and records what drew a response. This helps avoid repeatedly pitching a feature the person did not care about.

• The figures and usage information in the brief are demo data.
• He describes it as a short internal document to read before a meeting, so it does not need elaborate visual polish.

Delegate support and activation as well

Close Bot also handles support for existing customers. Shub says completing those requests may require access to data and billing information. Permissions should match the work being delegated.

The demo shows an activation example: detect a template shared with the team, grant credits, and announce them by email. Contracts, lead organization, and scheduling can also be assigned to the same bot.

• The $1,000 credit is a deliberately large fictional demonstration amount.
• Shub says he takes some conversations back when he wants to engage deeply with a customer himself.

Prod Bot: use the product that is actually live

Shub recalls demonstrating a feature that had already been removed. As changes accumulate, even a founder can lose track of what is live. Prod Bot summarizes releases, removals, and details that need another look.

It reads PRs and Linear, logs into the product, uses it, and returns screenshots and videos. The Flylo demo checks both development history and the screens users see. He says usage metrics can also be supplied to add the effects of changes to daily reports.

• Screenshots and videos let a person quickly inspect the result of an interaction.

Stalk Bot: sign up for competitors and track product changes

Stalk Bot researches competitors’ sites, changelogs, X posts, and hiring. It also signs up and tries onboarding and key features. The demo treats Craft and Notion as competitors to a fictional note-taking product and summarizes the findings in HTML and videos.

It checks for changes every few days and reports only important ones. He also suggests emailing customers known to have moved to a competitor to ask why. This information helps decide how the company’s own product should differ.

• The Stalk Bot template is shared at the end of the talk.
• Individual findings, such as hiring activity, reflect research at the time of the broadcast.

Proto Bot: turn customer requests into prototypes and PRs

Proto Bot has an environment where it can operate Grok Bot under a separate account. It checks the current interface and behavior before prototyping and doing QA. Shub describes collecting feedback from X and support channels and creating fix PRs.

In the demo, he supplies a request to make the template-sharing button more prominent. While the Cloud Agent starts work, he says the founder must decide which requests to adopt.

• Implementation is still running during the talk. Completion and production deployment are not confirmed.

Yap Bot learns the writing style; Misc Bot takes miscellaneous requests

Yap Bot learns the user’s writing style from email, Slack, and iMessage, and helps other bots write outward-facing messages. Sensitive emails can remain drafts; it learns from the difference between its draft and the text the person actually sends.

Misc Bot takes miscellaneous questions, such as whether an album has been released. If something relevant to work emerges, it can pass that information to the appropriate bot. Shub also describes Close Bot sending feedback to Proto Bot and Prod Bot sending product changes to Close Bot.

• Yap Bot’s role here is to write in the user’s style. This is not a speech-synthesis demonstration.
• A separate destination for miscellaneous requests keeps unrelated questions away from specialist bots.

Spend one or two hours listing what to delegate

He recommends giving a bot the necessary tools and information, then correcting it and continuing to use it when its work misses the mark. Teach the process and improve it through repeated use.

He suggests spending one or two hours listing daily work and deciding what to delegate. Clear deliverables and procedures make the same task easier to assign repeatedly.

• He says vague requests such as “make it better” are unlikely to produce the intended result.

Control costs by reviewing interactions and trigger frequency

Computer use can handle work without a direct integration, but repeating the same interactions consumes time and tokens. Shub recommends available APIs and integrations and reusable operations derived from a single run. He also suggests examining network requests and calling the underlying APIs directly.

He cautions against making routines too frequent. If changes can be received through a webhook or similar input, they can trigger execution instead. Another bot can review routine frequency and recurring failures and improve other bots’ procedures.

Additional suggestions include a writing-style bot, cookies to preserve login sessions, specialist roles, and good skills.

• Whether cookies or APIs can be used depends on the connected service’s authentication and access conditions.
• A QR code is shown for the shared Stalk Bot.

Q&A: dividing roles and using multiple computers

Start by listing work and grouping it into areas such as finance, customer support, and marketing. A Chief of Staff can provide a single point of contact, but Shub personally prefers talking directly to specialist bots. The choice depends on how closely the user wants to supervise them.

An audience member says bots can become confused across multiple computers. Shub says this is being improved and should have become better recently, and asks people to report setups that still do not work.

• He does not say that all problems involving multiple computers have been resolved.

Q&A: can a rule be enforced on every decision?

An enterprise question asks whether mandatory rules can sit outside the model. Shub acknowledges that model decisions are not deterministic. He suggests expressing rules as code or a decision tree and instructing the model to call the function for each relevant decision.

He also mentions asking another bot for approval or consulting a flowchart. These approaches still rely on the model following instructions about when to invoke the rule; he does not demonstrate an external mechanism that enforces every action.

• Shub himself says this would not provide fully deterministic behavior.

Q&A: migrating from other tools and authentication problems

The discussion covers bringing MCPs, APIs, skills, and authentication settings together. Shub mentions a shared source of information, 1Password, and browser sessions, and says a migration-assistance bot is being prepared.

Some services fail authentication or do not want bots on their platforms, so connections remain a problem. Shub says he chose Granola because it made the required transcripts easy to retrieve. He recommends looking for a connection that produces the needed result rather than fixing the tool in advance.

• One audience question is inaudible, leaving only the answer “not yet.” Its subject cannot be identified.

Q&A: UI speed, conversation volume, models, and unwanted memory

Asked whether UI interaction can become as fast as an API, Shub suggests headless browsers and DOM interactions to reduce screenshot-based decisions. Models are also being improved, but the added processing makes it difficult to promise performance faster than an API.

Adding many bots to a group can increase cost as they all respond proactively. He recommends considering whether the work needs a group or just a single mention of another bot.

Coding Cloud Agents can be given a model choice. A bot that repeatedly refers to irrelevant information can also be told to forget it.

• The 101 session demonstrated the visibility of group conversations. This talk also discusses their cost and volume.
• Model selection here mainly refers to coding agents in Cursor or Grok Build.

Q&A: template review, other accounts, local execution, and memory

Shub says marketplace bots are reviewed by people and bots. He recommends asking what a template does and how before using it. Direct conversations with bots belonging to other people or accounts are not available yet and are being considered.

Enabling local execution in settings lets a bot use the user’s browser and device. It can also take over the screen or consume local computing resources, which is why he favors cloud execution.

On memory sharing, he says each bot has separate context and memory but can share files, describing “one VM with multiple instances or desktops.” In contrast, the 101 talk said a bot could not access another bot’s computer. The broadcast alone does not establish the precise isolation boundaries.

• Collaboration among one user’s bots is distinct from collaboration across people or accounts.
• The relationship between 101’s computer isolation, PM’s shared memory pool, and Founders’ shared files has not been verified.

Q&A: which work should go to Cloud Agents?

Shub describes Grok Bot passing the necessary information to a Cloud Agent and receiving implementation results. With access to the target environment, it can also perform QA and inspect PRs. He recommends coding Cloud Agents for complex implementation, production changes, or tasks requiring control over the model.

He says trying a few tasks helps users learn which light work can stay inside Grok Bot and which should go to a Cloud Agent. Define the assignment once so later work is delegated appropriately. He repeats the contest announcement and closes the talk.

Run several businesses with 22 bots

Jenny says she uses Grok Bot in ventures including VC, media, and real estate while raising a baby. She has built a media agency that supports executives’ communications and says she uses 22 bots.

Master Chief coordinates roles such as Boxy for the inbox, a note-taking bot that processes meetings and delegates work, and a finance bot for receipts and books. They work together in groups when a project crosses several responsibilities.

• Shub preferred speaking directly with specialists, while Jenny delegates management to a Chief of Staff.

There is a venue list, but outreach and requirements are still ahead

Asked about progress, the team says it has listed candidate venues but has not progressed with inquiries or operations. It is considering an open warehouse or gallery-like space for about 100 people, perhaps more.

Jenny asks about the date, alcohol, and food format. The tentative answers are next month or later, no alcohol to simplify preparation, and hot food. She says these requirements should be given to the bot before venue searching.

• The business-building goal is 72 hours, but the team has not committed to holding the event within that period.
• The required permits have not yet been researched.

Check timing, kitchens, and approved vendors

Venue choices depend on whether the event is at night, uses an on-site kitchen, or brings in catering. Some venues require particular food vendors, so the team also considers choosing a good space and adapting the food to its conditions.

Jenny suggests placing an event-planning bot above bots responsible for venue research and coordination. Work can be divided much as it would in a human event-production team.

• Give the requirements to each bot so it can check venue suitability and availability.

Set a budget before requesting quotes and negotiating

Jenny proposes delegating venue emails, quotes, and availability checks to a bot. With a budget and negotiating boundaries, it can also discuss terms. She says she uses rules like this for a bot negotiating clothing resale.

The team has not set a budget. To establish prices and production costs, it asks a bot to act as an experienced planner for a pop-up with 100–200 guests. The budget should cover venue, food and drink, and staffing, including people for registration and security.

• Marketing could sit in the company budget or the event budget; they choose to keep it separate for now.
• Sending a quote request to a venue has not been confirmed.

Add microphones, speakers, and permit research

They may not need a DJ or a large stage, but they need a microphone and speakers to address attendees. A venue that includes equipment and staff would reduce the work of finding separate vendors.

Jenny proposes another bot to research permits and rules. Requirements differ by city, so the research must fit the location and event format.

• Include a microphone and speakers as basic AV equipment in the budget.
• At this point they have requested research; actual legal requirements have not been established.

Use AI for the first contract pass, followed by experienced review

Jenny says AI can help with an initial reading of contracts and rules, but may not understand local or industry practice. She recommends having an experienced person review the contract too.

Understand the roles and steps a person would perform, then assign the bot roles accordingly. In this discussion, Jenny’s event experience reveals conditions the team needs to investigate.

Research and draft overnight, then decide what to send in the morning

Jenny recommends having bots research candidates and draft inquiry emails overnight, then letting a person review recipients and wording before sending them in the morning.

For invitations, she suggests researching followers in the host city. The team also sees potential in the X audience watching the stream. The discussion ends with anticipation of the event, although its operations are still undecided.

• Her example is to find the 50 local followers with the largest followings.
• No inquiry or invitation is confirmed sent, and no attendance is confirmed. The demo also does not verify that candidates’ locations were identified correctly.

Narrow down what to build in the remaining time

They reflect that the idea changed several times during the day and may change again. They learned a lot from the guests, but now need to choose one or two things to complete in the remaining time.

Reconsider whether the pop-up should be the business

Slack, bot-driven Notion updates, GitHub, and Vercel are in place, and work has begun on the landing page and dashboard. But hearing the operational requirements raises doubts about choosing a business as difficult as a pop-up.

They plan to think overnight and return the next day to decide what to build. There is no announcement of a confirmed venue, revenue, or a functioning business.

Close with the contest announcement

They repeat the viewer bot-template challenge and say they will return the next day. After briefly mentioning a video problem, the broadcast switches to music and ends.

• This article covers day one only; it does not include results from subsequent days.