Roman Ugarte and Lauren Tan on Grok Bot's AI Coworkers

How the Grok Bot Team Puts AI Coworkers to Work Inside Its Own Company

Roman Ugarte and Lauren Tan are on the core team behind Grok Bot, SpaceXSI's product for creating AI teammates. They incubated it as an internal prototype and took it from the first line of code to launch in about seven weeks. On Y Combinator's Lightcone podcast, with Garry Tan among the hosts, they describe how their own marketing, support, data, sales and engineering teams use the bots, and where the idea of an AI employee still falls short.

Three design principles: Ugarte says the product started from what long-running coding agents had done for engineers and asked what that would look like for everyone else. Work is organized around bots, not chats or files. Each bot gets the tools a person would, including its own computer. And bots are always on, so they come to you with ideas instead of waiting to be prompted. The aim is to work inside the tools a company already has; the team says it is not trying to rebuild B2B SaaS.

What the bots do today: The performance marketing team gave its bot its own Google Ads and Facebook Ads logins and a budget, and told it to work with the design team's bot, which produces the assets, to A/B test them. The support team's bot sits on the incoming tickets and reproduces issues. The sales team shares specialist bots for lead research and the operational parts of a deal, so one expert bot carries the whole team's best practices instead of every rep keeping a private one. The hosts add that some of the most enthusiastic early users are small businesses that can't hire for jobs like bookkeeping.

A three-step trust ladder: Step one is a read-only bot. The data science team kept getting Slack requests for quick analyses before feature launches, so it built a bot with read access to the database that answers them in Slack. A vendor procurement bot started the same way. Step two is a bot that takes actions and finishes a task end to end. Step three is a bot that owns a whole job responsibility or an outcome, and on that the builders are plain: "I think we're still quite far away from those."

Onboard a bot like a person: Asked about identity and permissions, the team says nobody in the industry has a complete answer, and that its shortcut is to ask what you would do for a human: "You hire a person, you give them a computer. You give them access to credentials. You maybe scope those credentials based on their role, maybe how new they are." Access expands as trust builds. Team bots, launched about two weeks before the recording, have an owner and a manager and can take collaborators.

Bots have no feel for the room: With bots in Slack threads and meetings, a new problem shows up. In a thread with several coworkers, "your bot doesn't really know who to listen to. It doesn't have context on who's the domain expert here, who has decision-making power." The team sees this as work to be done at the product, harness and model level. Bot-to-bot conversation is kept explicit: bots have a first-class chat tool, visible in the desktop and mobile apps, and Tan's engineering bot asks the data bot in a Slack thread how many users a bug affects.

A feature built in one Slack thread: Tan, who Ugarte says merges about 4,000 pull requests a month, showed a feature built with a colleague and a PM in a single public thread of about 200 messages. Her bot spawned a Cursor Cloud Agent with its own virtual machine, ran the app and came back with videos and screenshots. She never opened the editor or read the PR. "I've gotten to a point where I essentially have my agents merge their own pull requests." Ugarte notes a side effect of doing this in public: colleagues who watched the thread used the same workflow the next day.

What stays human: A pipeline Tan built takes in thousands of pieces of customer feedback a day. Small bugs are reproduced, fixed and merged automatically, and ship overnight. Anything that changes what users see every day is handled differently. It is dogfooded for longer than feels comfortable, and "the default is if something doesn't get internal product market fit, we don't ship it." Tan points her automation at maintenance, performance and bug fixes, not at new features. The bottleneck has moved accordingly: someone suggests a change in a meeting and a colleague already has a PR for it, so the team's time goes to agreeing on what the product should be.

6 Takeaways From Grok Bot's Builders on AI Coworkers

• Start read-only - A data bot with database read access, living in Slack, built trust before any bot was allowed to act
• Let the domain expert manage the bot - Ugarte compares it to an apprentice managed by the person who knows the problem best
• One bot per concern - He prefers a small team of bots that each care about one thing over a single bot that tracks a hundred
• Share bots across the team - Sales and engineering run shared specialist bots so improvements reach everyone
• Non-engineering work lacks a compiler - Code passes CI or doesn't and its context lives in the repository; in the rest of the company the tests don't exist and the knowledge is in people's heads
• Specify intent carefully - When execution is cheap, "the gap is probably not going to be an execution failure. It will probably be a intent specification failure or a goal failure."

What Grok Bot's Internal Rollout Means for AI Employees

The useful part of this conversation is how modest the working deployments are. The bots that took off inside the company answer data questions, handle procurement requests and triage tickets, all in Slack, under a named human owner. Bots that own a job outright are, by the builders' own account, still far off. For a company planning its first AI teammates, that gives an order of operations: read access first, actions second, ownership last, with a domain expert responsible at each step. The engineering side of the story, including the 0.5% revert rate, is in Lauren Tan's AI Engineer talk.