Grok Bot: a company in 72 hours
Livestream diary
Three people from xAI set out to build a company in 72 hours with Grok Bot, live. Here's the story day by day, with a link to the minute of each moment and to the lesson where you learn to do it yourself.
Day 1 · 15 September
Grok Bot 101 · Engineering · Product · Founders
Day one was about getting started. They picked an idea from the audience's suggestions, turned it into a landing page with its own domain and assembled the first team of Bots. Along the way came an introduction to Grok Bot, an engineering workshop, two sessions on Bot teams already in production and several guests offering business advice. It ended with pitches done, the Bots wired to Notion, GitHub and Vercel, and the first landing page live.
Day 1, first hour. Before building anything, the stream stopped to explain what Grok Bot is.
Two people from the product team created a Bot from scratch and asked it out loud for a form with two questions about coffee. The form was built in front of everyone, click by click, on the Bot's own computer.
Then a second Bot drafted an email with that data without anyone asking. A rule written into its settings stopped it before it sent. And not everything worked: the form's QR code errored out because the link was not public.
This module comes out of that hour.
Day 1, mid-morning. It was time to decide what company to build.
The day before they had asked on X and had thousands of replies. A Bot grouped them: no more software demos, something physical and local, nostalgia for old games. That gave them the direction, a platform for running restaurant pop-ups in San Francisco.
For the landing page, Lauren, from the Grok Bot team, did not ask for a design straight away. She asked for references to well-made sites, dictated the idea for a couple of minutes and made the Bot repeat it in its own words. The Bot added something nobody had asked about: the hard part was not the website, it was finding a venue, cooks and an audience.
Almost all her work was giving the Bot context. That is what this module covers.
Day 1 · 1:43:15The Bot summarises thousands of audience ideas
Day 1 · 2:15:17Asking the Bot to repeat the idea in its own words
Day 1, midday. With the idea settled, something had to go live.
Roshan, who runs product, created an empty repository and wired it to Vercel so every change shipped on its own. While they were still configuring it, the Bot had already pushed the first version of the page.
They connected Notion to store decisions and asked for domain names. They bought one that ended up naming the company: Ship by Thursday. The database credentials were slow to arrive, so they told the Bot to get as far as it could without them.
Connecting your tools, leaving sessions signed in and scheduling work without handing over more access than needed is what comes next.
Day 1 · 2:35:42The Bot pushes the page while they connect Vercel
Day 1, late afternoon. They had an idea, a domain and a first page live. Time to split up the work.
Lauren installed a Bot from the marketplace that creates other Bots and used it to build her team: one chief of staff, one for quick prototypes and a third engineer. Matt, who runs developer relations, made himself a prospecting Bot to find restaurants.
Then a guest made them stop. Before creating more Bots, what number were they trying to move? Her advice was to try selling it to three people before building anything, start on X without paying for ads, and save every good comment from day one.
Hours later Lauren needed a new Bot and Matt did not explain how to make one: he sent her his as a template. That is where this module comes from.
Day 1 · 2:05:40Dr. Eggbot turns Steve into a chief of staff
Day 1 · 2:57:57Codie Sanchez: sell it to three people before you build
Day 1, afternoon. The engineering Bot was already coding on its own, and that is where the scares began.
They told it to work in the cloud and come back with a video or a screenshot before deploying anything. Soon after, it opened a pull request of some two thousand lines on its own. The answer was a clear rule: no pull requests for now.
Off camera, Lauren set up what she called her engineering factory. One Bot reviews what the other opens and an automation posts every change to Slack. The workshop that followed showed the next level: a freshly installed Bot that learns the team's rules by asking another Bot, and code audits running overnight.
That path, from delegating the code to automating it with verification in between, is this module.
Day 1, last build block. It was the messiest stretch of the day.
The shared screen froze, one Bot could not reach the repositories and another failed to note the event date. They still moved forward: the landing page was storing signups and sending confirmations, one Bot found the best street corners for handing out flyers and another pulled together twenty-odd caterers with phone numbers.
Halfway through they changed plan. The first pop-up went from restaurant to art exhibition, and the first thing they did was tell the coordinating Bot so the rest would stop working on the old idea.
In parallel, other sessions showed teams that have been running for a while: a product one that goes from a data question to a prototype, a founder one that preps calls and watches competitors. The real cases in this course come from there.
Day 1 · 5:39:38Change of plan: from restaurant to art exhibition
Day 1, closing. The day ended with two conversations about what a demo never shows.
In the founders' session, someone from xAI explained how to keep Bots from overspending: fire routines when something happens instead of every few minutes, have Bots call a site's API rather than clicking through it, and send one-off questions to a separate Bot.
Then a guest who runs seven businesses with twenty-two Bots sat down with them. She helped write the budget prompt and said what she would not hand to a Bot: the guest list, security and the final read of a contract.
What this way of working costs, and where a person should keep deciding, is the last module.
Day 1 · 7:55:39Using the API instead of the browser to spend less
Day 2 · 16 September
Sales Engineering · Sales · SDRs · Customer Support
Day two opened with a change of plan. Overnight they had left the Bots reviewing the pop-up idea against the guests' advice, and by morning the conclusion was that it could not be built in two days. They became a game studio instead. The first game turns the audience's Bot templates into characters that fight each other. By the end of the day they had login with X, an empty leaderboard, generated music, video ads and a Notion board where a dozen new Bots divided the work.
Day 2, as the stream opened. "The agents sold us on the pivot," was how Matt put it.
The previous day's guests had warned that a pop-up in San Francisco needs licences and permits. The Bots, working overnight, reached the same conclusion. Half an hour at the whiteboard produced the new idea: everyone uploads a Bot they already use, the game gives it stats and an ability, and pits it against someone else's team.
Soon after, in the first workshop, a Bot went into a real airline's booking site on its own computer to compare it with the made-up airline in the demo. Nobody had set up any integration for it.
What a Bot is, what computer it uses and what it can do without asking you first: that is what the lessons in this module explain.
Day 2 · 0:11:08The agents sell them a pivot
Day 2 · 0:51:05Serena tries Southwest's site on her computer
Day 2, first hour. The game did not start in code, it started in a plan.
Lauren wrote it while the other two stayed at the whiteboard, and asked her chief of staff Bot to talk to the Bot that creates Bots and have it build an engineer. At the end of the message she added her usual line: restate this in your own words before you start. Someone said it would be strange to talk to a person that way. Her answer was that this is active listening.
Later she saw that the engineering Bot's description was full of details from a single problem. When a rule is born from one specific mistake, the agent packs that whole case into it and the skill ends up a pile of examples that no longer apply. She asked it to rewrite the rule as general principles.
That is this module: what a Bot remembers, how to teach it a task and how to give it the right amount of context.
Day 2 · 1:32:28Restate this in your own words before you start
Day 2, mid-morning. A guest creator showed the most talked-about use of the whole stream.
Her Bot builds a personal newspaper overnight with her calendar, her email, the parcels arriving and a crossword with clues from her life. Then it finds a printer on the wifi and prints it without asking. She also said that wiring up her split-flap display took two minutes: she pasted an API key and that was it. Coding it by hand had taken far longer.
In the studio, the Bots started finding things out for themselves: one got notified of every pull request, another listened for Slack mentions, another watched the board. Mid-afternoon they learned live that the 1Password integration had just shipped, after spending the previous day fighting with credentials.
Connecting tools, signing in and scheduling routines that fire on an event are what this module covers.
Day 2, afternoon. There were so many Bots that a system became necessary.
Roshan asked his chief of staff for a task list and turned it into a board. All three created a Slack Bot at the same time, by voice, and two of them came out with the same name. Lauren fixed the mess with a single instruction: every one of her Bots should treat the board as the source of truth and keep it current.
And she gave the test for knowing when you need one. If you notice you are issuing one-off orders to each Bot, it is time to stop and organise the whole team.
At the end of the day she asked it to read every one of her Bots' conversations and find where the work was getting stuck. The answer was that the bottleneck was her.
Day 2, building the game. The first prototype was throwaway code, no login and no database, with sliders to change the rules in real time.
"If the game isn't fun, nothing else matters," Lauren said. The point was to reach the fun part early without waiting for the agent to finish each change.
There were stumbles. She asked for a glow library and every card came out identical; she admitted she had briefed the agent badly. They realised the debug panel could not live in the browser of a competitive game, because anyone would cheat from the console, so they split client and server. And when the tests started failing, they deleted them all: they would write them once they knew what they wanted to test.
By the afternoon she had a coordinating agent handing work to five more, with others verifying the result. That is how the engineering module works.
Day 2, between blocks. The studio handed over to people already working this way outside a demo.
The owner of a coffee shop with its own roastery has a chief of staff Bot wired to the till. From his phone he asks it what they were selling two years ago, and he sent it a photo of the menu to see which products barely moved.
A creator who makes a living from videos about AI told two stories. He photographed the things he no longer used and let his Bot look up recent prices, post the listings and answer buyers: that is how he sold a console and a laptop. Another Bot went through twelve months of electricity bills and found him a plan a thousand dollars a year cheaper.
Matt summed it up: personal problems look a lot like company ones. Haggling at a flea market is the same as negotiating with a supplier. The real cases in this module come from there.
Day 2, questions from the audience. That is where the numbers and the limits came out.
A whole slide deck cost between twenty and thirty dollars, against four or five hours of work. Answering a medium-difficulty support ticket came to one or two dollars, and batching the easy ones with a script brought it down to about twenty cents. The most repeated advice for spending less was to fire fewer routines and tell the Bot exactly what to look at.
The limits came out too. If a tool does not run on Linux, a Bot cannot use it. Some sites detect that it is a Bot and block it. And one of the guests admitted the problem almost nobody mentions: he gets more done than ever and is busier than ever.
What it costs and where to stop is what this module is about.
Day 2, first whiteboard. It was not about the game, it was about the company.
Matt listed what being one would take: people discovering the game, an email or even a phone line to handle players, and maybe reading the X chat directly. In the afternoon they asked the team's intern what makes a game go viral. He said word of mouth and posting constantly, on X for the first players and in small forums asking for feedback.
Those pieces got a thorough look in four workshops the same day. In pre-sales, one Bot tried out competitors on its own computer while another read the code. In prospecting, a group of Bots researched two hundred companies in parallel. In support, a Bot answered tickets, issued refunds and flagged the urgent ones in Slack.
This module collects those workshops: the work waiting as soon as the game had players.
Day 3 · 17 September
Marketing Ops · Post-Sales · Marketing · Final showcase
Day three was not about building, it was about operating. At ten in the morning they launched the game and within minutes ninety-six people were on the leaderboard. From then on the work was reading what people said, measuring what they did and fixing what broke, with the Bot factory running on its own in the background. It ended with over four thousand matches, around two thousand users, the database down for a while and a first sponsorship dollar never collected.
Day 3, mid-morning. A guest explained how to teach a Bot a craft.
Naming it "data scientist" does not make it one. What she did was tell it to go take courses in the craft, at beginner, intermediate and advanced levels. The Bot found the courses, extracted the traits that define someone good at it and kept them as a permanent skill. She repeated the trick with a design Bot when something looked ugly to her.
In the afternoon, another guest added where to start when you face a blank page: record a fifteen-minute voice memo while pacing around, saying what your job is and which processes are broken.
That is where this module's lessons come from.
Day 3 · 3:08:37Send the Bot to take courses in its craft
Day 3 · 4:22:16Fifteen minutes of voice memo to start from zero
Day 3, mid-afternoon. A phone number appeared on the site without warning.
Matt called live, left his feedback by voice, and the message showed up in their Slack channel instantly. He had written no code: he used a voice workflow builder with a graphical interface and a webhook that catches the call.
The interesting part was where he drew the line. He would not have an agent call people on his behalf, because he himself finds it annoying to reach a robot. For collecting information, yes, and with one mandatory piece: a tool to hand the call to a person when needed.
Connecting tools that far is what this module covers.
Day 3, early afternoon. The post-sales guest showed a team of eleven Bots she does not manage.
She talks to one only, her chief of staff, and he coordinates the other ten. She put it like this: I run a team of one or two, he runs a team of ten. The rest never message her.
And she showed something that had not come up on the previous days: she convenes meetings between her own Bots to decide what to do with the one free hour she has left. The instruction that makes it work is the one worth copying, always disagree, because with AI you do not want everyone agreeing with you.
That is where this module comes from.
Day 3, with the game already live. They chained the Bot that triages feedback to the one that writes code, and wondered whether to dare with full autopilot.
They dared, with one condition: people were already playing, so breaking the game was not an option. Two rules came out of that. The agent has to reproduce the bug before touching anything, because only then do you know it understood. And another Bot checks that whoever read the user's comment understood what it said.
To test, they spin up many agents at once, each with its own computer, that open the game and click their way through it.
That is the level this module reaches.
Day 3, midday. Two talks showed teams that have been running for a while outside a demo.
The marketing operations one described a Bot that built an internal app for salespeople to review their leads, and that stopped to ask which fields should change before writing any code. The answer forced her to sharpen her own idea.
The post-sales one gave six concrete uses: the morning status board, call prep fifteen minutes ahead, the follow-up desk, the promise keeper, the ask watch and the account reset. All real, none invented.
This module's cases come from there.
Day 3, questions from the audience. That is where the limits and the money came out.
On cost, the most concrete answer of the three days: having the Bot open a browser and fill a form by clicking costs more than handing the data to the tool. And the silent spend is routines, because it is so easy to set something checking every fifteen minutes and forget it. Three of those are hundreds of messages a day.
She also put a brake on her own system: the scan that proposes improvements can only send her one suggestion per week, because at first it sent ten and over-corrected.
What it costs and where to stop is this module.
Day 3, first hour. The marketing operations talk opened with one line: build tools, not just rules.
Her argument: in sales the work goes into communicating guidelines and hoping each team follows the right checklist. With a Bot you can build the internal app that respects those rules by design.
In the afternoon, the growth session separated two things people tend to mix. Marketing is the top of the funnel, getting known. Growth is what you do with the people who are already in. And for cold email she gave the criterion: the only thing that matters is that it gets read, and the first thing anyone looks at is the sender's name.
That is what this module is about.
Day 3 · 3:00:00The first thing you look at in an email is who sent it
Day 3, ten in the morning. They launched the game with an unpolished interface, and within minutes ninety-six people were playing.
That is when the work changed. They stopped deciding at a whiteboard and started deciding on what people did: a feedback form landing in Slack, a Bot triaging it, another reproducing every bug, and agents fixing them. Along the way they measured that 71% of the feedback was bugs and that there were more mobile players than desktop ones.
The day ended with the database down for a while and a sponsorship dollar never collected.
This module is that day.
From the diary to the course
The course turns everything that happened in the livestream into short lessons, from the basics to advanced. Start from the beginning or go straight to the module you're interested in.