给每个机器人一台电脑：小团队如何一个月做出 Grok Bot

Roman Ugarte, who leads product for Grok Bot at SpaceXAI and earlier led growth at Cursor, says the project began as a blank-page exercise. Having learned how to build useful agents for developers, the company wanted a product for knowledge work more broadly. It formed a very small team and sent it "off into a cave" for about a month with one goal: an amazing knowledge-work product that brings agents to the rest of the company.

The isolation was literal, Ugarte says: a separate part of the office and private Slack channels. He believes that is what allowed the team to move so fast, because it had to make many non-obvious micro-decisions every day. A bigger group thinking in terms of a long-range vision would not have landed where they did.

Once the prototype worked, it was rolled out across the company after an all-hands, which Ugarte describes as a pressure test against reality. People who had used ChatGPT or other chat interfaces daily moved their agentic tasks over to Grok Bot, sometimes from parts of the company the team did not expect. After that reception the team switched into getting it ready to scale to millions of users.

Host Lenny Rachitsky points out that other labs grew knowledge-work features out of their coding agents, and asks why SpaceXAI did not build this into Cursor. Ugarte says the decision was not obvious and was debated at length. People already use Cursor and other coding products for non-coding tasks, but they hit small paper cuts, and the product can feel intimidating to non-technical users.

He also sees a risk in competitors adding a new tab for each form factor, which can feel like "shipping your org chart". Users sense that they are looking at three visions sharing a screen rather than one consistent view of how work should work. A brand-new product let the team control every pixel and keep a single vision of knowledge work.

Lenny notes that Codex went the opposite way and is merging into one thing, so there is more than one path and it is too early to say which is best. For Ugarte, the point is that people should get an amazingly simple and powerful experience, with room later to bring users from other surfaces into the new one.

For about two weeks the core team personally onboarded a couple hundred early users, including Lenny. The first calls were painful, with computers that would not spin up and confused users, and Ugarte says that pain forced fixes immediately because the next onboarding was the next day. The group also wanted to learn how people would really use the product without biasing them.

Inside the company, people had been running five to 10 bots, each scoped to a domain. Around week two, some began promoting a standout bot to "chief of staff" that fanned tasks out to the others, and some users jokingly asked whether their promoted bot would get a raise. The team avoided telling early-access users to create a chief of staff, and when many got there on their own, it added a gently opinionated nudge that is not a one-way door.

The second lesson was how little users wanted to see. Grok Bot hides tool calls, clicks and chain of thought: you send a message, see an activity indicator like Slack's green dot, and get progress updates as the bot sees fit. Users did ask to see a to-do list or how tasks were prioritised, but nobody wanted a long stream of text. The early-access group also included unconventional profiles, such as a coffee shop owner whose Shopify and copywriting feedback differed sharply from what internal dogfooding produced.

The timeline Ugarte gives is roughly a month from first code to the internal beta, three weeks from there to public launch, and about three weeks since launch at the time of recording. During the beta weeks the team's main move was to unship. It had exposed model thinking and stored memories inside the product for debugging, and had to trim aggressively what users truly need to see; he says the team is still working to simplify ruthlessly.

The second push was making the product just work. People want to describe a meaningful task and get back finished work, he says, and delivering that is less about features than about hill-climbing a handful of hard back-end problems. The team collected the tasks users actually gave bots and tracked week over week how well it did on each category.

One example came from the go-to-market team, which relies on sales tools that lack well-supported MCPs or APIs. Bots there needed to see the browser and click precisely on parts of a Salesforce dashboard, so concrete failures went back to the infrastructure team. Each fix unlocked a workflow that had been failing, and the sales team's appreciation arrived the next day.

Ugarte says the recruiting team gave heavy early feedback, and describes one of its uses as always-on sourcing. The hiring philosophy he describes is that being on the market is not a precondition for a hire, so the best workflow is to map a universe of people to a concrete role. One example has a bot visit a conference website each morning, download new PDFs, add unseen author names to a spreadsheet, research them and Slack someone at the company for an introduction.

On product discipline, he says the team asks what the launch post would be for any work on Grok Bot, and if it is not compelling it may not be worth building. He contrasts the old habit of saying Grok Bot now has a button, dropdown or integration with the framing "Grok Bot can now". Adding things to the product is not the goal, he argues; making bots reliably do impactful work and giving them capabilities is.

A good example is automations. Competitors make users open a sidebar, press plus, and pick a trigger and an action, which he says people rarely bother with. In Grok Bot you just tell the bot, for instance, to remind you at 8 a.m. every day, and Ugarte says about 99% of automations on the platform are now built that way.

Asked what is different, since most of it could in principle be done with other coding assistants, Ugarte names two early decisions. The first is that users should never have to think about local versus cloud, whether their laptop must stay awake, or whether a phone task is tethered to a computer at home. Grok Bot runs in the cloud as a persistent colleague with its own computer and the same state everywhere, so you can text it from your phone.

The second is that each bot has its own computer. Humans do not work through MCPs and APIs alone but by clicking and typing, so bots need those baseline capabilities too. He finds it odd that people onboard brilliant AI colleagues and have them share one laptop and one set of credentials, and compares it to telling a new hire to sit next to you and share your machine forever.

Why did others not do this? Ugarte guesses that it is hard to act on market feedback when you are stuck in an existing paradigm with sunk costs, and he stresses that these ideas were not strokes of genius. The primitives had already found fit in products like OpenClaw, which he says got two things right: giving bots the tools you use for your job, and treating them as colleagues. Grok Bot aimed to be easy to set up, since a home VPN and a Mac mini will not scale to millions of users or to businesses, and to hide abstractions like skills.

The ultimate vision, Ugarte says, is simple: a team of AI bots that help with your job and your life, feeling like autonomous teammates you can steer without micromanaging. He describes a recurring tactic the team calls being "colleague-pilled". When a product debate has good arguments on both sides, they step back from the SaaS lens and ask how a human would do it, and the answer is often clear and nearly unanimous.

One example is voice. With a human teammate you might trade Slack messages, then hop on a five-minute huddle where you share screens, and then continue asynchronously. Ugarte says no AI product has gotten that experience right yet, and the team wants to build it. He adds that power tools of the future will be about expressing intent and steering rather than turning many dials, so the interface is conversational.

On whether people will keep separate work and personal assistants, he says many will want a separation, and enterprises have good reasons for it. But he thinks the problems are not different in form factor, and his instinct is that one product will be best for both. Lenny notes that the open question is preventing cross-contamination and making people feel safe.

Ugarte expects the computer concept to be abstracted away from users within a short time, since you should never click into a remote VM or take control from a bot. What matters is that Grok Bot is a team of long-lived agents with a long memory of past interactions, rather than a new chat for each unit of work. He says he is always copying and pasting between chats, and thinks roles or lanes of work that get smarter over time are a better grouping.

Because each agent has a computer, it can do anything a colleague could do on one. He mentions a teammate running Grok Bot inside Grok Bot, and says he does something similar: one of his bots is a QA tester that runs workflows on new builds of the desktop app and compares results against past test notes in Notion. Once you stop thinking of the product as AI chat with connections and see it as a colleague with a computer, he says, the ceiling for what you would delegate goes up.

Another pattern is the bot as an infovore and chief of staff. A first version sits on Slack and email, knows your role, and sends a daily roundup of what matters. Ugarte says he is further along, with a fire hose including every mention of Grok Bot on X. Some people even let the bot page them for urgent issues, which only works if you trust that it does not give false alarms, and he thinks proactive bots will be the next shift.

Lenny praises the team's distribution, from free accounts to use-case templates. Ugarte says the company has culturally cared about not building demoware, and that the go-to-market pattern should echo coding. Early adopters pushed coding tools on nights and weekends around 2023, felt like they were walking through molasses at work, and then demanded the tools there.

He expects the same for knowledge work, with aha moments coming in personal use, from home robot vacuums to negotiating a Tesla charger. The next step, he says, is businesses: bots contributing economically valuable work inside teams. That raises unanswered questions about how a bot works inside complicated company systems and what memory looks like across an organisation rather than for one person.

He lays out three pillars of SpaceXAI. One is coding products, currently Cursor and Grok Build, where every pixel is tuned for professional developers. The second is general knowledge work, where Grok Bot is the step. The third is training the smartest models, with a goal of useful AI rather than chasing a vague notion of superintelligence, which he says reflects a culture of engineers with an applied mindset.

Ugarte's pinned tweet says an AI that does 100% of the job feels categorically different from one that gets 90% of the way. Grok Bot was the first time on non-coding tasks that he could delegate and come back to finished work. If you only 90% trust a teammate, he says, you are still doing the task in your head; with a "no-look pass" you trust the colleague to run with it. He adds that engineers have felt this for a year or more, while most people's AI experience still looks like two years ago.

On the team's speed, which Lenny finds striking, Ugarte says the startup feeling has not changed even as Cursor grew from about 15 people to over 1,000 and then joined SpaceXAI. He defines a startup less by headcount or funding than by a scramble energy, which is not pleasant for everyone but lets you have extreme impact quickly. Many companies tell themselves they are still startups after hypergrowth when they no longer move fast, and he says it is easier to say than to be.

Lenny asks why Cursor survived in the most competitive market, given that it sits on top of models from its biggest rivals. Ugarte calls it a fuzzy answer rooted in culture: never feeling complacent, and a belief that products must meet the moment as capabilities improve. He says that if the company cannot reinvent itself every six months, "we're going to lose", and notes that the early competitors, Microsoft among them, are no longer at the frontier, which he attributes to a cultural inability to move.

He names two values he keeps repeating. The first is deleting the product: removing scaffolding that exists only because models are not yet smart enough, even if it upsets a small set of users. The second is "do the thing", meaning it is not an ask-for-permission culture, so if you see something needed you fix it and pull in resources. Lenny calls that agency.

On moats, Ugarte thinks Cursor would not have succeeded by working backwards from a strategy diagram. It built something useful today and kept asking how to pull next-quarter capabilities forward, then deleted that engineering when models caught up. He advises founders to make the impossible possible, and expects distribution and data advantages to follow; Lenny adds that moats are often discovered, not planned.

His practical tips for new users are to give Grok Bot the context a new hire would need, such as Slack, email and company records, then ask what it can do for you. His first task was to scan Slack and email and suggest five things to take off his plate, and two were helpful enough that he immediately spun up bots for them. Power users, he says, should have bots write to a single legible store, such as a database of daily digests.