Grok Bot shipped in a month: a small team hid in a cave, a big team would have micro-decisioned it to death
Building knowledge work into Cursor is not obviously wrong, but users can smell three visions sharing one screen — that is shipping your org chart. So Grok Bot started from zero, a handful of people hid in a cave for a month.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
Shipping a hit in a month came from a small team hiding in a cave
Grok Bot did not start as a tab added to Cursor. It started as a team of "a handful of people" isolated in a corner of the office with a private Slack channel, going from first line of code to an internally usable prototype in about a month. Roman's judgment: with a big team and a 6-to-12-month vision plan, you would not have built the thing that ultimately shipped — because every day is a pile of non-obvious micro-decisions, and a big team drags those decisions to death.
— Roman UgarteNot putting it in Cursor: users can smell three visions on one screen
Building knowledge work into Cursor is not obviously wrong, and the team discussed it seriously. Roman says the problem with that path is "small paper cuts": the product feels oppressive to non-technical users, plus the brand association. He called out the competitor approach of "a tab for every new form factor" — users can feel that this is not one unified vision of work but three visions sharing one screen, like "shipping your org chart." So they decided to start completely from zero.
— Roman UgarteTwo or three hundred manual onboardings, so tomorrow's mistake never happens again
The team onboarded two or three hundred people by hand, including the host. The first few were painful: the computer wouldn't start, the user was confused, and the core team had to sit on that 20-minute call. Roman says the effect of that presence is "that can never happen again" — it has to be fixed tomorrow, because tomorrow you onboard the next person. The pattern lasted about two weeks.
— Roman UgarteThey deliberately did not tell users what bots to build
Internally, the pattern of "5 to 10 bots each owning a piece" emerged on its own. By the end of the second week, people started promoting a standout bot to primary personal assistant, then making it chief of staff and dispatching tasks to other bots — there was even a screenshot of a user telling a bot it had been promoted, and the bot asking whether that came with a raise and a bigger token budget. The team noticed, but deliberately did not guide it in onboarding, afraid of biasing users; they wanted to see whether outside users would get there on their own. Many did.
— Roman UgarteNot showing the thinking is a product stance, not laziness
Grok Bot hides a lot of internal machinery: no tool calls, no step-by-step view of what it clicks on its own computer, just a Slack-like activity indicator and on-demand stage updates. Roman's analogy: you would not ask a colleague to report second by second which button he pressed and which site he visited. Some feedback did ask for a to-do list and priorities, but nobody wanted long streams of text and chain of thought — which confirmed the direction.
— Roman UgarteThose three weeks of internal beta were mostly unshipping
From internal beta to public launch was only about three weeks, and Roman says that stretch was "we unshipped a lot": cutting experimental features, moving pseudo-developer visibility tools off the product surface, like interfaces exposing the model's internal thinking and specific memories. The test was "what is the launch post" — if it can't be written as a convincing launch tweet, it probably shouldn't be built. He also distinguishes "Grok Bot now has" (new button, new dropdown, new integration) from "Grok Bot can now" (new capability); the latter is the right frame.
— Roman UgarteAutomation should have no UI; 99% is generated from one sentence
Competitors' automation setup means going to the sidebar, clicking plus, picking a trigger event, picking an action. Roman calls that clunky, and the result is that people rarely actually build automations. Grok Bot's approach is to define it in natural language: tell the bot "remind me every morning at 8," and it should just do it — the user should never see the automation-creation UI. Today 99% of automations on the platform are built that way.
— Roman UgarteTwo early decisions: everything in the cloud, every bot has its own computer
Roman credits Grok Bot's success to two decisions that were not obvious at the time. First, users should never have to think about local versus cloud, whether their computer is on, or whether starting from their phone means connecting to a machine at home — all of it in the cloud, with the bot as a persistent colleague that has its own computer and is consistent across every entry point. Second, the bot must have its own computer, because a huge number of tools have no decent MCP or API, and humans never worked through MCP and APIs anyway — they clicked pixels and typed into input boxes.
— Roman UgarteMaking AI colleagues share your computer is the oddity of this era
Roman says this is a strange moment people will look back on: letting these super-smart new colleagues share your one computer. His analogy: if a new hire showed up on day one and you said you don't get your own laptop, just sit next to me, we'll share this computer forever and trip over each other, you'll have my credentials and I'll have yours — nobody would do that. So bots need an onboarding equivalent of "here's your own laptop."
— Roman UgarteOpenClaw proved the models were being used the wrong way
Roman says OpenClaw got two big things right. First, models are already smart and will keep getting smarter, but even at current capability, if you give a bot the tools you use to do your work, it can go very far; a lot of where people think AI is dumb or underdelivers is "harnessed in the wrong way." Second, it pushed the mental model of AI toward a colleague, a teammate, a personified assistant entity. What Grok Bot adds on top: it has to be extremely easy to set up — the VPN-at-home-plus-a-Mac-mini setup obviously cannot scale to millions of users, and is not how enterprises adopt.
— Roman UgarteThe endgame is giving you a team of AI bots
Roman says Grok Bot's endgame is "incredibly simple": you should have a team of AI bots that does work for you and lives for you, and it should really feel like a team — autonomous, steerable, not needing micromanagement, with access to the tools needed to do big things. The product north star: with every product decision, think less like a SaaS product and more like "we are building a useful AI teammate." He offers an operational test: when both sides of a product argument are right, step out of the tech-company context and ask "what would a human teammate do here" — the answer is often clear and unanimous, and all that's left is to build it.
— Roman UgarteThe voice experience to copy is the five-minute huddle
Roman brings up the phrase "colleague pill," saying many product decisions should be pushed toward "like a colleague." The concrete example is voice: in human collaboration it's very common to trade context back and forth on Slack, but simpler is to just open a five-minute huddle, share screens, lay out the ideas, then go offline and continue async. He thinks no AI product has gotten this right, and that it is "deeply integral to the way that I think humans collaborate," so he wants to build something like it.
— Roman UgarteThe power tool of the future has no knobs
Roman says the baggage of bad B2B software over the past decade or two makes people assume a simple product isn't a work tool, isn't a power tool. The previous generation of power tool in his head is Photoshop: a pile of knobs, and the user is a cockpit flyer who knows what every knob does. He thinks the future power tool is completely different — mostly expressing intent plus good human steering, with the AI tool abstracting away all the knobs; unless you genuinely need direct manipulation, you shouldn't see them. So the interface is conversational: walking past a colleague's desk and seeing Grok Bot, his first reaction was "is he using a chat app?" — when that was actually the person's main work tool.
— Roman UgarteWork and life will eventually share one bot
Roman expects many people will want work and personal life separate, which is fine and important, and there are common-sense reasons from the enterprise side too. But the direction he wants to build: Grok Bot handles both the large volume of delegable, low-leverage tasks in your work and the low-leverage parts of your personal life, and these two "actually are not different problem sets" — the product shape and the way you solve them are basically the same. So his instinct is that one product will be the best form for both. The host pressed on how to avoid personal and work content cross-contaminating; Roman did not give an answer in this segment.
— Roman UgarteThe concept of a computer will be abstracted away entirely
Roman uses the teammate analogy to explain computer: when you work with a teammate, the number of times you need to manually take over their computer, click around, and say "you did this wrong, click here" should be close to zero. Likewise, computer use is already decent and improving fast, and soon the concept of a computer will be fully abstracted out of the user's view — you shouldn't click into a remote VM, and you shouldn't need to take it over. In the medium term, computer remains an important concept for users, but not the thing they actually interact with. Grok Bot should be understood as a team of agents doing work for you.
— Roman UgarteEvery bot has its own computer and can run Grok Bot
Roman says these agents have long memories, are not one-off sessions, and get smarter over time; they get the tools a human colleague would have (APIs, MCP), plus a computer they can operate as freely as a person. He mentions that at a meetup, Shub demoed running Grok Bot inside Grok Bot — a bot can run its own Grok Bot, for testing and watching regressions. Roman does this himself: he gave a bot Grok Bot as a QA tester, having it test a new build against ten workflows and write the results into a Notion doc that records every test run for comparison.
— Roman UgarteTreat the bot as an infovore and let it page you proactively
Roman says a simple but deep pattern is treating Grok Bot as an infovore: swallow massive amounts of information, take the cognitive load off you, and push only what matters. The V1 implementation is hooking up Slack and email and telling it your role and focus areas, what should ping you directly, and what goes into a daily roundup. He rates himself at V3 or V4: hooked up to everything on X mentioning Grok Bot, cross-referencing internal context and the QA tester to see whether bugs reproduce, plus his own messaging service for fast feedback responses. Some people have already given their bot page permissions, so when something is urgent it calls them even while they're getting coffee — provided you trust it not to false-alarm. He thinks agents being more proactive than people will be AI's next shift.
— Roman UgarteIn their own words · checked verbatim
we decided to kind of create this very small team internally. It was really just a handful of people uh to go off into a cave for about for about a month with the sole objective of build an amazing knowledge work product that brings agents to the rest of the company.
Roman Ugarte4:05
this was not a single consistent uh vision of the way that work should work and instead it's three different visions that all kind of share a screen and you can hop between but it is kind of a shipping your org chart style thing that I think users are reacting negatively to.
Roman Ugarte10:08
you're onboarding these super intelligent new colleagues, these AI bots and you're asking them to share the same computer that you have. It's crazy.
Roman Ugarte32:20
The ultimate vision of Grockbot is incredibly simple, which is you should have a team of AI bots that help you with your job and help you with your life.
Roman Ugarte39:31
I think power tools of the future will actually be very different from that. Uh where it is mostly just intent being expressed and good steering on the part of the human and these AI tools abstract away all of the knobs.
Roman Ugarte43:33
You're not that's not 90% task completion. You're still doing the thing and it feels that way and it's it's weighing on you in the same way versus like truly throwing a nook pass to a colleague and being like you got this.
Roman Ugarte1:02:56
I've always been a big AI semantic search nerd. I love any SEM search product, especially the kind of out of the ordinary ones.
Roman Ugarte1:20:03
I think we're in the very early innings of this still. I mean, we released a beta 3 weeks ago.
Roman Ugarte1:22:03
Figures
| First line of code to internally usable prototype | about a month | 4:05 |
| Internal beta to public launch | about three weeks | 19:11 |
| Manual onboardings | two or three hundred people | 11:08 |
| Share of automations created via natural language | 99% | 29:17 |
| Roman's self-rated stage of Grok Bot infovore usage | V3 or V4 | 51:42 |
| Time since Grok Bot beta launch | 3 weeks | 1:22:03 |
Glossary
- MCP
- An open protocol that lets AI models connect to external tools and data sources.
- steering
- Directional adjustment of AI output by a human, rather than directly operating every detail.
- infovore
- A pattern of swallowing huge amounts of information and pushing only what matters to the user.
- unshipping
- Removing an already-shipped feature or interface from the product.
How to listen
Founders and PMs building AI products, agents or knowledge-work tools, especially those interested in how small teams validate fast and whether a bot should have its own computer.
The lightning round after 1:18:03 (books, film, mottos) has no product mechanics and can be skipped.