By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

The Rise Of AI Coworkers

Lauren Tan and Roman Ugarte join this episode of the Lightcone to go in deep on how they built and deployed Grok Bot.

Roman UgarteguestLauren TanguestGarry TanhostJared Friedmanhost

Nov 14, 20261h 0mWatch on YouTube

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

Great conversations run long. Their best ideas don't have to.

uListen is free on iPhone, iPad, Android, Chrome, and Claude.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

What Grok Bot is: AI teammates with tools, identity, and proactive loops
Roman explains Grok Bot as a product for creating “AI teammates,” not just chats. He describes the core principles: bots with names and identities, access to the same tools humans use, and an “always on” posture that can run long loops and proactively surface work.
- •Grok Bot is positioned as creating AI teammates with identities, functions, skills, and tools
- •The product started as a fast internal prototype built in about seven weeks
- •Motivation came from how long-running agents and tool access changed engineering workflows
- •Design choice: organize work around bots as the primary primitive (not files or chats)
- •A key goal is proactivity: bots run over time and bring ideas and insights unprompted
Giving bots real jobs: from small tasks to full company functions
Roman describes a pattern where people start with personal tasks, then gradually grant more tool access and responsibility. He shares examples of bots taking on marketing operations and support workflows end-to-end, moving toward bots acting like managed employees inside companies.
- •Common adoption pattern: basic task → more tools → outcome/objective → full job responsibility
- •Marketing example: a bot gets ad platform access, works with a design bot, and runs A/B testing
- •Support example: a bot can reproduce issues and help manage a constant stream of tickets
- •Bots are treated like employees with credentials and management by domain experts
- •Expectation that domain experts will build bots and share them across the company
Lauren’s “outer loop”: bringing agents into Slack and X where work happens
Lauren explains how Grok Bot changes her engineering workflow by moving context gathering into the same places she already works. Instead of manually summarizing Slack discussions into an agent, she brings bots directly into threads, making collaboration and last-mile execution more ergonomic.
- •Lauren uses Grok Bot heavily for engineering alongside tools like Cursor
- •Key benefit is reducing context-copying by integrating bots into Slack and other surfaces
- •She describes Grok Bot as her “outer loop” and “last mile” for getting context to agents
- •Bots can be interacted with like coworkers in Slack threads and on X by tagging
- •Ergonomics and connectors significantly increase her productivity
One bot vs a team of specialists: organizing bots to match how you think
The conversation shifts to how users structure bots: one generalist or many specialists. Lauren emphasizes that bot setup should reflect how you compartmentalize work, while Roman shares why he prefers bots that each obsess over a single problem and proactively report back.
- •Bot organization is flexible and should be set up to match the user’s brain
- •Two patterns: specialist bots by function vs bots organized by customer (horizontal vs vertical slices)
- •Lauren prefers fewer bots with a few specialists; others prefer many compartments
- •Roman prefers bots dedicated to one problem, similar to hiring focused employees
- •This “obsess over one problem” framing helps bots surface proactive insights
Sharing bots across the company: Team Bots and internal best practices at scale
Roman introduces Team Bots: bots that can be shared across an organization with an owner and collaborators. Lauren describes how teams (like sales) build shared specialist bots so everyone benefits from the same loops and best practices, rather than duplicating individual setups.
- •Team Bots allow sharing bots across a team/org with a clearer ownership model
- •A builder-type person in a department often creates scalable automations for peers
- •Sales example: bots help research leads, handle operational sales steps, and share expertise
- •Shared team bots consolidate best practices into a single “expert bot” everyone uses
- •Similar shared patterns apply to engineering bots and internal workflows
Multiplayer agents and the trust gap: who does a bot listen to in a group?
The group discusses the next phase after “single-player” prompting: agent collaboration. Roman highlights unresolved multiplayer problems, like bots lacking social context in group threads and not knowing which humans have decision authority, requiring product- and model-level solutions.
- •Agent collaboration is framed as the next step beyond individual prompting workflows
- •Bots inside Slack threads can struggle with social context and authority recognition
- •Roman describes bots as like new employees with no EQ or room awareness
- •The team expects advances at the product harness level and model level to address this
- •The next few years are described as an interesting period for solving these issues
Identity, permissions, and onboarding bots like humans (auth isn’t solved yet)
The discussion turns to authentication and authorization for AI coworkers. Lauren notes the need for bot identity, permissioning, and collaborator roles; Roman says there’s no industry-wide silver bullet and argues for borrowing familiar HR-like patterns of scoping access and expanding it with trust.
- •Bots have concepts like owner, manager, and collaborators
- •Key open problems: authentication, authorization, and permissioning for bots
- •Roman frames the approach as: treat bots like humans you hire and onboard
- •Access should be scoped by role and expanded over time as trust grows
- •A participant shares an approach where a bot inherits access from the user per Slack context
Bot-to-bot collaboration in practice: visible chats, Slack identities, and safety worries
Lauren explains that bots can talk to each other, with their collaboration visible inside the app and often happening explicitly in Slack via bot identities. The group discusses the eerie feeling of bots conversing autonomously and touches on safety concerns, while Roman emphasizes gradual trust-building starting with read-only bots.
- •Bots can collaborate directly; their conversations can be viewed in the Grok Bot app
- •Lauren describes a lead bot supervising other bots, including amusing “disciplinarian” behavior
- •A speaker describes an internal forum-like system where bots have long conversations without prompting
- •Lauren describes explicit Slack-based bot communication between a personal engineer bot and a data specialist bot
- •Trust-building starts with small, read-only bots; later steps include action-taking and job ownership
The workflow behind 4,000 PRs/month: building and shipping features inside one Slack thread
Lauren walks through how she turns Slack requests into shipped features using Grok Bot, often staying in Slack rather than switching into a separate coding environment. She describes a real example where a feature was developed end-to-end through a long Slack thread involving coworkers and her bot, producing artifacts like videos and screenshots for fast feedback.
- •Lauren says much of her engineering work now happens in Slack and on X
- •Example workflow: share a reference, ask what it takes to support it, and the bot spawns a cloud agent
- •Cloud agents can prototype and return videos/screenshots for immediate team feedback
- •A feature can be built end-to-end in a shared Slack thread with many messages
- •Lauren describes getting to a place where agents can merge their own pull requests in some cases
Teaching agents to write code you trust: PStack, skills, and “codebase as memory”
Lauren explains PStack (Potato Stack) as an open-sourced set of skills that teaches agents to do rigorous engineering work the way she would. The conversation expands into how personal software factories evolve via memory—capturing preferences and workflows through repeated interactions and shared skills.
- •PStack is described as a set of agent skills inspired by GSack and designed for Lauren’s engineering workflow
- •She frames these stacks like “chef knives” you bring to a new kitchen—opinionated, portable workflows
- •PStack aims to make agent-written code more rigorous and aligned with her standards
- •Garry describes a personal factory with a “captain” agent coordinating multiple ongoing threads
- •They discuss an emerging personal element where transcripts and memory teach agents when to intervene or proceed
Building a personal software factory: minimal loops and agents that check their own work
Lauren lays out what she considers the smallest useful agent loop: enabling the agent to run the code empirically and verify results so it can iterate without constant babysitting. She then extends the idea to an “outer loop,” where alerts can trigger automated reproduction and fixes, and describes delegation to coordinator agents managing sub-agents.
- •Minimal loop focus: teach the agent to run the code and check its own work empirically
- •Self-checking enables iterative improvement without a human executing every step
- •Correctness can improve before “goodness”; engineers then work on making good code the default
- •Outer-loop idea: alerts trigger agents to reproduce issues and apply the same loop automatically
- •Lauren describes using a coordinator agent feature that manages sub-agents so she doesn’t manage projects directly
How much code review is enough: avoiding overfitting, saving tokens, and shifting left
Garry raises the problem of extremely expensive review passes, and Lauren explains she has deemphasized some heavy review strategies over time. She argues that excessive adversarial review can overfit and miss broader intent, and proposes pushing quality into the codebase through architecture, static analysis, and rules to reduce token-heavy review.
- •Garry describes review steps that find bugs but consume tens of millions of tokens
- •Lauren says she no longer uses plan mode and has reduced emphasis on heavy review skills
- •She describes spawning reviewers across different model families, but warns about overfitting and misaligned feedback
- •She presents an “inverted pyramid” where investment should go into codebase and static analysis first
- •Guardrails encoded in the repo reduce both human review effort and token spend
Codebase guardrails that save tokens: CI-enforced constraints and performance protection
Lauren gives a concrete example of turning performance and architecture constraints into enforceable rules rather than relying on code review. By building linting and dependency graph checks that prevent problematic imports, the team avoids recurring review burdens and keeps app performance consistent over time.
- •Lauren frames the codebase as a form of memory that can encode decisions and constraints
- •Example: Electron performance sensitivity motivates strict separation of main vs renderer code
- •They enforce import boundaries to prevent heavy work from creeping into the renderer path
- •CI enforcement means issues can’t be checked in, reducing review overhead
- •They describe this as a way to keep quality even as AI-written code accumulates over time
When product judgment becomes the bottleneck: taste, dogfooding, and what not to automate
Roman explains that as execution accelerates, the limiting factor becomes alignment on vision and roadmap rather than implementation capacity. They describe selectively automating maintenance (like bug fixes) while keeping a high bar for changes that affect core user experience, relying on internal dogfooding and “internal product market fit.”
- •Roman says the bottleneck is shifting from building features to agreeing on product vision and “what great looks like”
- •He describes frequent situations where features already exist as PRs but shouldn’t all be merged
- •Lauren describes “Sandy,” a factory that processes large volumes of feedback and auto-fixes small bugs
- •They avoid automating big UX changes that could lead to confusing day-to-day UI shifts
- •They keep a high bar: if changes don’t achieve strong internal buy-in, they don’t ship
The future of AI coworkers and the AI-native company: execution abundance and new org shapes
Lauren shares a 2027-oriented hope that bots become true coworkers with identity and capabilities, and wonders what the final agent UI will be beyond chat. Roman contrasts software factories with broader business “factories,” predicting that execution becomes abundant and companies will need better problem definition, KPIs, and intent specification.
- •Lauren imagines bots with their own identity and capabilities comparable to what humans can do
- •She asks what the final agent UI is: chat or something else, and references a more “fluid” intent interface concept she saw discussed
- •Roman highlights differences between code (with CI and clear correctness checks) and other knowledge work that lacks equivalents
- •He notes non-code context is often trapped in people’s heads or inaccessible places, limiting agents
- •The group discusses AI-native organizations shifting scarcity from execution to higher-level goal/intent specification
From finance to AI engineering: Lauren’s path, communication, and closing thoughts
Lauren recounts her non-technical academic background and how she discovered enjoyment in building through spreadsheet macros, then learned by building and sharing publicly. She credits writing and posting about what she learned, which led to speaking opportunities and career momentum, and the episode wraps with thanks and an outro.
- •Lauren studied accounting and finance and enjoyed building spreadsheets and macros as an entry into logical/technical work
- •She started a startup, joined the startup community, and got her first job through that path
- •She describes writing a blog and sharing what she learned publicly as a key accelerant
- •She recounts being invited to speak at a conference, building storytelling and communication skills
- •She closes with a loop: do cool work, talk about it, and opportunities can follow

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.