How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)
In a Nutshell
SpaceXAI built Grokbot in one month as a standalone product with dedicated cloud computers for each AI agent, rather than integrating into Cursor or sharing user machines. The team prioritized reliability over features by unshipping visibility tools and abstractions, then focused on giving agents access to real computer interfaces and business systems instead of APIs. Key insight: users naturally converged on "chief of staff" patterns where one primary bot manages other specialized agents, and success came from treating agents as autonomous teammates rather than chat interfaces.
These notes were generated by AI and may contain inaccuracies.
The ultimate vision of Grockbot is to have a team of AI bots that help with both work and life. The product launched three weeks prior to the recording and quickly gained significant traction, with hundreds of attendees at a Grockbot meetup standing room only. The product is described as the hottest AI product in the world at the time, with users migrating from competitive tools like Co-work and Codex.
"Once you start breaking out of this is AI chat with a set of connections instead to this is a colleague with a computer. It just raises the ceiling of what you would think to give to AI."
Grockbot originated as a completely blank page, from-scratch build exercise. The team had been building intuition about agents through developer-focused products like Cursor, but wanted to understand what an agent product would look like for knowledge work. A small team of a handful of people was created to go into isolation for about a month with the sole objective of building an amazing knowledge work product that brings agents to the rest of the company.
The first line of code to internal prototype took approximately one month. The team was physically isolated in a separate part of the office with private Slack channels. This small, focused, isolated structure was considered critical for moving quickly and making micro decisions daily. A larger group working on a 6-12 month vision would not have reached the same outcome.
After the prototype was ready, an all-hands meeting was held to share the product across SpaceX. The first week after the all-hands saw extraordinary internal reception, with people switching from ChatGPT and other tools to use Grockbot as their primary agent surface. Users who wouldn't have been expected to adopt the product became daily drivers.
The decision to build Grockbot as a completely separate product rather than integrating into Cursor was controversial and not obvious at the time. While competitors like Codex evolved their coding agents into knowledge work tools within the same surface, the team evaluated adding new tabs for different form factors and found it would feel cluttered. Users could feel when multiple different visions shared a screen. Starting fresh allowed control over every pixel and a consistent vision of knowledge work.
The team manually onboarded 200-300 people over a two-week period, including the podcast host. The core team participated directly in onboarding calls to experience pain points firsthand. This included witnessing when computers weren't spinning up or when users were confused during onboarding, which immediately led to fixes the next day.
The early access group included not just influential users but also unconventional profiles like a coffee shop owner who became both a power user and rich source of feedback on integrations like Shopify.
During internal rollout, a pattern emerged around week two where users began promoting one standout bot as their primary personal assistant, which then managed other bots. Screenshots showed bots being promoted and asking about raises and token budgets. This pattern was observed internally but not imposed on external users during early access. Many early access users arrived at the chief of staff pattern independently.
A key design decision was to hide internal mechanics from users. Rather than showing tool calls, every click, or chain of thought, users see only a typing indicator and green active circle similar to Slack. Progressive updates are sent as the bot sees fit. This approach was validated when users requested to-do lists and prioritization views, but nobody wanted the long streams of text and chain of thought sequences.
During the three weeks between internal beta and public launch, the team unshipped many experimental features including visibility tools that exposed internal model thinking and memories. The focus shifted to making the product work reliably rather than adding features. Backend improvements addressed specific failure modes like insufficient mouse control precision on Salesforce dashboards.
The sales team was among the most enthusiastic adopters because tools they used lacked well-supported MCPs or APIs, and Grockbot could complete workflows that previously failed. The recruiting team was also identified as a top user group.
- Month of building from first line of code to internal beta
- Three weeks from internal beta to public launch
- Three weeks since public launch at time of recording
Grok Bot has been valuable as a sourcing tool for recruiting. The company's hiring philosophy does not require someone to be actively on the job market before attempting to hire them. Instead, the approach is to identify the biggest problems at the company that need ownership, find the best people in the world to solve those problems, and then work to convince them to join.
The most useful recruiting workflow is not sorting through resumes. The more valuable approach is matching the entire universe of potential candidates to concrete business problems or specific roles, then facilitating introductions and meetings. This has led to unexpected ways of finding top talent, such as going beyond LinkedIn to find co-authors of papers that exist only on conference websites rather than Google Scholar.
The bot can be set up to automatically visit conference websites each morning, download new PDFs, identify new names not yet tracked, add them to a spreadsheet, research the individuals, check for connections at SpaceX, and send Slack messages requesting introductions when connections exist. These always-on sourcing use cases were previously incredibly manual but are now handled effectively by AI.
AI excels at generating more ideas and features but is not good at determining what to remove. Deciding what not to ship has been a significant part of the internal evolution from prototype to launch.
The team uses a framework where for anything being worked on, they ask what the launch post or launch tweet would be. If it is not compelling enough to tweet about, it may not be worth pursuing. This extends further by reframing product updates from "Grok Bot now has" (which suggests new buttons, dropdowns, or integrations) to "Grok Bot can now," which is a more human way of describing capabilities.
This forces the team to think in terms of tools and capabilities given to Grok Bot rather than new things added to the product. Adding things to the product is not the goal. The focus is on making bots reliably do impactful work behind the scenes in ways that just work.
Many Grok Bot features that were initially considered "Grok Bot now has" features have been recognized as capabilities that do not need pixels. The goal is to kill as many pixels as possible, allowing the bot to manipulate things behind the scenes without requiring direct user control.
Competitors often require users to set up automations through a clunky sidebar interface where they press plus, select trigger events, select actions, and may describe them in natural language. This friction means people set up fewer automations. Grok Bot's approach is to define automations in natural language by simply telling the bot what to do, such as reminding the user at 8 a.m. every day. The automation interface never needs to be seen. This is now how 99% of automations on the platform are built.
Two early decisions were critical to Grok Bot's success. The first was the decision that users should never have to think about local versus cloud infrastructure. There should be no concern about whether a computer needs to be awake or whether a phone-initiated workflow needs to be tethered to a home computer. The decision was made early to run everything in the cloud with a persistent agent that has its own computer and can do its own work. This provides consistent state across all interaction points and enables texting the bot from a phone or calling it from anywhere to have it do real work.
The second decision was that these bots need their own computer rather than sharing the user's computer. Many tasks lack well-supported MCPs and APIs, and humans do their jobs by using computers, clicking on pixels, and typing in input boxes. Bots need these baseline capabilities as well.
Onboarding AI bots to share the same computer as the user creates significant friction. The analogy is onboarding a new human teammate by having them share one laptop forever, constantly tripping over each other, and having mutual access to credentials. This is not how people operate with human teammates, and the same principle applies to AI colleagues.
Starting from scratch rather than building off an existing coding assistant platform allowed these decisions to be made without being constrained by sunk cost in an existing paradigm. The team had previously built cloud infrastructure for coding agents and had seen patterns of naming agents and treating them as discrete entities in Slack, but chose to create a new surface optimized for general knowledge work rather than retrofitting existing concepts.
OpenClaw influenced Grok Bot in two major ways. First, OpenClaw demonstrated that if models are given access to the tools people actually use to do their jobs, including their own computer, they can accomplish much more than people assume. Second, OpenClaw changed the mental model of AI from tools to colleagues and teammates that have access to a person's life and can extend their capabilities.
Grok Bot extended this by focusing on making the experience easy to set up without requiring hacky home setups like VPNs and Mac Minis, which would not scale to millions of users or work for businesses. The team also focused on sanding down rough edges to create a delightful product experience and removing abstractions that power users are familiar with, such as skills. Users should never have to know what a skill is or type a slash command. These should be created in the background as useful primitives.
The ultimate vision is that users should have a team of AI bots that help with both work and life. These should feel like autonomous teammates that can be steered without micromanagement and have access to the tools necessary to do ambitious work.
The product development north star is to think less from the perspective of a SaaS product and more from the perspective of building useful AI teammates. When product debates arise with sensible arguments on both sides, the team asks what a human teammate would do in that situation. This often provides a clarifying and unanimous answer.
One example is voice experience. Human collaboration often involves shifting from Slack back-and-forth to a quick five-minute huddle with screen sharing, then returning to async work. This pattern should also exist with AI bots.
There will likely be separation between work and personal bots for many people due to the desire to keep those domains separate, which is important for both personal and enterprise reasons. However, the goal is for Grok Bot to handle a large portion of day-to-day work delegation so users can focus on higher-leverage activities, while similarly handling low-leverage parts of personal life.
The product form factor and problem-solving approaches are essentially the same for both domains. The instinct is that one product will be the best form factor for both work and personal use.
Future power tools will differ from past generations. Rather than interfaces like Photoshop with many precise knobs and dials requiring expert manipulation, future power tools will primarily involve expressing intent and providing good steering, with the AI abstracting away the knobs. Users should never see the knobs unless they need to directly manipulate them, and there should be great affordances for doing so when needed.
The interface should be primarily conversational. When observing someone using Grok Bot, it can appear for a moment as though they are on a messaging app, when in fact it is their primary tool for doing much of their work.
In the teammate frame, the number of times one would need to manually take over a colleague's computer and start clicking should be close to zero. Currently, computer use is good and improving, but in the medium term the computer concept will be completely abstracted away from the user. Users should never be clicking into a remote virtual machine or taking control. The computer concept will remain important but should not require direct user intervention.
Grokbot should be understood as a team of agents that perform work on behalf of users. These agents maintain access to a very long memory set of past interactions rather than requiring users to create new chats for each discrete unit of work. The current paradigm of creating separate chats for individual tasks creates problems, including frequent copying and pasting between chats and poor categorization of work. Instead, agents should have defined roles that correspond to different swim lanes of work, allowing them to learn from users and become smarter over time.
Agents need access to all the tools a human colleague would have, including APIs and MCPs. Beyond this, agents should have access to their own computer that they can manipulate freely. A demo by Shub from the go-to-market team showed agents running their own Grokbot instances within themselves, which was used for testing and watching regressions. This capability expands the ceiling of what tasks can be delegated to AI beyond what most people currently conceptualize.
One practical application involves downloading Grokbot for a dedicated QA tester bot. When testing new builds of desktop apps or addressing bug reports, users can provide 10 workflows to test and have the agent write results to a Notion document that maintains an extensive list of past tests across client versions for comparison purposes.
Grokbot functions as an infovore that consumes large quantities of information, removing this cognitive load from users and surfacing only important items. The V1 implementation involves Grokbot monitoring Slack and email based on high-level role descriptions, notifying users in specific cases while including other information in daily roundups. More advanced implementations connect bots to complete information fire hoses, such as every mention of Grokbot on X, with interactions between internal context and QA testing systems to reproduce bugs or feedback.
Advanced users have given Grokbot the ability to page them when urgent matters arise, though this requires high trust in low false positive rates. This represents a shift toward agents being more proactive than users reaching out to them. The focus is now on business applications, including how bots work inside broader teams and real company systems with complex context and history, rather than just single-player use cases.
The approach prioritizes giving out free accounts and focusing on use cases to capture market share rapidly before competitors like foundation labs release competing products. The pattern observed in coding tools is expected to repeat for general knowledge work, where early adopters use tools on nights and weekends for side projects, experience extreme acceleration, then demand these tools at work.
The company culture emphasizes building actually useful products rather than demoware, focusing on getting AI into the hands of millions of people and transforming companies. This differs from building shiny objects or fun prototypes. The three main pillars of SpaceX AI are the coding product (Cursor and Grok Build), general knowledge work (Grokbot), and the general model effort to train the smartest models with practical rather than aspirational goals.
SpaceX AI distinguishes itself by focusing on building useful AI rather than chasing super intelligence or vague aspirational ideals. The model training effort involves engineers who approach the work from an applied mindset, which differs from some competitors.
A pinned tweet states that an AI that does 100% of the job feels categorically different from one that gets you 90% there. This represents a significant update in thinking about AI capabilities. Engineers have been experiencing this level of delegation for about a year to a year and a half, but most people still use AI in the traditional way of creating threads, typing inputs, and iteratively refining outputs.
Grokbot enables users to delegate work without ongoing mental monitoring, creating a fundamentally different experience from 90% trust scenarios where users must remain involved and ready to intervene. This is analogous to throwing a "no-look pass" to a trusted colleague rather than delegating to someone requiring constant oversight.
The company maintains startup-level speed despite scaling from 15 people at Cursor to over 1,000, then joining SpaceX. This includes rapid feature deployment like launching marketplaces with templates in two days and providing free codes immediately upon feedback. The culture preserves the chaotic, high-impact energy that enables extreme results in short timeframes.
Cursor succeeded in the most competitive market against OpenAI and Anthropic by quickly adjusting to market reality rather than becoming complacent. The company started as autocomplete, evolved to talking to agents, then to cloud, and now Grokbot. This continuous reinvention happens every six months or less, with the belief that AI capabilities move incredibly quickly and products must meet the moment as capabilities strengthen.
Two core values guide operations. The first is "deleting the product," which involves removing scaffolding and product overhangs as models become capable enough to handle tasks directly, even if this upsets small user groups. The second is "do the thing," which creates a culture without permission-seeking where individuals identify needs and pull resources to fix problems without waiting for approval.
Rather than relying on traditional moats, success stems from an obsession with building useful things today while constantly updating beliefs about where the world is heading. The data feedback loop from autocompletion and best-in-class experience contribute to competitive advantage, but the core driver is the cultural inability to become complacent in a rapidly changing environment.
The approach that proved effective was identifying capabilities that aren't solvable now but will be in the future, then determining how to bring those capabilities forward even if it requires substantial engineering work. This might involve changing the product specifically so users can interact with the new capability. The strategy involves building something that will become the common bare minimum in three months, then deleting all the temporary scaffolding once the capability becomes standard.
This constant iteration of pulling future capabilities forward led to users trusting the product and investing their time, because they saw the team consistently bringing things to the next frontier.
Founders should adopt a perspective of making something that isn't possible now actually possible. Users will come specifically to use that new capability. This creates distribution advantages and data advantages over time, even if value isn't immediately obvious. The key is playing at the next impossible frontier rather than optimizing within current constraints.
Modes in a product are typically discovered through iteration rather than planned ahead of time. Building something people are obsessed with takes priority over overthinking competitive moats. If you continue building what users love, the moats will emerge naturally.
When getting started with Grokbot, the priority is giving it the context needed to be successful. Similar to onboarding a new team member, providing access to tools like Slack, email, and company records enables the system to understand the user's workflow.
The recommended first task is to ask Grokbot what it can do given the connections established, letting it review the connected systems and suggest specific tasks it can take off the user's plate. One user found that asking for five suggestions resulted in two genuinely helpful automations that could be immediately spun off into dedicated bots.
This approach moves beyond simple tasks like drafting emails to having the AI perform actual chunks of work.
Experienced users are finding new patterns for bot-to-bot interaction and collaboration. A useful practice involves creating a scaffold for where artifacts created by Grokbot should live, writing outputs to a single store that's legible and organized. One implementation involves frequent digests that get pushed to a database for easy daily reading.
Recommended Books:
- Cat's Cradle by Kurt Vonnegut
- The War of Art by Steven Pressfield, which addresses the challenge of being creative and overcoming resistance when creating something new
Favorite Media:
- Casablanca is rewatched annually, partly due to the character named Ugarte
- Monk provides a snapshot of San Francisco in the late 1990s and early 2000s
AI Product Recommendations:
- Exa (formerly Metaphor) for semantic search, particularly for unusual queries over web data or specialized datasets like image collections
Life Philosophy:
- The Desiderata poem, kept posted on doors since teenage years, providing new insights with each reading
Grokbot was released in beta three weeks before this conversation. User feedback from early users is directly influencing ongoing development. The team encourages sending feedback as they're still in the early stages of building the product.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
