Grok Bot’s team: give agents checks before giving them autonomy

Lauren Tan and Roman Ugarte say their team took Grok Bot from an internal prototype to launch in seven weeks. The product is organized around persistent bots with identities, tools and responsibilities rather than only chats or files.

Ugarte says the team wanted non-engineers to benefit from the shift that long-running coding agents had already brought to engineering. Bots should be able to use familiar tools and proactively return with work or information.

Early internal users ranged from enthusiastic AI users to colleagues who had used it much less. Ugarte says people can start with a simple task, then configure the bot and gradually give it broader responsibilities as trust develops.

He describes a marketing bot with access to advertising accounts and a budget, working with a design bot to test creative assets. A support bot can reproduce issues and help process incoming tickets.

Tan uses a bot as an outer loop around engineering. Instead of collecting context from Slack and copying it into a coding tool, she can bring an agent into the conversation where the bug report or feature request already lives.

Users can organize bots around functions, individual customers or a mix of both. Tan prefers a smaller collection with some specialists; Ugarte likes assigning each bot a distinct problem and having it proactively report what it finds.

Ugarte compares the role of a bot owner to a domain expert managing an apprentice. He says this can make it easier for businesses to apply agents to a particular outcome rather than rely on a single general assistant.

Team bots can be shared across a company. A colleague who likes building automations can put a few hours into a workflow, then let peers use and improve the same bot rather than maintaining separate copies.

Tan shows a sales example: shared specialists research potential leads and handle operational steps. Engineering bots similarly incorporate skills and practices that the whole team can use.

Shared work introduces ambiguity. Ugarte says a bot in a group thread may not know which person has the relevant expertise or decision authority; the product needs better ways to represent those relationships.

The group discusses bot ownership, managers and collaborators as possible sources of authority. The broader question is how an agent should interpret instructions when several humans or bots participate in the same workflow.

Tan describes making bot-to-bot work visible in Slack. Her engineering bot can ask a data bot whether a user issue is widespread, and she can observe the exchange rather than reconstruct it afterward.

Ugarte recommends building trust in stages. A data bot can first have read-only database access and answer questions; after people see it perform reliably, they can consider allowing actions or assigning broader outcomes.

Asked about her development loop, Tan describes collaborating with a colleague and her bot in a Slack thread. She shared a video and asked what it would take to build a similar feature.

The bot launched a Cursor cloud agent with a virtual machine that could run the app, prototype the change and return screenshots and video. Other colleagues could join the thread and give feedback while the work was underway.

Tan says one feature was developed through roughly 200 messages in the shared thread, without her opening Cursor for that project. The team judged the resulting artifacts and iterated together before shipping.

That level of autonomy took time to establish. Tan says the team invested in skills, codebase constraints, static analysis and tooling so that recurring review requirements were encoded in the system rather than left to a person each time.

In this setup, her agents can merge their own pull requests. She says that, for the example shown, she reviewed the output artifacts rather than reading the pull request itself.

Tan explains pstack, short for potato stack: her collection of engineering skills, inspired by GStack and published through the Cursor plugins repository. She compares a personal set of agent tools to a chef bringing familiar knives to a new kitchen.

One host describes a personal software factory with multiple threads and a coordinator that learns preferences from prior interactions. He uses it to look for useful techniques in other toolkits and adapt them to his workflow.

Ugarte says work happening in public Slack threads helps knowledge spread. Colleagues can see a power user invoke an agent and later adopt the same technique, instead of leaving the workflow hidden in a private coding session.

Tan keeps some personal bots outside Slack, while engineering bots join shared threads. Ugarte says the aim is to let bots work inside existing company tools, including documents and meetings, rather than rebuild every business application.

Looking ahead, Tan imagines bots with more of their own identities and tools. She is interested in interfaces that make communicating intent more fluid, though the examples she offers are possibilities rather than product commitments.

Ugarte says software has useful infrastructure that other knowledge work often lacks: code can be compiled and tested, and much of its context lives in a repository. Elsewhere, important context may sit in people’s heads or scattered documents.

The hosts discuss how a company organized around AI might assign ownership of outcomes and teach employees to use agents. Ugarte expects defining objectives and deciding how to measure them to become more important as execution becomes cheaper.

Tan says the smallest useful engineering loop gives an agent a way to run its code like a user and inspect the result. The agent can find a problem, change the code and repeat until it meets a defined goal.

She distinguishes functional correctness from overall quality: a loop may make a feature do the requested thing while leaving performance or resource use poor. Engineers still need to design the environment and constraints that guide good work.

Once the basic loop is reliable, an alert can trigger an agent to reproduce an issue, inspect the application and propose a fix. Tan says she also uses a coordinator to manage subagents rather than personally supervising every step.

A host asks how much automated code review is enough when a thorough review consumes tens of millions of tokens. Tan says review remains useful, but she has reduced some adversarial review because agents can overfit to feedback without understanding the product’s larger goals.

Her alternative is to put more knowledge into architecture, APIs, compilers and static checks. A rule encoded in the codebase can prevent a recurring mistake without repeatedly paying for an agent to rediscover it.

Tan illustrates the idea with the Electron desktop app: a dependency checker prevents imports between parts assigned to the main and renderer threads. It does not measure execution time; it enforces a boundary intended to keep heavy work off the renderer.

She says the rule has helped the app maintain consistent performance. Critical infrastructure and database changes may still deserve human involvement; the amount of review should depend on the work and its consequences.

Tan notes that she has access to substantial model capacity and treats her workflow as an experiment in what engineering may look like later. She believes well-designed codebase checks can make ordinary agent-assisted work more economical.

Ugarte says the team’s bottleneck is increasingly agreement on product direction rather than the time needed to write a feature. Many ideas already have pull requests, but merging all of them would create a fragmented product.

Tan’s feedback bot gathers customer reports and can reproduce and fix some small bugs. The team treats core interface changes differently: it uses them internally for longer and declines to ship changes that do not gain strong internal support.

Tan directs much of her factory toward maintenance, performance and user-reported issues rather than autonomous feature selection. That frees engineers to spend more attention on product experience and decisions about what to build.

Tan studied accounting and finance and discovered she enjoyed building spreadsheet models and macros. After an early startup and involvement in the Australian startup community, she found her first technical work.

She says sharing what she learned online led to an invitation to speak at an Ember conference, despite her fear of public speaking. Mentors and the ability to communicate ideas helped her continue growing as an engineer.