Four weeks from the first line of code to a working internal product. Three more weeks to public launch. Three weeks after that, standing-room-only meetups and a wave of users migrating their daily work off Cowork and Codex. That's the timeline Roman Ugarte lays out for Grok Bot, the knowledge-work agent from SpaceXAI, and the compression is the point. A handful of people, physically separated from the rest of the company, made hundreds of small product decisions per day that a larger team on a 12-month roadmap would have debated into mush.
Ugarte was employee 15 at Cursor, led growth as it scaled past 1,000 people, and now leads product for Grok Bot. His account of how the product came together turns on a few product decisions that felt strange at the time and obvious in hindsight. Two of them, he argues, explain most of why Grok Bot clicked where technically equivalent products didn't.
The timing matters. Every foundation lab already ships a coding agent, and each has been stretching that agent toward general knowledge work. Anthropic's Cowork and OpenAI's Codex both grew out of coding surfaces. Grok Bot is the counterexample: a knowledge-work agent built from zero, by a team that had a perfectly good coding product it deliberately chose not to extend. Whether that fresh-start approach holds up is the live question for anyone deciding whether to bolt AI onto an existing product or start over.
A cave, a handful of people, and one month to a prototype
The setup was deliberately monastic. A small team sat in a separate part of the office, with private Slack channels, and one objective: build a knowledge-work product that brings agents to the rest of the company. Ugarte says the isolation was deliberate. "It took a small focused group that was completely isolated from the rest of the company. And I mean that literally."
The reason is decision velocity. Grok Bot required daily calls on things the company had never done on other product surfaces, and a big group thinking in six-to-twelve-month horizons "just wouldn't have really gotten to the place that we ended up landing at."
After a month, the team demoed the prototype at an all-hands and asked the whole of SpaceX to use it. This was the first real pressure test, because building a thing and understanding its mechanics makes you a poor judge of whether anyone else will switch. The answer came within a week: people who'd been daily-driving ChatGPT moved their agentic tasks over, and the groups that adopted hardest were ones the team hadn't predicted. Sales. Recruiting. Once the internal signal was clear, the team pivoted immediately to scaling for millions of users and shipped GA three weeks later.
Starting from scratch beat bolting agents onto Cursor
The obvious path would have been to add a knowledge-work mode to Cursor. People already used Cursor and other coding agents for non-coding tasks. The team debated it seriously, and Ugarte says the decision "was not obvious at all."
What tipped it was watching competitors add new tabs for each new form factor. The result, in his description, is a surface where three different visions of how work should happen share one screen. Users can hop between them but can feel the seams. He calls it a "shipping your org chart" problem. Coding agents also carry brand associations and interface paper cuts that intimidate non-technical users, and no amount of retrofitting removes those.
So they started blank. Controlling every pixel let the team hold one consistent thesis about knowledge work rather than negotiating with the constraints of an existing product.
The underlying primitives weren't new to the company, Ugarte says. Cloud infrastructure for agents, named agents you address as discrete entities in Slack, persistent runtimes: all of that had been built before in some form. The difference was refusing to inherit the packaging. "If you have a lot of sunk cost in that existing paradigm, it's very painful to create a new thing from scratch." He credits that pain as the main reason competitors who saw the same market signal didn't act on it.
Three hundred hand-onboarded users and a chief of staff nobody was told to build
Before launch, the core team personally onboarded somewhere between 200 and 300 early-access users over about two weeks. Each session was a 20-minute call. Some went badly: a computer that wouldn't spin up, a user who sat there confused. Ugarte frames those failures as the whole value. When the person building the product watches an onboarding fall apart, "that can never happen again" becomes the next morning's priority, because the next onboarding is tomorrow.
The early-access group was intentionally broader than influential power users. One of the most productive testers was a coffee shop owner, a friend of a friend, who became both a heavy user and a steady source of bug reports and feature requests around Shopify integration and product copy. That's a use case a company of developers dogfooding internally would never surface. Ugarte's framing: the team lives in "this kind of Silicon Valley AI bubble," and a product meant for mainstream business users has to get out of it on purpose.
The onboardings were also a control group for internal hypotheses.
Inside the company, a pattern had emerged around the end of week two. People started with five to ten bots, each scoped to a lane of work. Then screenshots started appearing in Slack of people "promoting" their best-performing bot to chief of staff, talking mostly to that one bot, and letting it fan tasks out to the rest. (The promoted bots reportedly asked whether they'd get a raise or a bigger token budget.) The team liked the pattern but didn't want to "lead the witness," so they withheld it from onboarding scripts to see whether outside users would arrive there on their own. Many did. Only then did the product start nudging toward it, and even now it isn't a one-way door.
A second hypothesis tested the same way: how much of the machinery users want to see. Grok Bot shows almost none of it. You send a message, the bot starts working, and you see a typing indicator and progressive updates it chooses to send. No tool-call stream. No chain of thought. The analogy is a human teammate: you wouldn't ask for second-by-second reports of every button they press. Feedback confirmed the direction. Users asked to see their bot's to-do list and rough prioritization, but nobody asked for the long stream of text.
Two unobvious bets: a cloud runtime and a laptop for every bot
Why did Grok Bot succeed when the same tasks are technically possible in Codex or Cowork? Ugarte names two early decisions.
The first is that users should never think about local versus cloud. Does my laptop need to be awake? If I kick a task off from my phone, is it tethered to a machine at home? Ugarte calls this "so much jank" in current products, and the team's answer was to put everything in the cloud from day one. A bot with its own persistent runtime has the same state on every surface you touch it from, which means you can text it, launch work from your phone, and eventually call it. "This is its own entity and it lives separately from your device."
The second goes further: each bot gets its own computer. Part of the rationale is practical. Humans don't do their jobs through MCPs and APIs; they click on pixels and type into input boxes, and a large share of real business tools have no well-supported programmatic interface. Grok Bot's sales team was among the most enthusiastic internal adopters for exactly this reason, because their tools had blocked every previous AI attempt. The team maintained a list of 10 to 20 concrete failures, like a mouse lacking fine enough control to hit the right spot on a Salesforce dashboard, and worked through them one by one on the infrastructure side. Each fix produced the next day's flood of thanks from sales. That, Ugarte says, was more useful than watching a dashboard metric creep up.
The other part of the rationale is the analogy that runs through his entire product philosophy:
"If you were onboarding someone to your team and you said, 'It's your first day. You don't have your own laptop. You're going to sit next to me. We're going to share this laptop forever and constantly trip over each other. You're going to have access to my credentials.' There's a good reason why that's not the way people operate."
He expects the industry to look back on the shared-computer era of AI assistants as strange. His guess about why competitors didn't make the same call is the same sunk-cost argument: they were extending coding assistants, and this was a big architectural shift away from that base.
Ugarte credits OpenClaw with proving two things the team built on. First, current models given access to the tools you actually use get much farther than people expect; a lot of what looks like AI being dumb is AI being harnessed badly. Second, treating bots as named colleagues rather than chat threads changes what people think to delegate. What Grok Bot added was setup that doesn't require a Mac mini and a home VPN, and the removal of power-user abstractions. A Grok Bot user should never need to know what a skill is or type a slash command.
Unshipping is the roadmap
The three weeks between internal beta and public launch were mostly spent removing things.
Two weeks out, the product still exposed model reasoning, stored memories, and other observability tooling the team had bolted in because they didn't want to context-switch to a separate debugging pane. All of it had to go. Ugarte describes the current mandate as "how can we just ruthlessly simplify this product and abstract away anything the user doesn't need to actively be thinking about," and says there's still room to run.
Two internal tests govern what ships. The first is the launch tweet: if you can't write a compelling one for a feature, maybe don't build it. The second is grammatical. Old-school software announces "Grok Bot now has," and the sentence completes with a button, a dropdown, or an integration. The team reframes every feature as "Grok Bot can now," which forces the question of what capability the bot gains rather than what pixels the product gains.
Automations are the cleanest example. Competitors make you open a sidebar, press plus, pick a trigger, pick an action, and describe it. Grok Bot has no such interface. You tell your bot "remind me at 8 a.m. every day" and it does. Ugarte says 99 percent of automations on the platform are now created that way.
The same logic explains why the second launch push was almost entirely backend. What users want is to describe a meaningful task and get complete work back. Delivering that meant hill-climbing on five hard infrastructure problems, tracked week over week against a collected set of real tasks, rather than shipping visible features.
Colleague-pilled: the tiebreaker for every product debate
The team has a word for its north star: colleague-pilled. When a product debate has reasonable arguments on both sides, they step out of "the tech-companiness of it all" and ask what you'd want from a human teammate in the same situation. Ugarte says the answer is usually clarifying and close to unanimous. Then it's just a matter of building it.
One illustration: voice. Humans slack back and forth, hit a wall, and jump on a five-minute huddle with screen sharing before going back to async. No AI product does that well, and the team is building toward it because the human pattern already exists.
The framework also settles the work-versus-personal question. Ugarte expects many people to keep separate bots for the two, and thinks enterprises will have legitimate reasons to demand it. But he argues the underlying problem is identical: delegate the low-leverage parts of your job, then delegate the low-leverage parts of your life. Same form factor, same solution. One product is his bet. Lenny's rejoinder about cross-contamination and exfiltration went unanswered in detail; the safety story is a stated goal rather than a described mechanism.
Colleague-pilled thinking also reshapes the memory model. The chat-per-task paradigm forces constant copy-pasting between threads. Teams organize work by role. So Grok Bot's bots are long-lived, scoped to a lane, and meant to learn over time. Ugarte's own setup includes a QA-tester bot that runs Grok Bot inside its own computer, executes ten regression workflows against each desktop build, and writes results to a Notion doc comparing against prior versions. His broader point: once the mental model shifts from "AI chat with connections" to "a colleague with a computer," the ceiling on what you'd think to delegate rises.
The recruiting team's use case shows the ceiling. SpaceX's hiring philosophy, per Adam Ward, starts from the biggest unowned problem and works backward to the best person in the world for it, whether or not they're looking. The bot version: every morning, visit a conference site, download any new paper PDFs that aren't on Google Scholar, extract co-author names not already tracked, research them, check whether anyone at SpaceX is connected, and Slack that person asking for an intro. Ugarte calls it "the type of thing AI is superhuman at." Recruiters get their time back for the conversations that close.
His own heaviest use is what he calls the infovore pattern: a bot that ingests Slack, email, every mention of Grok Bot on X, and internal context, then decides what warrants a direct ping versus a daily digest. Some users have given their bots permission to page them for genuine emergencies. He expects proactive bots, ones that reach out to you rather than waiting, to be the next shift.
What Cursor's survival teaches about moats and reinvention
Ugarte's diagnosis of why Cursor kept winning against OpenAI and Anthropic, while sitting on top of their models, comes down to a refusal to believe it had won. The company has reinvented its priorities and core product roughly every six months, recently faster. AI coding was crowded from the start, he says, with Microsoft and a dozen others in the race, and none of those early competitors lead today. The cause, in his reading, wasn't wrong decisions or missing resources but "this cultural inability to move quickly and to change to meet the moment."
Two values encode this. Deleting the product means expecting every past iteration to be recognizable mainly by what got removed: scaffolding built because models weren't yet smart enough, then torn out when they were, even if a few users or engineers object. Just do the thing means nobody asks permission; if you see what needs to happen, you pull the resources and do it.
On moats, his advice is blunt. Working backward from a strategy diagram wouldn't have produced Cursor. What produced it was a loop: look three to six months ahead, identify what models will soon make solvable, pull it forward with engineering effort today, and then delete that scaffolding when the capability becomes table stakes. Users trust the product that keeps dragging them to the next frontier, and distribution and data advantages accrue as a byproduct. Moats, as Lenny summarized it, are discovered rather than planned.
The organizational corollary is the startup feeling. Ugarte defines a startup by "scramble energy" rather than headcount or funding round, admits it's an unpleasant environment for many people, and argues it's the property that allows extreme impact in a short window. He says it has survived the growth from 15 to over 1,000 to inside SpaceXAI, with fingers crossed that it continues.
How to start, if you're downloading it today
Ugarte declines to offer hacky pro tips, since the team's philosophy is that knobs shouldn't exist. His advice for a new user mirrors onboarding a hire: give the bot access to Slack, email, and the records you use daily, then ask it what it can take off your plate. His own first prompt, before onboarding screens existed, was exactly that. It suggested five things; two were real chunks of work rather than "draft an email," and he spun off two bots on the spot.
For power users, his suggestion is structural: give your bots a single store to write into, so digests and artifacts land somewhere legible rather than scattered across conversations.
The through-line of all of it is the tweet Lenny brought up: "An AI that does 100% of the job feels categorically different from one that gets you 90% there." A teammate you trust 90 percent is one you're still thinking about while they work, which means you're still doing the task. The no-look pass, where you hand over context and stop thinking about it, is a different category. Ugarte says engineers have felt that for a year and a half. Grok Bot is his bet that the rest of the company is about to.
