Context

Roman Ugarte was employee number 15 at Cursor and led growth there before helping incubate Grok Bot, SpaceXAI's knowledge-work agent product that went from an isolated team's first line of code to a widely used public launch in about seven weeks. He talks with Lenny Rachitsky about why the team built a completely new product instead of extending Cursor, why they personally onboarded 200 to 300 early users by hand, and the specific technical and product decisions, cloud-only agents, agents with their own computers, that they believe explain why Grok Bot broke out where other knowledge-work AI products have not. This matters to PMs building any AI agent product: the episode is a detailed account of the small decisions that separate a demo from something people actually delegate real work to.

The Big Idea

A small, isolated team building from a blank page, and being willing to unship almost everything they first built, produced an agent product that people trust to finish entire tasks rather than get partway there.

Grok Bot went from first line of code to internal beta in about a month, and from beta to public launch in three more weeks, by deliberately not building on top of Cursor's existing coding-agent surface. Two decisions, that agents live entirely in the cloud and that each agent gets its own computer to operate rather than sharing the user's, are what the team credits for making delegation feel complete instead of partial.

Key Insights

1. Small isolated teams make faster micro-decisions

A handful of people worked separately from the rest of the company, in a distinct part of the office with private Slack channels, for about a month to build Grok Bot from scratch. Roman argues this isolation was not a nice-to-have but the actual mechanism that made speed possible: the team had to make many small, non-obvious decisions every day, and a larger group operating on a six-to-twelve-month roadmap would never have converged on the same product. The lesson generalizes beyond this one company: giving a new, ambiguous product area to a small team with real autonomy, rather than folding it into an existing team's roadmap, can be what actually produces a breakout result.

2. A new product beat bolting a feature onto an old one

• What: the team explicitly considered adding knowledge-work capability inside Cursor (their existing coding product), the same way competitors' new features share one surface with tabs for each new form factor.
• Why it matters: users could feel that a shared surface represented three different visions stitched together rather than one coherent one, and Cursor itself carried baggage (an intimidating, developer-branded interface) for non-technical users.
• Example: Grok Bot was built as a completely separate product where the team controlled every pixel, which let it express one consistent vision of what work should look like instead of inheriting compromises from an existing tool.

3. Manually onboarding 300 users surfaced patterns worth building for

The team spent about two weeks personally onboarding 200 to 300 early users on live calls, including painful early sessions where users got stuck or confused. This close contact let them notice real usage patterns, like users naming one bot their "chief of staff" and having it delegate to four or five other specialized bots, without leading users toward that pattern first. Only after seeing it emerge organically across many users did the team decide to lightly encourage it in the product. The broader principle: watching unscripted usage before designing the guided version of a workflow avoids baking in a pattern nobody actually wanted.

4. Hiding the agent's internal mechanics increased trust

Grok Bot deliberately does not show users the tool calls, chain-of-thought text, or step-by-step clicks its agents make, showing only a Slack-style "active" indicator and periodic updates. Roman compares this to how a human colleague doesn't report every mouse movement to a manager: showing too much internal mechanics felt overwhelming and created more doubt than confidence. Some users asked for a visible to-do list or rough prioritization view, which the team treats as reasonable feedback, but nobody wanted a raw stream of reasoning text, which confirmed the original instinct.

5. Unshipping features mattered as much as shipping them

• What: in the weeks between internal beta and public launch, the team removed a large amount of what they called "jank," including developer-style visibility tools and exposed internal model reasoning that had been useful for debugging but confusing for end users.
• Why it matters: Roman argues AI is good at generating more ideas and more surface area, but bad at telling you what to remove, so cutting features is a distinctly human skill that determines whether a product feels simple or cluttered.
• Example: the team now tests every planned feature against the question "what is the launch tweet," and reframes capabilities as "Grok Bot can now" (an ability) rather than "Grok Bot now has" (a button or menu), which pushed automations to be created by typing a plain-language instruction instead of through a multi-step trigger-and-action interface. That single change is now how 99% of automations on the platform get built.

6. Non-coding tasks lacked reliable APIs, so computer access filled the gap

Sales and recruiting became two of the internal teams that adopted Grok Bot fastest, because tools like Salesforce often have no reliable API or MCP integration, and small failures (a mouse unable to click a specific dashboard element) would previously stall an agent completely. Giving each bot its own computer, the same way a new human hire gets a laptop, let it operate tools built for humans rather than waiting for every tool vendor to ship an API. The team's recruiting workflow, for example, has a bot that autonomously scans conference websites for new co-author names not yet in a company spreadsheet, cross-checks them against current employees, and drafts an introduction request, a task that used to require constant manual sourcing work.

7. Complete delegation feels categorically different from 90% delegation

Roman's now-famous framing is that an AI completing 100% of a task feels different in kind, not just in degree, from one that gets 90% there. If you still have to watch and steer a task while it runs, you have not actually delegated it, no matter how much of the work got automated. He compares it to throwing a "no-look pass" to a trusted colleague versus handing off a task you know you'll have to babysit; only the former actually frees up attention, and it's this complete-handoff feeling, not raw capability, that made Grok Bot's early access users switch away from other AI tools.

Mental Models & Frameworks

"Colleague-pilled" product decisions

When a product debate has good arguments on both sides and no clear internal answer, the team asks: how would a human colleague handle this exact situation? Roman says this question is often surprisingly clarifying and produces near-unanimous agreement, even when the abstract "SaaS product" framing of the same debate does not. It works by removing the layer of software conventions (dashboards, settings screens, notification preferences) and replacing it with the much more familiar frame of managing an actual working relationship. Examples the team built from this lens include giving each bot its own computer (you wouldn't share a laptop with a new hire) and designing a "huddle" voice mode modeled on how coworkers jump onto a quick call instead of typing back and forth.

Cloud-native, computer-owning agents

• Cloud-first: every agent runs persistently in the cloud rather than depending on the user's own machine being awake, so it has the same state whether the user opens it from a phone or a laptop.
• Owns its own computer: each agent gets its own virtual machine to click, type, and navigate with, instead of sharing the user's device and credentials.
• Why it matters: this combination is what lets an agent act on tools that have no API and keep working when the user is offline, which the team believes competitors building on top of existing coding-agent infrastructure were structurally less likely to adopt.

"GrokBot now has" versus "GrokBot can now"

A simple linguistic test the team uses to catch feature bloat: describing a change as "GrokBot now has [a button, a dropdown, an integration]" signals a UI addition, while "GrokBot can now [do a specific task]" signals a capability. The team treats the second framing as the actual goal, and any planned feature that only produces the first kind of sentence is a candidate to cut or to move behind the scenes as something the agent just does rather than something the user configures.

Trade-offs & Nuance

Hiding mechanics helps most users but not all

Grok Bot's choice to hide tool calls and reasoning traces reduced overwhelm for the majority of users, but some early testers explicitly asked for partial visibility, like a to-do list or rough task-priority view. The team's response was to treat that specific, bounded request as legitimate feedback worth building, while holding the line against exposing full raw reasoning streams, which nobody wanted. The nuance is that "hide the mechanics" is not an absolute rule; it is a default that should flex for the narrow visibility users genuinely ask for.

Speed versus process as a company scales

Roman describes watching companies slow down as they grow even while insisting internally that they're "still a startup." He argues a startup is defined less by headcount or funding stage and more by a "scramble energy" that lets people make outsized impact quickly, which is uncomfortable for some people to work in but produces disproportionate results. The trade-off is explicit: that fast, somewhat chaotic mode is not a pleasant environment for everyone, and sustaining it deliberately as headcount grows is presented as a conscious, ongoing choice rather than something that happens naturally.

Common Mistakes

Mistake: Retrofitting new AI capability into an old surface

Roman says the "strong default" for most companies would have been to add knowledge-work features into an existing coding-agent product, because that surface already exists and has users. He argues this path produces a cluttered experience where users can feel they are looking at three different product visions sharing one screen, and that competitors who avoided a from-scratch rebuild may have been constrained less by lack of ideas than by sunk cost in their existing paradigm.

Mistake: Leading witnesses during early user research

The team specifically avoided telling early access users to create a "chief of staff" bot or suggesting the multi-bot delegation pattern outright, because doing so would have made it impossible to tell whether that pattern was something users actually wanted or something the product had planted in their heads. Only after seeing many users independently converge on the same structure did the team decide it was safe to lightly encourage it.

Practical Application

Ask "what is the launch tweet" before building a feature

Before committing engineering time to a planned feature, write the one sentence you would use to announce it. If that sentence isn't something a user would find compelling or directly feel in the product, treat that as a signal to deprioritize or cut the feature rather than build it anyway.

Watch usage before you design the guided path

• Do: roll a new AI or agent feature out to a broad, unbiased set of early users without suggesting the "correct" way to use it.
• Then: look for patterns that emerge independently across many users, not just from your most vocal or expert testers, before deciding what to encourage or build a shortcut for.
• Why it works: a pattern several unrelated users discover on their own is much stronger evidence of real demand than a workflow the product nudged them toward.

Recruit unconventional test users, not just power users

Grok Bot's early access group deliberately included a coffee shop owner with no connection to AI or software, alongside expert power users like Lenny himself. The coffee shop owner's feedback surfaced integration gaps (a flaky Shopify connection, copy generation that didn't fit a small retail business) that the company's internal, Silicon-Valley-heavy dogfooding never would have caught, since most likely users of a general product are not developers.

Reframe every planned addition as a capability, not a UI element

When scoping new work, describe it as "the bot can now do X" rather than "the product now has X." If a proposed change can only be phrased as a new button, menu, or settings toggle, treat that as a prompt to ask whether the capability could instead run automatically in the background without requiring the user to configure anything.

Questions to Consider

• If our AI or automation feature still requires the user to watch and intervene while it runs, are we actually offering complete delegation, or just automating part of a task while leaving the trust-building work to the human?
• Which of our current features would fail the "what is the launch tweet" test, meaning users would not find them compelling enough to mention if we announced them today?
• Have we ever suggested the "correct" way to use a new feature to early testers before letting them discover a pattern themselves, and did that bias what we thought we learned from their feedback?
• Are we recruiting only power users and internal employees for early feedback, or do we have at least one genuinely unconventional tester (a small business owner, a non-technical user) who could surface blind spots our regular testers can't see?
• Is our organization still moving with the "scramble energy" of an early-stage team, or have we started calling ourselves fast while actually slowing down as we've grown?

Bottom Line

Grok Bot's breakout success came less from a single brilliant insight than from being willing to start over with a blank page, hand-onboard hundreds of real users to see how they actually worked, and aggressively unship anything that didn't make delegation feel complete. The two structural bets, agents that live entirely in the cloud and agents that get their own computer, are what let the product cross from "AI chat with some connections" into something people trust to finish whole jobs on their own.

Concepts to Explore

Agentic computer use

Computer use refers to an AI agent directly operating a computer, clicking buttons, filling in forms, and navigating software, the same way a human would, rather than relying only on APIs. This episode frames it as the missing piece that let Grok Bot work with tools like Salesforce that have no reliable API, and as a capability the industry expects to keep improving until "the computer" becomes an invisible implementation detail rather than something users interact with directly.

Moats as discovered, not planned

Roman argues that trying to design a defensible strategic moat in advance, rather than obsessively building something useful today, would not have produced Cursor's success. Instead, he describes a repeated cycle of asking what capability the model landscape will unlock in three to six months, building the product to pull that capability into the present, then deleting the scaffolding once it becomes standard and building the next frontier feature. Distribution and data advantages, in his account, accrued as a side effect of that obsession rather than from a moat-first strategy.

Notable Quotes

"An AI that does 100% of the job feels categorically different from one that gets you 90% there." (Roman Ugarte)

"GrokBot now has" versus "GrokBot can now": "adding things to the product is not the goal... making your bots reliably do really impactful work for you behind the scenes in a way that just works, and giving them the capabilities to do that, that's what users actually care about." (Roman Ugarte)

"If we as a company can't completely reinvent ourselves every six months... we're going to lose." (Roman Ugarte)