Grokbot for Engineers: Named AI Teammates and Cloud Agents

Product managers get pulled across projects, inboxes, and tools, then still have to ship. A chat box can answer a question. It does not sit in Slack, open Linear, write in Notion, or come back with a result you can merge.

Grokbot for product managers is how Kevin deParco and Roshan Sajnani of the SpaceX AI product team run that work: named AI teammates with their own computer, long-running memory, and permission to finish jobs. You message them the way you message colleagues. They come back with charts, specs, mocks, and pull requests — and they interrupt you only when they need approval.

This is the operating manual for that setup. You will define a small roster of role-based bots, connect the tools they actually work in, and run a data-to-spec-to-design-to-code loop. Start with one bot if you want; the method scales by adding named colleagues, not by stuffing more into a single thread.

Key takeaways

Treat Grokbot as AI teammates you give real work to, not as a chat box that returns text. The speakers’ bar is results, then a ping when approval is required.
Encode the best colleagues you have worked with: they tie multiple tools together, keep long-running context, work independently on their own computer, and message in a rapid, interruptible way.
Use named, role-scoped bots (chief of staff, data, PM, design, engineering manager, recruiter). Scoped memory learns better, and you always know who to ping.
Connect the systems the work already lives in — Notion, Slack, Figma, Gmail, a data warehouse, and similar — through the marketplace. Bots are much more effective with those tools attached.
Run product work as handoffs between bots, not as one mega-prompt. In the demo, data found a funnel leak, the PM bot wrote a PRD, design produced mocks, and engineering shipped prototypes via cloud agents.
Plan an onboarding phase. Named agents are not great on day zero; they pick up skills, context, and taste as you teach them and leave feedback.
Keep a human in the loop for product shape, and use the bots to catch your mistakes. In the demo, the data bot corrected a wrong read of the funnel before the spec was written.
Cut noise on purpose. Routines should stay quiet when there is nothing urgent; otherwise Grokbot becomes another inbox.

Who this is for / who should skip it

This is for product managers, founders, and product-org operators who already live in a stack like Slack, Notion, Figma, email/calendar, a ticketing system, and a warehouse (the speakers mention Databricks or Snowflake as examples). It assumes you can install Grokbot, connect those tools, and tolerate an onboarding period while bots learn your business. Comfort with leaving comments in docs, tagging bots in threads, and reviewing PRs or prototypes is enough; you do not need to be the person writing the SQL or the production code.

Skip it if you only want a single chat window for one-off answers, if you cannot give a bot its own computer and tool access, or if you need a fully autonomous system on day one. The speakers are explicit: these colleagues start weak and get better on the job.

What Grokbot is trying to be

The craft of building software is shifting. Coding and prototyping are more accessible, which puts more weight on the questions DHH (quoted in the session) treats as product management: what should it do, who is it for, how should it do it, how should it look, and what are the priorities. Every product builder — PM, engineer, designer, founder — now has to answer those while actually shipping.

Internally, the speakers watched people outgrow the chat box. Asking a model for text was no longer the job. They wanted agents to drive outcomes, the way coding agents already do, but for the rest of product work. The pattern that kept coming up: treat the agent like a colleague at the next desk — messageable in Slack, able to read tickets, able to write PRDs in Notion.

It’s an agent with a computer at the end of the day and it feels like texting a colleague.

That colleague brief produced four product requirements for Grokbot.

Four properties of a colleague-agent

They tie multiple tools together. Real work does not live in one system. Ticketing (Linear, Jira, or similar), CRM (Salesforce or similar), Notion, Figma, email, Slack — colleagues already stitch those together. The bot should too.
They keep long-running context. The best teammates learn on the job. They start with little company context, take feedback, and get better. The speakers want that loop for agents: memory, a sense of what matters, and the ability to incorporate notes.
They work independently, on their own computer. Colleagues complete tasks without waiting on you for every click. Grokbot has its own computer — a cloud virtual machine — where it creates output, uses credentials you give it, and can be unblocked when it gets stuck.
They message like Slack, not like a turn-taking chat box. The chat box still makes sense as a core premise. What felt constrained was waiting your turn. You should be able to rapid-fire messages, jump between threads, interrupt, and steer while work is in flight.

Two operating rules sit on top of that design:

Give Grokbots real work. They should come back with results, not a wall of text or a list of clarifying questions.
They should finish jobs, and return when they need approval.

We want these Grokbots to be AI teammates that you can give real work to and that come back with results.

Why several named bots beat one mega-agent

You can put product, design, and engineering into a single builder bot. The speakers say that can work. For more complex use cases, they prefer a roster of named roles, for three reasons that are about you as much as about the model.

First, even if a model can hold a novel in context, you cannot. You want to know who to ping. Assigning roles that match how you already talk to colleagues — data, PM, design, engineering manager — is the natural interface.

Second, scoped memory learns better. Continuous learning and the feedback loop work more cleanly when a bot is cast into a type. A data bot that only does data builds stronger instincts than a generalist that also writes specs and reviews PRs.

Third, named bots are easier to parallelize. A common internal pattern: fire messages to several bots, let them all spin, then synthesize. That mirrors a meeting where you assign action items, people go do the work, and you reconvene. Bots can also message each other in channels and group chats, so roles can merge when the work requires it.

Each bot has its own memory. There is also a shared memory pool bots can write to when they (and you) decide the team should remember something. Under the hood, prompting tunes which pool they use. Group chats are how you bring separate memories into one room without collapsing everyone into a single agent.

The Grokbot roster you can copy

The demo team is inspiration, not a required org chart. Construct the roles that accelerate your product team. This is the set they ran.

Use case	Bot / tool	Input needed	Output	Owner
Attention and focus	Cora (chief of staff), email, calendar, Slack	How you actually spend time; priorities	A working model of your attention vs. what needs to get done	PM
Data and customer context	Ashley (data science), warehouse (e.g. Databricks, Snowflake)	A business question; trusted data sources	Queries, charts, funnel reads, corrections when you misread the data	PM
Product specs	PM Pete, Notion (and product context)	Insights, prior decisions, a crisp ask	PRD with P0 / P1 / P2 aimed at getting to code fast	PM
Design	Pixel, Figma, design-system and reference files	P0s from the spec; brand and UI no-nos	Mocks and options that already respect the system	PM / design
Shipping	Emily (EM) plus IC bots; cloud agents on the repo	PRD, mocks, a definition of done	Deconstructed work, prototypes, PRs, verification loops	EM / engineering
Hiring	Ray (recruiter)	Roles you are building out	Sourcing help and pipeline management	Product leadership

Cora is the person you turn to for email, calendar, and Slack — a model of how you as a PM actually work. Ashley is the go-to for data questions that used to mean writing SQL and hunting for trusted sources. PM Pete drafts PRDs, synthesizes customer insight, and runs lower-level product work. Pixel is a designer loaded with context on how to be a strong AI designer, plus your design system. Emily is coached not to write the code herself; she manages a team of engineering colleagues (in the demo: Einstein, Egor, Nova, Larry, and Eileen), deconstructs larger chunks of work, delegates, and runs verification. Ray covers sourcing and the hiring pipeline if you are building out the function.

Group those bots the way you group people. The speakers pin some at the top, hide or unassign others, and keep sections such as leadership and an engineering team. They also put bots in rooms: an eng pod for standup, an EPD (engineering, product, design) group, a war room for triage. The point is not the labels. It is that bots work as a team, in channels, not only in 1:1 chats.

How to set up Grokbot for a product org

What you are trying to accomplish: a left-hand roster of named bots, tools attached, and enough structure that you can hand off work without re-explaining the company every time.

What to prepare

The roles you will actually ping in a normal week (start smaller than the full demo roster).
The systems those roles need: Notion, Slack, Figma, Gmail, and whatever else is in the marketplace. Ticketing and CRM come up as the kind of systems colleagues already cross.
A data warehouse connection if you want on-demand analytics.
Design-system files and any hard no-nos (the speakers’ example: never put X buttons in the left corner).
Repo access if you want cloud agents to open PRs.

Steps

Install Grokbot and scan the interface: bots on the left, pins at the top, sections for grouping, a marketplace for tools.
Create named bots that match jobs, not a single “assistant.” Give each a role you could introduce in Slack.
Connect tools in the marketplace so each bot has the surfaces it works on. The speakers had Notion, Slack, Figma, MCP, Gmail, and an S-tier design skill stored in setup.
Group bots into the rooms you already run: leadership, eng pod, EPD, incident war room.
Give Grokbot its computer. The VM is where agents navigate the web, use credentials, and produce artifacts. Top right: you can teach a task by recording a workflow on that machine so the agent can watch, replicate, and later refine the skill. The speakers call this out for bespoke systems — including complex Salesforce work on the go-to-market side.
Load skills and reference context. Pixel is not “a designer” in the abstract; it has design-system context in Figma plus reference files for the business. Pete has skills that push specs toward crisp P0/P1/P2 requirements rather than long-lived documents.

Good looks like this: you know which bot to message for a given task; that bot can reach the systems the task lives in; and you are not pasting the same company primer into every chat. Failure looks like a bot with no tools, no role, and no memory — a chat box with extra chrome.

Run the product loop: attention, research, then shipping

The speakers organize PM work into three jobs Grokbot can take: an attention list, research and customer context, and shipping. The Flylow Airlines demo strings the last two into one loop. You are a PM at a boutique airline. The same sequence applies to any funnel you already measure.

Attention list

PMs are pulled in many directions. Cora’s job is to learn how you work — what you paid attention to this morning, this week, this month — and diff that against the priority list. The speakers describe this as a colleague on your shoulder, not a dashboard you remember to open. Pair it with routines (below) so the pulse comes to you, and with noise rules so empty mornings stay empty.

Research and customer context

Product work still depends on what users need, where they get stuck, and how to serve them. Ashley is connected to the data layer. You ask in plain language, including with typos. The bot generates queries, runs them against the warehouse, and returns numbers and charts.

In the demo they asked how many people purchased tickets yesterday on mobile versus web. Ashley returned 1,400 tickets, about 58% web and 42% mobile, then charts on solo / couple / family / group mix (about 25% of flyers were family). They also pulled a mobile purchase funnel and found a large fall-off.

Two setup details matter more than the airline numbers. You can turn a useful query into a routine — for example, the same family-and-purchase pulse every morning at 6:00 a.m. — so it is the first thing you check in Grokbot instead of a stack of dashboard bookmarks. For major launches, they have asked for hourly reports live from the data store to see where people get stuck as the launch is happening.

Good: an answer plus a chart, on demand or on a schedule, from a bot that knows the trusted sources. Failure: you misread the chart and ship the wrong fix. In the demo, the humans said the leak was seat selection. Ashley corrected them: on mobile, the big leak was search to fare selection, not seats. That correction went into the handoff to the PM bot. Keep the data colleague in the thread when you interpret funnels.

Shipping: spec, design, engineering, cloud agents

You cannot, in the speakers’ framing, be a PM in 2026 if you are not focused on delivering software. Grokbot is meant to accelerate the PM and the rest of the team. Internally, they say Grokbot represents a double-digit percentage of merged PRs, and it lets product people ship PRs into production when the setup is right. Treat that as their internal claim, not a benchmark you should expect on day one.

The demo handoff, in order:

From the funnel thread, tag the PM bot and ask it to work with the data bot on a spec to optimize the mobile funnel. Bots message each other. Ashley sent Pete the corrected insight and the ask.
Pete produced a Notion PRD with P0s and P1s. Skills in Pete’s context bias toward crisp requirements that help you get to code and prototype quickly, not toward a document that lives forever. Ideas in the first pass included a mobile fare-results redesign, a faster compare section, and honest fare proof on the card.
Do not treat that as done. The speakers one-shot it for the demo and immediately said real work needs more iteration. Leave comments in Notion (Grokbots can read them). The same pattern works with Google Docs and other connectors: tag the bot, say which number is off, keep going.
Hand the PRD to Emily to prototype, and bring Pixel in for design on each P0. Pixel has the design system and airline reference files, so it is not inventing fonts, colors, and UI patterns from scratch. It returned two options; the room picked one; they handed that mock to Emily to update the prototype.
Emily deconstructed priorities into scoped work, messaged each IC engineer with extra context, and let the ICs kick off cloud agents. Those cloud agents run with a local copy of the repo, including setup needed to make the repo testable and runnable. When Nova asked about creating a PR, they said yes. Nova launched the cloud agent and kept monitoring. When it completes, another verification loop can run: the IC reviews the cloud agent’s work, or hands it to QA or the engineering manager to check against the original goal.

You choose how much human to bring in. Low-stakes work (docs site, a resize in the mobile app) can run further without you. A meaningful implementation of a Pixel mock is a reason to ask for a demo or prototype. Two verification habits the speakers treat as generally true: give agents an environment to verify their own output, and give them tools that help you verify it too.

Agents are really good at prompting, oftentimes better than we are at figuring out what context to give to an agent.

That is why they often give the Grokbot team the goal and let the bots ask each other for context, rather than trying to pack the perfect prompt yourself.

Adapt the loop to your org. If requirements have lots of knock-on effects, you might staff bots whose job is to keep a knowledge base current and feed it into product. If you have a convoluted codebase with repos that must stay in sync, build that workflow in. The Flylow path is one example of a flexible tool, not a mandated pipeline.

Prompts, bot instructions, and workflows

No full system prompts were read aloud. What follows is the language they actually typed or described, cleaned of filler, plus short reconstructions labeled as such.

Data question used in the demo:

How many people purchased tickets yesterday on mobile versus web?
Help us visualize these with charts.

Turn a useful answer into a morning pulse:

Send me this as an update every morning at 6:00 a.m.

Handoff from a funnel insight to a spec (they typed this, then the data bot corrected the leak location before Pete wrote):

Looks like a big fall off when people are choosing seats on mobile. Work with PM Pete to generate a product spec to optimize our mobile funnel.

Noise rule for routines (reconstructed from the speaker’s description):

Reconstructed from the speaker's description.
If this is essentially a no-operation — nothing important or urgent for me to see — do not update me. Take the work on yourself or stay quiet.

Role briefs (reconstructed from the speaker’s descriptions, not quoted system prompts):

Reconstructed from the speaker's description.
Cora — Chief of staff. You have access to email, calendar, and Slack. Build a model of how this PM works. Track what they are paying attention to this morning, this week, and this month, and diff that against the priority list.

Ashley — Data science. You are connected to the data warehouse. Answer product questions with queries and charts. Know the trusted sources. If we misread a funnel or a chart, correct us before work moves downstream.

PM Pete — Product sidekick. Draft PRDs and synthesize customer and user insights. When asked for a spec, write crisp P0, P1, and P2 requirements that help us get to code and prototype quickly, not a long-lived document.

Pixel — Designer. Use S-tier AI design practice, our Figma design system, and reference files for this business (fonts, colors, UI patterns, and no-nos we have taught you). Produce mocks that are mostly right on the first try.

Emily — Engineering manager. Do not write the code. Manage the engineering colleagues. Deconstruct larger work, delegate, include the context each IC needs, and run verification loops on their output. ICs may kick off cloud agents against a local copy of the repo.

Ray — Recruiter. Help with sourcing and managing the hiring pipeline for the product function.

Teaching a skill on the VM (reconstructed from the speaker’s description):

Reconstructed from the speaker's description.
On Grokbot's computer, record the workflow (for example a Salesforce process). The agent watches, learns to reproduce it, and refines the skill each time it runs the task.

Measurement and business impact

The speakers did not give time-saved figures, cost, lead volume, or support-load numbers. The checkpoints they actually used:

Internally, Grokbot is a double-digit percentage of merged PRs, and it lets people in the product org ship PRs to production when the system is set up. That is their claim about their environment.
Qualitative bar for a data bot: you get queries and charts on demand, including during a live launch on an hourly cadence, without opening a bookmark folder of dashboards.
Qualitative bar for the loop: an open business question becomes a corrected funnel read, a Notion PRD, design options, scoped engineering work, and a cloud agent opening a PR — with you steering asynchronously while bots run for minutes at a time.
Qualitative bar for attention: the chief-of-staff bot and inbox grooming surface only what is important, so you can keep focus.

If you need a practical checkpoint in your own org, use theirs: did the bot come back with a result (chart, spec, mock, PR), and did a human still review product shape before it shipped?

Pitfalls and guardrails

Day-zero weakness. Named agents with separate memory will not be great at the start. Budget an onboarding phase: skills, context, recorded tasks, and feedback. They take on more work as that accumulates.
One-shotting product shape. Equipping bots with context does not mean they know everything. Layer on your own insight. Iterate in Notion comments, Google Docs, and threads. The demo skipped that for speed; the speakers said not to.
Misreading your own data. Humans got the funnel leak wrong. The data bot caught it. Keep analytics in the handoff, and do not let a wrong interpretation become a P0.
Noise. PMs already drown in pings. When you set up a routine, tell the agent to stay quiet on no-ops. They use Grokbot to groom an inbox and escalate only the important mail.
Context anxiety. Early-agent habits (compaction, pollution, watching the context window) still live in people’s heads. The speakers’ direction of travel is to make that less of your job: role-scoped memory, a shared pool when needed, and group chats to combine specialists. You still steer; you should not have to manage the window by hand all day.
Human-in-the-loop is a dial, not a religion. Easy, low-stakes diffs can run. Meaningful product and design changes should get a demo, a prototype, or an EM/QA check. Give agents a way to verify themselves and a way to help you verify.
Independence still gets stuck. The own-computer model includes you helping when access or a workflow breaks. Recorded tasks help on bespoke systems; they do not remove unblockers.

7-day implementation plan

Derived from the order they taught: colleague brief, roster, tools and computer, one real loop, then noise and verification.

Day 1

Install Grokbot. List the three to six roles you would actually message this week. Create those named bots. Pin the ones you will use daily. Connect the marketplace tools they need (start with Slack, Notion, Gmail/calendar, and Figma if design is in scope). Do not build the full engineering org on day one.

Days 2–3

Onboard one specialist. For most PMs that is either Cora (attention, calendar, Slack, inbox rules) or Ashley (one warehouse, one funnel, one chart). Load context. Run a real question. If the answer is useful, turn it into a routine — including the no-op rule so empty updates never land. Teach at least one task on the VM if your work lives in a bespoke UI.

Days 4–5

Run a two-bot handoff. Take a real insight (a funnel leak, a support theme, a launch metric) and tag a PM bot to write a crisp P0/P1/P2 spec in Notion. Leave comments. If you have a design system, bring a Pixel-style bot in for one P0 only. Practice bots talking to each other in a thread rather than you copy-pasting between chats.

Days 6–7

If you ship software, add an engineering manager bot and one IC path to a cloud agent on a low-stakes change. Decide in writing where a human must review (anything that implements a mock or changes user-facing flow) versus where the agent can run. Add one group room you already run in real life (EPD or a standup). Cut any routine that created noise. Write down the first workflow you now trust enough to reuse Monday.

Start with one colleague, not a whole org chart

The point of Grokbot is not more chat. It is a small set of AI teammates that already live in your tools, keep context, and finish jobs — attention, research, specs, design, and shipping — while you stay on the hook for product judgment. Start with one named bot, one connected system, and one workflow you will actually run again tomorrow.

FAQ

Do I need Grokbot, or is a normal chat box enough?

Use a chat box if you want a response and some text. The speakers built Grokbot because outcome-based work — tying Notion, Slack, Figma, data, and code together, then finishing the job — felt cramped in a single turn-taking window. If your work is already “message a colleague and get a result,” the teammate model is the one they are arguing for.

Multiple role-based bots vs one builder bot?

A single bot that is product, design, and engineering in one can work. They prefer separate roles for complex work because you can remember who to ping, memory stays scoped so the learning loop is cleaner, and you can parallelize. Group chats and a shared memory pool are how those specialists still operate as a team.

How does memory work across bots?

Each bot has its own memory that it writes and refines over time. There is also a shared pool for things the team should remember, with prompting that tunes when a bot uses which. Role-based bots are how you get strong, job-specific memory (for example, how to be a good engineer) without dumping everything into one context.

What tools does a Grokbot team need?

Whatever your colleagues already use. The demo connected Notion, Slack, Figma, MCP, Gmail, a design skill, and a data warehouse such as Databricks or Snowflake. Ticketing (Linear, Jira) and CRM (Salesforce) are the other systems they keep naming. Bots get much more effective when those are attached in the marketplace.

Can the bots talk to each other, or only to me?

They can message each other. In the demo, Ashley messaged PM Pete with funnel insights and an ask for a spec; Pete later handed work to Emily and Pixel. You can also put bots in group chats for standup, EPD, or a war room. You still steer by tagging, commenting in Notion, and choosing which mock or PR to take.

Do I need to be an engineer to ship with this?

The speakers’ pitch is that product people can ship PRs when the engineering manager bot, IC bots, and cloud agents are set up on the repo. You still decide how much human review to require. You do not have to write the SQL or the production patch yourself, but you do have to specify the goal and check the output that matters.

Will this work on day one?

No. They say named agents are not great on day zero. There is an onboarding phase: skills, context, recorded workflows, and feedback. Over time they build intuition and can take more work. If you need a finished colleague this afternoon, you will be disappointed.

Where must a human stay in the loop?

On product shape, on interpreting data before it becomes a spec, and on any change you would not rubber-stamp from a new teammate. Leave comments, pick among design options, and add verification for meaningful implementation. Let low-stakes work run further. Give agents a place to check their own output, and keep the right to interrupt.