How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)

Roman Ugarte joined me after helping take Grockbot from a tiny internal experiment to a launch that has me hooked. I use a pile of bots every day, and after a standing-room-only community meetup, I wanted to know why this broke through such a noisy AI market.

We started with a blank page: a handful of us spent roughly a month building an agent product for knowledge workers, not developers. Keeping the group tiny and isolated mattered. We made many small, non-obvious calls every day, and a larger team planning a six- to twelve-month roadmap probably would not have landed here.

The internal prototype was a real test. We loved it because we knew the mechanics, but people quickly moved everyday agent tasks from chat tools into Grockbot. That told us to move: about a month to internal beta, then three more weeks to public launch.

One choice jumps out: you did not tuck knowledge work into Cursor. Other companies have moved from coding agents toward broader work surfaces, but you made a separate thing. Was that hard?

Very hard. Coding products handled some non-coding jobs, but came with paper cuts, technical intimidation, and a coding brand. We did not want several product visions sharing tabs—that is basically shipping your org chart. Starting fresh let us own every pixel around one idea: bot-native knowledge work.

We manually onboarded a couple hundred early users in about two weeks. Some calls were rough, which was the point: when someone is confused or a computer fails to start, you feel it firsthand and want it fixed tomorrow. We recruited beyond influential AI people, including a coffee-shop owner whose Shopify and copywriting feedback exposed blind spots we would never find internally.

Internally, people made five to ten bots for separate lanes, then promoted one into a chief-of-staff role that delegated to the others. Naturally, it asked whether the promotion came with a raise. We did not force that pattern on outsiders, but enough found it themselves that it became signal, not company groupthink.

We took a strong position on visibility. I do not need second-by-second detail on every website click from a human teammate, so why demand it from a bot? Grockbot shows it is active and updates you when appropriate, while hiding tool calls and mechanics. People wanted rough priorities, not a giant scrolling stream of reasoning.

Before launch, we unshipped debugging surfaces, exposed memories, and model internals. They helped us build but did not belong in the customer product. The work was making meaningful tasks complete reliably: for sales tools without good APIs, a small browser-control improvement could unlock a workflow that had failed all week.

Our test is: what would the launch post say? “Grockbot now has” often ends in a button or dropdown. “Grockbot can now” asks what capability a person gets. Instead of a routine-builder UI, tell your bot to remind you at eight each morning; nearly all automations are made that way.

I keep coming back to this: other coding or foundation-model products may be technically capable of much of the same work. What made Grockbot feel categorically different?

Two early calls were huge. No one should think about local versus cloud, whether their laptop is awake, or where a workflow runs. A persistent cloud bot has state and can work after you message it from your phone. And every bot needs its own computer. Humans do not work only through APIs; we click pixels, log into tools, and type into boxes.

It is absurd to hire an extremely capable colleague and make them share your laptop forever, with tangled credentials and interruptions. Their own computer lets bots handle work without clean integrations and changes the model from a chat window with connections into a colleague who can use a computer.

OpenClaw made both ideas vivid: current models can go surprisingly far with the tools people use, and users respond to a helper or teammate. We wanted that accessible, without a home machine, VPN, slash commands, or needing to know what a skill is.

The vision is a team of bots helping with work and life, where you steer them without micromanaging. Our colleague-pilled test asks: step away from SaaS conventions—how would you want a human teammate to behave? That clarifies a lot, including interactions that feel like a quick screen-share followed by asynchronous work.

Work and personal contexts will often stay separate, and that is sensible. But the form factor can be one product: express intent, provide context, and hide most knobs. These should be long-lived agents with roles and memory, not disposable chats where you endlessly paste context between threads.

The exciting use cases are always-on. A bot can consume product mentions, internal context, feedback, and QA signals, then return digests or page you only for something urgent. My QA bot runs repeatable workflows on new desktop builds, writes results into Notion, and compares them with prior versions. The ceiling on delegation gets much higher.

The culture is still startup energy: high trust, fast movement, shared direction. We never assume we have won. AI changes quickly, so products must reinvent themselves around what models can do now. I return to two phrases: delete the product—remove scaffolding models no longer need—and just do the thing: pull together what you need and fix it.

Do not over-index on hacky tips. Give Grockbot the context a new teammate needs—email, Slack, company records—then ask it to identify chunks it can take off your plate. For heavier use, make one clear shared home for outputs, so bots can collaborate and their work stays legible.

That is a very good place to leave it. Roman’s picks are Kurt Vonnegut’s Cat’s Cradle and Steven Pressfield’s The War of Art. There is also a yearly Casablanca rewatch for the Ugarte connection, plus Monk’s old San Francisco. Try Grockbot, send feedback, and help shape what comes next. This is very early.