Grok Bot is not just a chat-style AI. Its goal is to build a team of AI colleagues, each with its own computer and long-term memory. Roman Ugarte walks through how a handful of people working as an independent team built an internal prototype in a month and then reached a public launch just three weeks later. He names the keys to that success as a cloud-first architecture, giving every bot its own computer, and a product philosophy of boldly stripping features away.
He also argues that what let Cursor and Grok Bot grow quickly in a brutally competitive AI market was not trying to design a future moat in advance, but a culture of building something people find useful enough to obsess over right now, and continually reinventing itself to match reality.
1. The Vision of an "AI Colleague Team" Beyond Chat AI
The interview opens with Grok Bot's very simple but very big vision. Roman explains that the end goal is for people to have a team made up of multiple AI bots that can help them in both their work and their personal lives.
"The ultimate vision for Grok Bot is incredibly simple. It's to have a team of AI bots that help you with your work and your life."
Host Lenny describes how, just three weeks after launch, a Grok Bot community meetup drew hundreds of people and was standing room only, and says the product is already cutting through the noise of the AI industry and getting an unusual reaction. He himself uses about 15 bots every day and says he quickly moved many tasks he used to handle with Codex or Cowork over to Grok Bot.
"It's really hard to break through the noise in the AI world. But Grok Bot is the hottest AI product right now."
Lenny also shares an early experience that stuck with him. All he typed was "Write a tweet promoting my latest podcast episode," and Grok Bot figured out on its own what the latest episode was and even produced fitting promotional copy. Not having to copy and explain context every single time changed his first impression of the product.
Roman says that, especially for non-development work, it gave him the first real sense that he could truly delegate work to AI.
"It was the experience of handing work to an AI, not having to keep thinking about it in the meantime, and coming back to find the work done."
2. The First Product, Built in a Month by a Small, Isolated Team
Grok Bot was not the result of bolting features onto an existing product; it was a project that started from a nearly blank page. SpaceXAI had experience building products for developers and engineers, but the next question was clear: what should an agent product for all knowledge workers look like?
To answer it, the company carved out a very small group. They literally sat in a different part of the office, worked in a private Slack channel, and for about a month focused on a single goal: building a great AI agent product for knowledge work.
"It was a really small team. We went off into a cave for about a month and focused only on building a great knowledge-work product that would bring agents to the rest of the company."
From the first line of code to a functional prototype usable internally took only about one month. Roman believes this would have been impossible in a large organization. They had to make countless small decisions quickly every day, and many of those decisions could not easily be answered from existing product experience.
A large team would have spent its time on a six- or twelve-month long-term vision and on aligning stakeholders, but because this team was small and independent, it could quickly decide "what to build now and what to throw away."
After the internal release, the reaction was much stronger than expected. Even employees who normally used chat interfaces like ChatGPT started switching to Grok Bot as their main tool for daily work. The team took this reaction as a reality check on the product.
"Of course we'd like it; we built it. But whether people would abandon other internal and external tools and use Grok Bot as their main work tool was a completely different test."
Once they had seen the internal reaction, the team immediately switched to preparing a launch for users around the world. The pace, with a public launch roughly three weeks after the internal beta, shows how small and focused the way they operated was.
3. Why It Became a Separate Product Instead of Living Inside Cursor
One of Grok Bot's most important early choices was not to put knowledge-work features inside Cursor, an already successful development tool, but to start as a completely separate product. At the time this was far from an obvious choice, and there was a lot of internal debate.
Coding agents like Cursor could already be used for non-development work to some extent. But Roman explains that doing so came with many small frictions. The product itself can feel intimidating to non-technical users, and the brand perception of a "coding tool" lingers. If you keep adding more use cases to a single screen and set of tabs, users may feel they are looking not at one coherent product but at several organizations and product strategies forced together.
"If you add another tab every time a new form factor comes along, the product gets complicated. Users can feel like it's not one coherent vision of 'how work should get done,' but three different visions sharing one screen."
He likens this to transferring the company's org chart directly into the product, the so-called problem of "shipping the org chart." So the team decided to avoid the inertia of the existing product and redesign the knowledge-work experience from scratch, in order to control every element on the screen and to create a simple yet powerful experience centered on bots.
In the end, this choice gave them the freedom of a fresh start. They could reference technical components and agent concepts that already existed in the previous product without having to strain to fit an existing paradigm. Roman says many competitors see the same opportunity, but the more existing products, investment, and user expectations have piled up, the more painful it is to build an entirely new product.
4. Why They Personally Onboarded the First 200–300 Users
The Grok Bot team personally onboarded its first 200–300 users over video calls. For a small team, this was a very large investment of time, but Roman sees it not as a distraction from product development but as a core process for making the product succeed.
The early onboarding was not smooth. Sometimes the computer didn't launch properly, or users got confused because they didn't understand the product flow. But because the core team saw that discomfort firsthand, they had a reason to fix the problem by the very next day.
"When a user gets really confused during onboarding, as soon as it's over you think, 'This must never happen again. We're onboarding another user tomorrow, so we have to fix it today.'"
This process, which ran for about two weeks, went beyond finding bugs. The team got to observe how people organized their bots and actually handed off work.
Internally, the pattern that emerged at first was that people generally created 5–10 bots and assigned each one a different area of work, for example splitting separate work lanes such as research, scheduling, content writing, and customer response into different bots. Over time, though, some users promoted a particular personal assistant bot into a "Chief of Staff" role that managed the other bots.
"People promoted their personal assistant bot to chief of staff, and had that chief of staff distribute work to the other bots and manage the team."
There were also amusing cases where, when told about its promotion, a bot asked, "Do I get a raise?" or "Does my token budget go up too?" But the team did not immediately impose this usage pattern as the product's right answer. Teaching users from the start to "build a chief-of-staff bot like this" could block other patterns users might discover for themselves.
Only after confirming that external users arrived at the same pattern without any particular nudging did the team begin to encourage that flow a bit more in the product. This process illustrates an important principle of their product philosophy: don't push internal hypotheses onto users; validate them through real usage.
The early user group also wasn't made up only of AI-industry celebrities or power users. The team brought in people the company had rarely met before, such as a coffee shop owner they knew through a friend. This user gave in-depth feedback on Shopify integration issues and on how product copy was written.
Roman says this experience confirmed that Grok Bot is not a developer-only product but a general-purpose tool that may be even more powerful for non-developers.
"We live inside the Silicon Valley AI bubble. It's a great place for pushing the future forward, but for this product to be useful to the general public and ordinary business customers, we have to deliberately step outside that bubble."
5. Hiding the Internals and Boldly Removing Unnecessary Features
One of the biggest changes in the three weeks between the early beta and the public launch was not adding a flood of new features, but the opposite: removing features and screens, in other words "unshipping."
The early product exposed a lot of developer-friendly information for debugging, such as the model's internal reasoning, stored memories, and observability tools. That was useful for the team building the product, but not really necessary for ordinary users. So the team aggressively separated what users truly needed to see from what they didn't.
Roman uses the example of a person giving work to a colleague. Just as you wouldn't demand a second-by-second report of which buttons your colleague pressed or how many seconds they spent on which website, there's no need to demand such granular execution logs from a bot.
"You don't tell a colleague, 'Let me know every second which button you're pressing and which site you're visiting.' Asking that of a bot is way too much, and it actually becomes a burden."
So in Grok Bot, when a user requests something, the bot starts the work on its own and gives interim updates only when needed. The user just sees an indicator that the bot is active, without peering into every tool call or click. Users wanted to see a rough to-do list or priorities, but they didn't want long reasoning text or detailed execution logs. This confirmed that the team was heading in the right direction.
The team also changed the question it used to evaluate the value of a feature, from "What does Grok Bot now have?" to "What can Grok Bot now do?"
"The traditional software way of putting it is 'Grok Bot now has X,' like a new button, a new dropdown, a new integration. But we're trying to change that to 'What can Grok Bot now do?'"
This difference is substantial. The goal becomes not increasing on-screen elements or settings menus, but giving the bot the capabilities to reliably accomplish more important work on the user's behalf. Roman says, "Let's get rid of as many pixels as possible." Rather than adding interfaces for users to operate directly, the idea is to hide the things the bot can handle behind the scenes.
Automations were designed with the same philosophy. In other products, users have to click a plus button in the sidebar, pick a trigger and an action, and save the settings. Grok Bot chose a direction where simply saying in natural language, "Remind me about this every day at 8 a.m.," creates the automation by itself.
"Users should never have to see an interface for building automations."
In fact, about 99% of automations on the platform are reportedly created this way, through natural language.
6. Two Decisions Behind the Success: The Cloud and Independent Computers
Lenny asks why Grok Bot delivered such an unusually strong experience, given that other AI products could technically do similar things. Roman points to two decisive early choices.
The first was putting the entire execution environment in the cloud. The team made sure users would not have to worry about questions like "Does this task run on my computer?", "Do I need to keep my computer on?", or "If I start from my phone, does it need to be connected to my laptop at home?"
"Users shouldn't think about local versus cloud. They shouldn't have to worry about where a task runs or whether they need to keep their computer on."
A bot that lives in the cloud becomes a persistent colleague, separate from the user's devices. You can start a task from your phone, and eventually the bot can do real work even when you send it a message or call it. Whichever device you connect from, you can carry on with the same state and memory.
The second was giving each bot its own computer. Many work tools don't offer connection methods like APIs or MCP, or if they do, those connections are unreliable. But when people work, they don't call APIs; they look at pixels on a screen, click, type into input fields, and log into websites. So AI bots need those basic abilities too.
Roman asks you to imagine hiring a human colleague and then having them permanently share your laptop.
"It would be strange to tell a new colleague, 'It's your first day, so sit next to me. You don't get your own laptop. We'll keep sharing this laptop from now on. And we'll share our account credentials with each other too.'"
This analogy captures the core of what Grok Bot means by "colleague-like AI." A bot is not just a feature that briefly operates the user's screen, but an entity with its own workspace and permissions that carries out work.
This structure had an especially large impact on sales teams. With tools like Salesforce, which sales teams use heavily but which are hard to automate smoothly through API or MCP connections alone, the bot could operate the screen directly. Every time they fixed a problem that seemed small, like the mouse failing to click a particular button precisely, an entire workflow that had been blocked until then opened up.
"It was far more direct than a dashboard number getting a little better. We'd ship one backend improvement, and the next day the sales team would flood in with 'The task that kept failing all last week finally works.'"
7. Bots With Long-Term Memory and an "Always-On Chief of Staff"
Another core aspect of Grok Bot is that it doesn't treat bots as one-off conversation sessions. In typical AI chat, you open a new conversation for each task and paste in the necessary context again. Roman believes this doesn't fit well with how human work is structured.
Instead, in Grok Bot you create bots according to roles and areas of work. Each bot remembers past interactions and, over time, understands the user's ways of working and context better.
"These aren't individual, one-off sessions. They're long-lived agents, and they get smarter over time."
Each bot has access not only to APIs and MCP but also to its own independent computer. This structure even makes it possible for bots to run bots. Roman describes how he installed Grok Bot inside his QA testing bot, so that every time a new version of the desktop app comes out, it repeatedly tests several core workflows and records the results in a Notion document.
"Once you start thinking of it not as an AI chat window with a bunch of connections attached, but as a colleague with a computer, the ceiling on what you think you can hand off to AI goes up."
Another powerful usage pattern is using Grok Bot as an infovore, an entity that consumes and digests enormous amounts of information. You connect streams of information such as Slack, email, mentions on X, internal QA information, and personal messages to the bot, and ask it to tell you only what really matters.
At first, this might just mean reading Slack and email and sending a daily summary. But Roman says he configured his bot to track every mention of Grok Bot on X, connect with internal context and the QA bot, and reach out to people directly based on the feedback it receives.
"It can become something like an 'always-on chief of staff' that protects the important work I need to focus on while continuously watching for anything that deserves my attention."
Some users even set their bots to call them only when something truly urgent happens. Of course, that only works when you trust the bot enough that there are almost no false alarms. Roman sees the next shift in AI as not users seeking out bots first, but bots approaching people more proactively at the moments they're needed.
8. How to Design a Product From the "Colleague Perspective"
Roman says the Grok Bot team uses the expression "colleague-pilled," meaning deeply immersing themselves in the colleague perspective, when making product decisions. Instead of treating things purely as a SaaS feature-design problem, they ask, "If we were working with a human colleague in this situation, what would we expect?"
"Rather than thinking we're building a SaaS product, we try to think we're building a useful AI colleague."
Inside a product team, there are times when both options seem plausible. He says that in those moments, stepping away from the complex context peculiar to tech companies and thinking about what would be natural for a human colleague to do often makes the answer clear.
"If you ask exactly what you'd want from a human colleague, the answer usually becomes surprisingly clear. Once you have that answer, you just build it."
Voice interfaces are one example. Even while chatting by text in Slack, when people need to get aligned on context quickly, they open a short five-minute huddle and share their screen. They explain quickly by talking, show what's needed, and then go back to working asynchronously when they're done. Roman thinks collaboration with AI needs this kind of natural experience too.
He also says that the powerful tools of the future don't need to take the form of a "cockpit" packed with countless precision controls, like Photoshop in the past. The power tools of the future are likely to be products where the user conveys their intent and steers the direction appropriately, and the AI abstracts away the complex settings and operations on their behalf.
On whether to separate work and personal AI, he thinks some degree of separation is necessary, since both people and companies will want privacy and work context kept apart. But he expects the product form itself may ultimately converge in one coherent direction, because the underlying problem structure is essentially the same in both work and personal life: delegate repetitive, low-leverage tasks so people can focus on more important judgment calls and creative work.
9. From a Personal "Wow" to Core Enterprise Work
Grok Bot's go-to-market strategy draws on the adoption path Cursor experienced in the AI coding market. Early on, individual users and early adopters push the product to its limits and experience big productivity gains on personal projects. Then, back at their companies, they find they can no longer tolerate the old, slow tools and start demanding organizational adoption.
"People who have experienced the future come back to their company and say, 'I can't work the old way anymore. Right now it feels like walking through molasses. This has to change.'"
Roman expects something similar to happen in knowledge work. People may first get a feel for the product's potential through fun personal use cases like managing a robot vacuum at home, negotiating EV charging rates, or organizing everyday information. But the next stage is bots doing work with real economic value inside companies and teams.
Recruiting teams are a representative example. Traditional recruiting automation tends to bring to mind sorting and classifying huge numbers of résumés. But Cursor's recruiting philosophy is more proactive: not just finding people who are currently job hunting, but finding the best talent in the world who can solve the company's important problems and persuading them directly.
Grok Bot can perform ongoing candidate sourcing, such as visiting conference websites every day, downloading new paper PDFs, extracting co-author names, adding people not already on the list to a spreadsheet, and checking whether anyone inside the company is connected to that person so it can request an introduction.
"AI shows superhuman ability at this kind of work. Instead of building giant lists by hand, the recruiting team can focus on talking to and persuading great candidates."
Roman says that for enterprise use cases, you have to go beyond a single personal bot and solve how bots will work within complex company systems, organizational history, and a team's shared context. How memory should work across an entire organization is also still a problem to be solved.
10. SpaceXAI's Three Pillars and Its Pursuit of Practical AI
Roman summarizes SpaceXAI as operating along three broad pillars.
-
Coding products: Professional tools for developers and engineering organizations, such as Cursor and Grok Build. Grok Bot can handle development-adjacent work like merging PRs and QA, but he believes building real production software will continue to require a separate workspace optimized for developers.
-
General knowledge work: Grok Bot is at the heart of this pillar. The goal is to let companies and individuals delegate real work to AI colleagues and use them naturally across many work environments.
-
General-purpose model development: Training world-class models, while emphasizing a practical perspective of building useful AI rather than the race toward vague superintelligence for its own sake.
"Our goal isn't to chase vague superintelligence or abstract ideals, but to build AI that's actually useful."
This direction applies to both the products and the models. Roman explains that a differentiator for the company is that the people involved in model training are also engineering-oriented people who have spent their careers solving applied problems.
11. The Difference Between 90% and 100%, and a Culture That Moves Like a Startup
One line Roman posted on X condenses the core message of this interview.
"An AI that does 100% of the work feels categorically different from an AI that gets you to 90%."
He asks you to imagine handing work to a colleague you can trust 90% of the time. In the end, you keep wondering whether the work will get done properly and have to be ready to step in or make corrections along the way. In reality, that isn't 90% of the work completed; it's a state where you're still carrying the work yourself.
In contrast, a colleague you can hand work to after giving them enough context, saying "I trust you to figure it out," is completely different.
"That's not 90% done. You're still effectively doing the work. On the other hand, if you can give a colleague context and toss it over with 'Handle it,' that's a different category of experience."
What Grok Bot is after is exactly this "no-look pass" experience: a state where you don't have to keep watching after handing off work, and you can trust the result when you come back.
Lenny says he was amazed by the Grok Bot team's speed, such as deciding to hand out free codes the day after receiving feedback, or launching a template marketplace within two days. Roman answers that the secret lies not in the company's size but in the startup sensibility the organization has maintained.
Cursor grew from about 15 employees to more than 1,000 and is now part of the larger SpaceXAI organization. Even so, Roman says the atmosphere where everyone moves fast and deeply trusts each other's ability to execute has been preserved.
"What defines a startup isn't headcount or funding stage. It's that energy: a little chaotic, a little disorganized, but able to create an enormous impact in one direction in a short amount of time."
The core of this culture is a clear vision, high trust, and delegation of authority. Rather than waiting for someone's permission, people are expected to pull in resources and solve problems when they spot something that needs doing.
12. How Cursor Won Amid Competition, and Its Two Core Values
Lenny says that, on the surface, it is remarkable that Cursor survived while going up against giant competitors like OpenAI, Anthropic, and Microsoft. Cursor is a product built on top of model providers, yet it has kept growing in the fiercest part of the AI market, AI coding.
Roman says a large part of the answer lies in culture. The company never thought "we've won," and believed that since AI capabilities change so quickly, the product had to keep being rebuilt too.
"The product that was right for the moment two years ago is completely different from the one that's right for today. If the company can't reinvent itself every six months, and these days on an even shorter cycle, we'll lose."
They also stress that the AI coding market was competitive from the very beginning. In the past, Microsoft and dozens of companies were competitors, but many of them are no longer at the frontier. He believes this is not simply because they lacked resources, but because they couldn't change quickly enough to keep up with shifts in the market and in model capabilities.
There are two core values Roman mentions repeatedly.
Delete the Product
The first is the attitude of "delete the product." When models aren't yet smart enough, you build all sorts of aids and on-screen elements so users can configure and operate things themselves. But as models improve, those aids may no longer be needed. Only by boldly removing them at that point does the product become both simple and powerful.
"If you look back at Cursor in the past and Grok Bot in the future, you'll see that more things disappeared than new features were added."
Just Do the Thing
The second is the value of "just do the thing." It means that when you see something that needs to be done, you solve it without waiting for approval.
"This isn't a culture of asking permission. If you think something needs to be done, you're expected to fix it yourself, pull in whatever resources you need, and get it done."
This principle is the foundation not only for the organization's speed but also for giving people a sense of ownership over the product and the company's outcomes.
13. A Moat Is Discovered, Not Planned
One of the most common concerns among AI founders is a "moat," a durable advantage competitors can't easily replicate. Lenny mentions a user-data feedback loop and an outstanding user experience as Cursor's moats.
But Roman says that if Cursor had started by designing its moat on strategy diagrams from day one, it would have had a hard time producing today's results. Rather than trying to predict the too-distant future, he argues, you should focus on bringing forward to users the things that are impossible today but will become possible in a few months as models advance.
"If we'd reverse-engineered a moat or started from a strategy diagram, this product and these results wouldn't have happened."
Cursor anticipated that models would get smarter in three or six months and tried to deliver that to users early, filling in the current gaps with engineering and product design. As time passed and the models themselves became good at those capabilities by default, they deleted the old compensating mechanisms and moved on to pulling forward the next future problem.
"You have to focus on how to make possible what's impossible today. Users will come to you to do that thing, and along the way, the distribution advantage and the data advantage follow."
Lenny sums this up as "build a product people will obsess over, and don't overthink the moat question up front." Roman agrees, adding that in many cases a moat is discovered rather than planned.
14. How New Users and Power Users Can Get the Most Out of Grok Bot
Roman says he doesn't want to emphasize complicated "hacking tips" or hidden settings. Under the product's philosophy, users shouldn't need to know a pile of secret features and knobs. What they need to do is provide context and hand work to the bots.
For first-time users, his advice is to start by connecting the tools and information a bot needs to succeed, just as a new hire needs access to Slack, email, documents, company records, and so on.
Next, even if it's hard to give the bot work right away, you can first ask it a question like this:
"Look through my Slack and email and suggest five things you could take off my plate, along with what you'd need to handle them."
Roman himself got five suggestions from this question, and two of them were immediately useful, so he created bots to take on that work right away. The important point is that this wasn't simply drafting emails; he could hand off substantial chunks of real work.
For power users, he recommends gathering the outputs of multiple bots in one easy-to-read place. For example, if each bot's results accumulate in a single database or document repository and you create a regular digest you can read daily, you can manage the bots' output much more efficiently.
"Have your bots write their outputs to one place. That makes it much easier to organize and read a large volume of output."
15. Lightning Round and Closing
Finally, Roman names the books he often recommends: Kurt Vonnegut's Cat's Cradle and Steven Pressfield's The War of Art. He says The War of Art in particular is a short book about the resistance that blocks creative work, and it's good for rereading a page or two at a time.
For movies and TV, he picks Casablanca, which he rewatches every year, and Monk, the detective series he watched with his family as a kid. He also has a personal reason for loving Casablanca: it features a character named "Ugarte," the same as his surname.
As the most exciting AI product category, he chose semantic search, and says he especially likes Exa. Unlike ordinary search, he finds great fun in exploring the internet or unusual datasets based on meaning. As something close to a life motto, he mentions the short poem "Desiderata", which he has taped to his door and read every time he's moved since he was a teenager.
At the end of the interview, Roman stresses that Grok Bot is still at a very early stage, and that the feedback users send after launch is feeding directly into real product development.
"We're still really early. The feedback early users send us is directly changing what we build and how we build it."
Ultimately, the core of this conversation is simple. Grok Bot isn't a product that tries to cram more features into AI; it aims to be a product that lets AI do work you can trust and hand off, as you would to a human colleague. To that end, the team is cutting unnecessary screens and settings, giving each bot memory and its own independent computer, and trying to build not a tool the user operates directly but a team of colleagues that carry out work on their own.
