How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)

Lenny's Podcast 1h22 6 min #30
How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)
Watch on YouTube

Summary

  • Grok Bot is a new AI product from SpaceXAI (formerly Cursor) that lets users create a team of persistent, cloud-based AI “bots” — each with its own computer, long-term memory, and access to tools — to delegate knowledge work the way you would to human colleagues. Roman Ugarte, employee #15 at Cursor and now product lead for Grok Bot, describes how a tiny isolated team built a working prototype in one month, manually onboarded hundreds of users, ruthlessly cut features, and launched a product that feels categorically different because bots can complete entire tasks end-to-end without micromanagement.

Origin story: a month-long isolated build

  • A handful of people went “into a cave” for about a month — separate office space, private Slack, no outside distractions — with the sole goal of building a knowledge-work agent product for the rest of the company.
  • From first line of code to a functional internal prototype took roughly four weeks; the small, focused group could make hundreds of micro-decisions daily without design-by-committee slowdowns.
  • Internal rollout at an all-hands triggered immediate, widespread adoption: non-technical teams (sales, recruiting, ops) switched from ChatGPT and other tools to Grok Bot as their primary agent surface within days.
  • Three weeks of polishing and “making it just work” followed, then public launch; as of recording, it has been live for about three weeks.

Why a separate product instead of inside Cursor

  • The team debated integrating into Cursor but chose a fresh start: coding agents have brand associations and UI paper cuts that intimidate non-technical users, and bolting on tabs creates a “shipping your org chart” feel.
  • Controlling every pixel let them design a single, consistent vision for knowledge work — simple on the surface, powerful underneath — rather than cramming multiple paradigms into one interface.
  • They saw competitors adding tabs for each form factor; Grok Bot’s clean break avoided that clutter and let them rethink primitives (e.g., automations defined in natural language, no sidebar builders).

Manual onboarding of ~200–300 early users

  • The core team spent two weeks doing 20-minute onboarding calls with a diverse group: power users, influencers, and intentionally “unconventional” profiles (e.g., a coffee-shop owner) to escape the Silicon Valley bubble.
  • Painful early sessions forced immediate fixes: if something confused a user on Monday, it had to be fixed by Tuesday for the next call.
  • They deliberately avoided leading users toward internal patterns (like the “chief of staff” bot hierarchy that emerged organically at SpaceX) to see if external users would discover the same workflows — many did, validating the pattern without product bias.
  • Feedback from non-developer users (Shopify flakiness, copywriting tone) revealed blind spots dogfooding alone would miss.

Hiding internal mechanics from users

  • Early design showed model reasoning, tool calls, and memory writes; onboarding revealed users found the raw stream overwhelming and preferred a simple “active” indicator with progressive updates.
  • The team took a strong stance: bots should work like human teammates — you delegate, they execute, you get updates — not like debuggers exposing every click.
  • Some users asked for a high-level to-do view; the team is exploring lightweight summaries but will not revert to verbose chain-of-thought streams.

Unshipping and simplifying before launch

  • In the three-week internal beta, they aggressively removed experimental features and “developer visibility” tools (exposed memory panels, raw tool calls) that were useful for debugging but cluttered the user experience.
  • Parallel effort: hill-climbing five core backend reliability problems (browser control, login flows, pixel-perfect clicking) that users don’t see but feel when a bot stalls.
  • Example: sales team workflows failing on Salesforce dashboards due to mouse-control precision; each infra fix unlocked new chunks of work and generated immediate user love.

Product philosophy: “Grok Bot can now” vs. “Grok Bot now has”

  • Internal litmus test: every feature must translate to a compelling launch tweet framed as a new capability (“Grok Bot can now…”) not a new UI element (“Grok Bot now has a button for…”).
  • Automations exemplify this: instead of a sidebar builder with triggers/actions, users just tell a bot “remind me every day at 8 a.m.” — the bot creates the automation invisibly.
  • Goal: kill as many pixels as possible; capabilities live behind the scenes, manipulated by the bot on the user’s behalf.

Cloud-first architecture: every bot gets its own persistent computer

  • Two foundational decisions: (1) everything runs in the cloud — no local/remote tethering, works from phone, persistent state everywhere; (2) each bot has its own full computer (browser, filesystem, apps), not just API/MCP access.
  • Analogy: onboarding a human teammate who shares your laptop forever is absurd; bots deserve the same independence — their own credentials, their own environment, no tripping over the user.
  • This unlocks tasks lacking APIs (legacy internal tools, gated websites) and enables recursive patterns: a bot can spin up other Grok Bots on its computer for QA, testing, parallel work.

Vision: a true team of AI colleagues

  • North star: “You should have a team of AI bots that help you with your job and help you with your life” — autonomous teammates you steer, not micromanage.
  • Decision framework: “colleague-pilled” — when product debates stall, ask “how would a human teammate handle this?” The answer is usually clarifying and unanimous (e.g., voice huddles with screen-share, not just async chat).
  • Work vs. personal: separation will exist for privacy/compliance, but one product serves both; the delegation patterns (email triage, scheduling, research) are identical.

Long-lived agents with persistent memory and tool access

  • Bots are not one-off chats: they accumulate long-term memory across interactions, learn user preferences, and get smarter over time — like a human colleague who retains context.
  • Tool access mirrors a human’s: APIs/MCPs where available, plus full computer control (clicking, typing, navigating) for everything else.
  • Recursive use case: a QA bot downloads the desktop app, runs regression workflows, compares results to a Notion log of past runs, reports deltas.

Grok Bot as always-on infovore / chief of staff

  • Common power-user pattern: hook bots to high-volume feeds (Slack, email, X mentions, internal trackers), give high-level filtering rules (“notify me only on X, summarize the rest in a daily digest”).
  • Advanced versions: bots cross-reference external signals with internal context, auto-repro reported bugs, draft replies, ping teammates — effectively an always-on chief of staff.
  • Some users grant bots “page me” authority for truly urgent items; early reports show high trust and low false positives.

Moving fast at scale: preserving startup energy

  • Despite growing from 15 to 1,000+ (now part of SpaceXAI), the culture retains “scramble energy”: chaotic, disorganized, but extreme impact in short timeframes.
  • Trust and shared vision let people execute without permission-seeking; “just do the thing” is a core value — if you see a problem, fix it and pull in resources.
  • Speed compounds: they reinvent priorities every few months to meet the moving frontier of model capabilities; competitors with more resources slowed due to cultural inability to pivot.

How Cursor kept winning in the most competitive market

  • Never complacent; deep belief that AI moves fast and products must reinvent every 6 months (now faster) to translate new capabilities into user value.
  • Early competitors (Microsoft, 10–20 startups) faded not from bad decisions or lack of resources but from cultural inability to move quickly and change direction as the moment shifted.
  • Grok Bot itself exemplifies this: a complete reinvention for knowledge work, built from scratch while Cursor’s coding surface continues evolving separately.

Company values: “delete the product” and “just do the thing”

  • Delete the product: scaffolding built because models weren’t smart enough yet (e.g., explicit skill builders, manual memory editors) must be removed as models improve — even if it upsets a few users — to keep the product simple and future-proof.
  • Just do the thing: agency over permission; everyone owns outcomes, pulls resources, ships fast. Shared with SpaceXAI culture.

Moats are discovered, not planned

  • Roman discourages working backward from strategy diagrams; Cursor’s moats (data flywheel from autocomplete usage, best-in-class daily-active-user experience) emerged from obsessing over “how do we make the impossible possible today, then delete the scaffolding tomorrow?”
  • Founders should focus on pulling users to the next frontier repeatedly; distribution and data advantages accrue naturally from that loop.

Tips for new and power users

  • New users: give the bot access to your core tools (Slack, email, calendar), then ask “go through my Slack and email and suggest five things you can take off my plate.” Spin up bots for the best suggestions — the “wow” comes from delegating chunks of work, not drafting emails.
  • Power users: design a shared artifact store (database, Notion, structured docs) where bots write outputs legibly; build scaffolds for bot-to-bot collaboration (e.g., daily digests, cross-bot handoffs) rather than relying on chat history.

SpaceXAI’s three pillars

  • Coding: Cursor + Grok Build — professional work surface optimized for production software engineering.
  • General knowledge work: Grok Bot — agent teammates for the rest of the company.
  • Models: training the smartest, most useful models (practical applied mindset, not abstract superintelligence chasing).
Back to Lenny's Podcast