GrokBot Product Lead Retrospective: Building GrokBot in a Month, from a Chatbox to an ‘AI Colleague with Its Own Computer’

Handing a task to AI and seeing it finish 90% quickly sounds impressive. Yet the remaining 10% often consumes the most human effort: fact-checking, repeated course corrections, filling gaps, and moving the result into the software where the work will actually be used. As long as you never dare walk away, the task has not truly been handed off—the AI has simply returned the work to you in a different form.

This is precisely the problem GrokBot aims to solve. Roman Ugarte sees the gap between “finishing 90%” and “finishing the entire task” as a qualitative leap: the former still demands continuous human supervision, while the latter creates the feeling of handing responsibility to a colleague. Instead of building a more powerful chatbox, the team designed GrokBot as an enduring, always-on knowledge-work Agent—one that retains context, runs persistently in the cloud, and can use its own computer to complete tasks across different applications.

Roman previously led growth at Cursor, then helped incubate GrokBot and took responsibility for its product direction. In this retrospective on Lenny’s Podcast, he explains how a team of just a few people went from the first line of code to an internally useful prototype in about four weeks, then spent roughly three weeks in internal beta before reaching public launch. Building GrokBot “in a month” does not mean a mature product sprang into existence overnight; it means the team validated its most important product hypothesis in an exceptionally short window.

The questions worth asking are: Why didn’t they simply put a general-purpose Agent inside Cursor? Why did they insist that every Bot have access to its own cloud computer? And how did a working prototype evolve through real work, feature cuts, and reliability fixes into an “AI colleague” capable of delivering completed tasks? These choices are the most reusable lessons in GrokBot’s origin story.

Treat the Agent as a “colleague with a computer,” not a “chatbox with plugins”

Roman believes most people still understand an Agent as a “chatbot plus a few external connections (API/MCP)”: you ask it a question, it calls search or a specific enterprise-software interface, then returns an answer.

From the outset, the GrokBot team used a framing they called “Colleague-pilled” as a product anchor: If we treat AI as a new colleague hired into the real world, how would we actually work with it?

Following that logic, the team made two critical architectural decisions:

1. Run entirely in the cloud and retain state

During its early exploration, the team drew important inspiration from OpenClaw. Roman said OpenClaw got two crucial things right: it gave powerful models more realistic access to system tools, and it helped shift the mental model for AI from a “chat conversation” to a “colleague you work with.” GrokBot borrowed heavily from those ideas and tried to productize the underlying primitives so they required less setup. The friction Roman described included questions such as whether the Agent runs locally or in the cloud, whether the computer needs to stay awake, and whether a task started from a phone still depends on a computer back at home.

GrokBot chose to have every Agent live in the cloud. Each Bot is a long-lived entity with continuous memory of its interactions, not an ephemeral session that forgets everything when a new chat begins. Whether a user sends a message from a phone or schedules a long-running task from a computer, the Bot continues working quietly in the background with the same state.

2. Let every Bot use its own cloud computer (Computer Use)

This is the product’s central—and most controversial—technical decision. Many technical teams prefer to connect external tools through APIs or the Model Context Protocol (MCP), but real work presents two major obstacles:

• Many critical business tools do not have usable APIs: Roman cited tools used by sales teams and Salesforce dashboards. Even when some interfaces exist, they may not cover the actual workflow.
• The absurdity of sharing a screen: Roman offered a vivid analogy. If a human colleague joined your company, you would never tell them, “You don’t get your own computer. Sit next to me, share this laptop and this set of credentials with me, and fight over clicks on the same screen.”

The team did not disclose a specific runtime-instance topology in the interview, but Roman confirmed that these long-lived Bots can use their own cloud computers (“access to its own computer”). That means a Bot can try to interact with websites and desktop applications as a human would: recognizing pixels, moving the cursor, and typing into fields. When it encounters a legacy system or complex website without an API, the Bot has another way to move the process forward through the graphical interface instead of being entirely blocked by the missing interface.

More importantly, the GrokBot team believes the underlying computer operation should eventually become completely invisible to the user. The user should not have to take over a remote desktop. The AI only needs to report its progress; “using the computer” is simply how it gets the work done underneath.

The interview did not disclose the resource-isolation model, cost, or idle policy for each Bot. What it confirms, therefore, is the product abstraction that “a Bot can use its own computer,” not an infrastructure topology from which those details can be estimated.

Why start fresh outside Cursor, and how was GrokBot built in a month?

Before GrokBot was incubated, the team’s core product was Cursor, an AI code editor that had already built a strong reputation among programmers. Cursor had roughly 15 employees when Roman joined and later grew to more than 1,000 before being acquired by SpaceX. In the interview, the host contrasted GrokBot’s choice with another product path: put several kinds of Agent in one interface, add a tab for every new task format, and eventually make the product feel crowded.

The Cursor team debated the question intensely. Programmers often use Cursor for non-coding work too, so wouldn’t extending the existing product be the path of least resistance?

They ultimately chose to build an independent product from scratch to avoid what Roman described as “shipping your org chart”:

• Cognitive barriers and mental baggage: Coding tools are crowded with terminals, file trees, and debugging panels, which can naturally discourage non-technical users. Forcing a “non-coding workspace” into a coding tool would not only make the interface cluttered and bloated; it would also leave users feeling that several different product visions had been forced to share one screen.
• Control over the whole product experience: Building a convincing “colleague” experience for general knowledge work required ground-up control over every pixel and every interaction flow.

To avoid the long planning cycles common in large companies, the team formed a tiny closed group of only a few people, moved to a physically separate part of the office, and used private Slack channels. Relative isolation allowed them to make a stream of micro decisions quickly. Roman believes that if a larger group had tried to pursue a grand six-to-twelve-month vision, they probably would not have reached the result they did.

That leads to a crucial fact about the development cadence: the project followed a clear three-stage timeline (all figures from the interview are approximate):

• Stage one (about one month): From the first line of code to the first internally useful prototype (“functional, useful prototype”). Here, “one month” means a minimum useful version that could complete the key path internally, not a mature public product.
• Stage two (about three weeks): From Internal Beta to Public Launch, with the team concentrating on critical system problems.
• Stage three (about three weeks): At the time of the recording, roughly three more weeks had passed since the public launch, and the product was still evolving at a very early stage.

The team first introduced GrokBot at an all-hands meeting and treated the rollout as a reality check. During the first week, colleagues from unexpected parts of the company moved day-to-day Agent tasks they had previously done in ChatGPT or other chat interfaces into GrokBot. Once the team saw real work moving across departments, it immediately shifted into preparing the product for public launch.

Organizational support: Why could a small team produce a prototype in four weeks?

In Roman’s view, producing a prototype within a month depended on more than isolation. It also relied on a particular culture of speed:

• High trust and shared direction: Team members agreed on the direction and deeply trusted one another to execute independently and deliver results.
• Protect the startup feeling: Even as the company grew, the team deliberately preserved a startup atmosphere—slightly chaotic, but able to create real impact extremely quickly.
• Two core principles: One was “deleting the product”—being willing to unship or remove unnecessary features. The other was “just do the thing”: when team members saw something that needed to be done or fixed, they did not wait for layers of approval. They took ownership, fixed it quickly, and pulled in the resources they needed. Roman presented these as the organizational conditions that let a small team stay unusually agile in its early stage, not as universal management rules.

From internal prototype to public launch: Why did the next three weeks focus on “unshipping”?

As the product rolled out inside the company and moved into targeted external testing, the team’s biggest problem was not “too few features,” but “too many features.”

During the roughly three weeks before public launch, the product went through an intensive process of unshipping features:

1. Remove engineer-oriented “transparency tools”

Early in the internal beta, the interface exposed debugging information such as the model’s internal reasoning, memory, and tool calls so the team could diagnose problems.

Those details gave developers a feeling of control, but they created serious cognitive overload in general knowledge work. You would not ask a real colleague to report every three seconds which button they had clicked or what thought had just crossed their mind; people do not need to stare at a scrolling text stream in the interface either. The team did receive feedback from some users who wanted to see the Bot’s to-do list and rough priorities, but nobody asked for a long stream of text or chain-of-thought. The team ultimately simplified the interface dramatically: after a Bot receives a task, the user mainly sees a Slack-like typing indicator and green active dot. The Bot sends progress updates when appropriate, then presents the result when it is done.

2. Shift from “what buttons did we add?” to “what can the Bot do?”

Traditional SaaS software is preoccupied with displaying “features” in the interface: settings in the sidebar, workflow builders, multi-select dropdowns, and so on. In the Agent era, however, every complex control added to the interface can mean handing people a burden that the AI should have absorbed.

Configuring an automation is a representative example:

• Many tools present a complex workflow canvas: click New, choose a trigger, choose an action, and configure a timer. The interaction is so cumbersome that ordinary users rarely set up automations.
• GrokBot removed the automation configuration page and let users define automations in natural language: “Remind me every morning at 8.” The Bot manages the scheduling logic in the background. According to Roman, 99% of automations on the platform are created through this kind of natural-language conversation. This is a platform figure stated by the interviewee, not an independent third-party audit. That restraint around unnecessary controls became two reusable questions inside the team:
• “What is the launch post for this work?” The team asks what it would actually tell users. If it cannot articulate a compelling value that users will directly feel, perhaps the work should not be done.
• Can “Grok Bot now has…” be rewritten as “Grok Bot can now…”? This moves scrutiny away from a new button, dropdown, or integration entry point and back toward the new task the Bot can execute, pushing the team to remove every unnecessary pixel it can.

The real work of the three-week beta: not only cutting features, but measuring and fixing system failures

During the roughly three weeks of internal beta before public launch, the team did much more than simplify the interface or remove experimental features. Roman said the Bot still suffered many basic failures: it would miss a target button or get stuck at a system login and be unable to proceed. The team focused on real users’ concrete tasks, collected the tasks and failure categories, measured them, and improved them week over week. During those three weeks, the engineering team concentrated on roughly five critical backend problems. Even then, the system could not reliably take over every complex process; many underlying limits still required human fallback and continued improvement.

Put the product into real work: What did the team actually validate?

In the roughly two weeks before public launch, the team took an unusually hands-on step: members of the core team personally provided one-on-one manual onboarding for hundreds of early users (the host estimated about 200 to 300 people). This was more than a headline number; it formed a tight, high-frequency feedback loop. During early 20-minute coaching calls, the cloud computer sometimes failed to start, or the user stared at the interface with no idea how to begin. The team’s rule was: “A problem found today must be fixed before tomorrow’s next onboarding.” It also deliberately recruited non-technical users far outside the Silicon Valley technology bubble, including an independent coffee-shop owner, to test whether GrokBot truly worked as a general knowledge-work product rather than a toy only for technical enthusiasts.

Several durable patterns of use emerged from those high-density interactions:

1. The “Chief of Staff” collaboration pattern

During the first week or two after the internal rollout, a common pattern was for each person to create five to ten Bots, each responsible for a different area of work.

By the end of the second week, the team saw some users select one standout Bot as a “Chief of Staff.” They would mainly speak to that Bot, which would fan tasks out to the others. Some users arrived at this pattern on their own; it was not the norm for most people or an irreversible fixed hierarchy. The team only considered lightly encouraging the pattern in the product.

2. Proactive talent sourcing

In recruiting, the company’s team believed the best candidates were often not actively applying for jobs; they had to be found proactively.

An internal recruiting Bot demonstrated one exploratory workflow: visit the websites of frontier academic conferences and download new PDF papers not yet indexed by Google Scholar; extract the authors’ names and add new names to a spreadsheet; check whether anyone inside the company had a direct connection to them; and, if so, send that colleague a Slack message requesting an introduction. The chain showed the exploratory potential of combining a cloud computer with a long-running Agent to connect non-standard websites, document extraction, and internal collaboration.

3. Sales and non-standard enterprise systems

Salespeople often have to work with tools and enterprise dashboards that lack usable APIs. During the beta, a Bot could fail because its mouse could not precisely click the target on a Salesforce dashboard, or because it could not log in. The team tried to improve the Bot’s ability to operate these interfaces by improving underlying browser visibility, pixel visibility, and mouse control. Roman stressed that these interactions still failed at the time and needed further work; the Bot had not reached the point where it could reliably take over every system.

4. A personal experiment in recursive testing (Bot in Bot)

Internal testing also produced some highly technical personal use cases. Roman, for example, downloaded and installed the GrokBot desktop app inside his own cloud-computer environment. He created a QA tester Bot to run ten critical workflows whose improvement he wanted to track from release to release, record the results in Notion, and compare them with past client versions. This was Roman’s personal experiment, not a fixed QA process that the team had institutionalized across the organization.

5. From passive summaries to proactive alerts with explicit boundaries

A basic usage pattern treats the Agent as a passive information organizer that sends periodic summaries. A more advanced direction is to connect the Bot to streams such as email and instant messaging, then define clear trigger boundaries: remain silent most of the time, and page or alert the user only in a very small set of urgent situations defined in advance. This pattern depends on the user trusting the Bot not to generate frequent false positives.

Advanced collaboration: Unified output and a Daily Digest

Roman also described a second layer of collaboration for advanced users. Bots responsible for different domains can coordinate by writing their output to one shared, human-readable database or store, such as Notion or a common spreadsheet. Instead of checking every Bot conversation separately, the user can read one consolidated Daily Digest and make decisions from there.

Evolution: From a personal information loop to the unresolved challenge of enterprise adoption

Roman distinguished between a common user pattern and his own personal setup. In the V1 pattern used by many people, a Bot monitors Slack and email, immediately surfaces high-priority items, and puts the rest in a daily summary. Roman described his own setup as roughly V3 or V4: it ingests mentions of GrokBot on X, combines them with internal context, works with a QA tester to reproduce bugs, and uses his own messaging channels to respond to feedback quickly. The added value lies in the chain from “external signal → internal context → QA reproduction → response.”

Moving from personal exploration toward enterprise use, Roman looked back at how AI coding tools spread. Early users first experienced the value on personal projects at night and on weekends, then returned to work and demanded access to the same tools. He expects knowledge-work Agents to follow a similar path: create an aha moment in a personal setting, then enter teams and contribute economically valuable work.

Roman also emphasized that many questions remain unanswered when Agents enter complex enterprises: How does a Bot enter complex company systems and understand the company’s context and history? How does it work inside a larger team? What should organizational memory look like?

Where do moats come from? Build capabilities from three to six months in the future

One of the most anxiety-inducing questions for founders and investors in today’s AI market is: “If foundation-model vendors such as OpenAI and Anthropic put these capabilities directly into their next generation of models, where is the moat for an application-layer product?”

Roman’s answer was not to work backward from a strategy diagram projected twelve to twenty-four months into the future, but to focus on building something genuinely useful today. Lenny then summarized the idea this way: first build a product people become obsessed with; moats are often discovered in that process rather than planned in advance.

Across the past few years, the team developed a cadence that resembles a time machine:

1. Anticipate the trend: Estimate which things that are impossible today will become possible in three to six months as models improve.
2. Pull the future forward: Do not only wait for the foundation model to mature. Build engineering scaffolding on top of today’s models to put that future experience in users’ hands early.
3. Delete the scaffolding decisively: When the underlying model can perform the task natively, remove the scaffolding that is no longer necessary and make the capability part of the product’s baseline. Then move to the next difficult frontier.

This also explains Roman’s view that the team needs to significantly reshape its priorities and core product roughly every six months—and, recently, on an even shorter cycle. When model capabilities and user behavior are both moving quickly, a product boundary that makes sense today may not last.

Roman believes the central logic of this fast cycle of self-disruption and willingness to delete code is not to wait passively for foundation models to improve. It is to use engineering to deliver future capabilities early. In the process, the team may build first-mover advantages in users’ daily habits, data feedback, and distribution rather than relying on a static strategy diagram and merely asserting that it has an unassailable moat.

How to get started: Hand off one well-bounded task first

For readers who want to move beyond one-off conversations and begin building a long-lived Agent assistant, the interview offers concrete starting points:

1. Provide real context as you would for a new employee, but keep firm safety boundaries Do not expect a model floating in a vacuum to take work off your plate. The first step is often to connect the Bot to the important channels used in daily work, such as work email, team messaging, and a knowledge base. Roman believes many people will want personal and company work to remain separate, and he acknowledged that organizational memory and collaboration among multiple Bots inside real, complex teams still raise many unanswered questions. Lenny then raised the risks of personal and work data becoming mixed (“cross-contamination”) and company data leaking out (“exfiltration”). Based on those risks, this article recommends starting with least privilege and separating personal from work data, preferring access that can be revoked at any time, and requiring human confirmation for external sending or high-risk actions.

2. Break the cold-start problem by asking the Bot what it can do A common reaction to a new Agent interface is, “I don’t know what to ask it to do.” Roman’s own approach was to let the Bot review his email and Slack, then ask it to suggest five things it could take off his plate and what it would need in order to do each one (“Suggest like five things that you can take off of my plate and what it would take for you to do that”).

   For a practical first attempt, that idea can be turned into a more explicit prompt:

   “Review my recent email and day-to-day communications. Based on my role, proactively list five concrete chunks of work you could take off my plate, and tell me what system access or permissions you would need for each one.”

   In Roman’s experiment, two of the five suggestions were genuinely useful, so he created one Bot for each of those two tasks. A safer starting point for readers is to choose one or two well-bounded tasks with verifiable results rather than handing over all of their work at once.

AI Agents are moving from text generation inside a chatbox toward persistent digital collaborators that work through cloud computers—a shift in emphasis from flashy demos to practical usefulness. But the limits remain important. As Roman emphasized at the end of the interview, this wave of Agent experimentation is still in its “very early innings.” It is nowhere near mature enough for people to delegate with their eyes closed and give up oversight entirely. A more realistic path is to hand off repetitive, well-defined work gradually, within clear boundaries and with verification, while exploring new ways of working through continued human-AI collaboration.