Hello everybody.

Welcome to Grobbot for product managers

or PMs. Uh very excited to see you all.

We got many on the live stream as well.

I'm Kevin Dearco from the SpaceX AI

product team joined by and I'm Roshan

Sani also on the SpaceX AI product team.

Really excited to be chatting with you

all today.

>> Cool. We are going to be going through

how we have been building with Rockbot.

Some of the tips, the tools, uh the bots

that we have found very useful uh across

our product org. And so uh I wanted to

start sort of with the backdrop which I

think everybody in this room on the

stream knows. If you have been building

software, if you're a PM, obviously the

craft is changing very rapidly. Uh it

becomes now very easy to code, to build

things, to prototype. uh way more

accessible than it ever has been before.

And I like this quote from DHH uh the

developers developer, one of the

creators of Ruby on Rails, uh who says,

"Software is product management. What

should it do? Who should it do it for?

How should it do it? Uh how should it

look? What are the priorities?" These

are questions that now every product

builder, whether you're formerly

engineer or designer or founder or

product manager, really has to grapple

with as you start to build software for

your customers, for your users. Yeah.

So, with that, we thought we'd spend

just a second talking about the

motivation behind Grockbot because in

some ways, Grockbot is it's a product

we've also made. And so there's a story

to it having been built just the same

way there's a story to every product

having been built. And um I think if you

think back to sort of what motivated

Grockbot in the early early days it was

realizing that you know at least

internally within SpaceX there are so

many folks who were starting to evolve

beyond a chat box. And I think there's

been a lot of discourse about this maybe

some of you all have felt this or read

about it as well. Um, but really it

started to feel increasingly that agents

weren't quite as home in a chat box as

you you might have wanted them to be. I

think a lot of this was just a natural

evolution of how we started interacting

with these large language models and

sort of, you know, going from asking for

a response and maybe waiting for some

text to asking agents to drive outcomes.

And so obviously we saw a lot of this

outcomebased agentic development happen

when it comes to things like coding

agents. But you know, as more and more

of us internally started thinking about

that beyond coding, it felt like the

chat box was a little bit limiting. And

so we started exploring, you know, all

kinds of ways that we might want to chat

and work with agents and have them

complete tasks and have access to

systems that really go beyond the chat

box. And, you know, the most common

thing that kept coming up in all of

these conversations was that we kept

sort of treating our agents as if they

were colleagues. We wanted to be able to

interact with them as if they were sort

of these smart colleagues that sat next

to us at our desks or were messagable in

Slack or had access to linear to look at

tickets or you know wrote PRDS with us

in notion or whatever it is. And so a

lot of the motivation behind how Rockbot

was evolved and kind of why it is the

way it is today uh is grounded in this

idea that you know we should really have

these agentic colleagues that we can

work with on all the right things we do

when we build products. And so that was

really the motivation. So really I think

there's four things that we kind of took

as the brief based on that colleague

definition. Uh the first one is that

colleagues when you work with them often

together often tie multiple tools

together. They don't live in one system.

Uh they work across many systems and

those systems do different things right.

So you might have a ticketing system

like I mentioned linear or jira or

something like it. You might be using a

you know CRM or a CRM plus you know

something like Salesforce or more. You

might be keeping documents in notion,

designs in Figma and all these tools are

really really great at what they do but

oftentimes your colleagues or you know

yourselves are tying things together

across them. Um the other things here

are that these colleagues often have

longunning context. They learn and they

don't just you know you know work on a

task, eject the task and then move on.

The best colleagues you work with, the

best teammates you work with, they learn

as they learn on the job, right? Maybe

they start out with very little company

context. You teach them some tasks or

teach them how to get some work done.

They kind of do some work. You give them

some feedback, right? That wasn't that

great. They hopefully take the feedback

and then get better at their jobs. We

think that model generalizes to agents

too where agents can really, you know,

the way that the models have evolved,

get good at learning, at sort of

building memory for themselves, at

realizing what's important and at taking

and incorporating that kind of feedback.

The third thing, and I think this is a

really big one, is independence. And I

think for a lot of wh we lost the

slides. Let's go fix that. There we go.

Um, for a lot of, you know, people we

work with, they go execute things

independently, right? Once in a while,

maybe you'll get asked for, hey, I need

some help on blocking a task or, you

know, maybe you someone gets stuck on,

you know, stuck with access to a system

or something like this. Um, but really

the the defining property of a colleague

that you work with, one of the defining

properties is that they can work on

their own. that they can complete tasks

on their own and they have their own

access. And so this is really what

motivated the need for Grockbot to have

its own computer. And so we decided

Grockbot, you know, should have its own

computer that I can do things in. And

this is true and this is how the product

works today. So if you, you know, go in

and use Grockbot, Grockbot has its own

computer. You can kind of help it when

it gets stuck on that computer, but it

has its own surface where it can create

the output that you need to to get

assisted in your work. And then the last

and final thing I'll call out here is

messaging. So earlier I mentioned that,

you know, it felt like we hadn't, you

know, we wanted to move beyond the the

chat box a little bit, but but I meant

that a little bit tongue-in-cheek. You

know, the the sort of chat box that

defines how you interact with a large

language of model. We think that that

core premise makes still a lot a lot of

sense. But where it started to feel a

little bit constrained is that usually

when you're chatting with a colleague,

you're like rapid fire messaging. If

you're like me in Slack or maybe like us

in Slack, you're constantly streaming

out messages, you're switching between

threads, you're multitasking. And we

found that it, you know, rather than

having to wait your turn for the next

response, that it's a lot more engaging

if you can just really jump in,

interrupt, drive, and interact with

agents in this way. And you'll see a

little bit of this in a minute, but

really, I think those are the four

things that we found as we kind of built

this product and played with it

internally that, you know, define how

colleagues work.

>> I love those four things. And it's not

just like any colleague. It's like

really trying to encode the best

colleagues that you have worked with.

Yeah.

>> Uh they have a ton of context about the

organization.

uh they understand and can learn on the

job. They can move independently, make

their own decisions. They're not

constantly waiting for you. Uh and so

yeah, I think this is like the high

level of of how we think about what

Grockbot is. It's an agent with a

computer at the end of the day and it

feels like texting a colleague.

Exactly. Yeah. Uh and I think there's

two things here that if you want to sort

of take away uh with you as to what

Rockbot can do is it's it's these two

things on the slide here. is that we

want these Grock bots to be AI teammates

that you can give real work to and that

come back with results. They don't come

back with text or they don't come back

with sort of questions. They come back

with results. And then I think the last

thing here is that they really finish

jobs. We we think that really uh you

know being able to get the job done is a

much more productive way to interact

with agents uh and come back when they

need approval. So yeah, I'm curious how

do we use these with products?

>> Absolutely. So we are actually going to

see uh Grockbot in the wild a real demo

of uh some of the agents that we have

built the colleagues that we work with

in Grockbot. I think there are really

sort of three use cases that we're going

to see here. The first is what we call

the attention list. And so as PMs we are

constantly pulled in a bunch of

different directions. Maybe you're

working across a bunch of different

projects or there's a bunch of context

everywhere. And it is very helpful to

think about what are you currently

paying attention to? What have you been

paying attention to this morning, this

week, this month? And then really diff

that against your priority list and help

you understand how the ways in which

you're spending your time and where your

focus is relative to what needs to get

done across the team. And we're going to

talk about how Rockbot can help you do

that as this helpful assistant, this

colleague that's always on your

shoulder. uh being able to learn about

the ways in which you're working. The

next is uh research and building up

customer context. Obviously, this is

where a lot of product work goes into

doing the research, figuring out what

users and customers actually need and

want and love. Uh what the biggest

bottlenecks are, what issues are they

running into, how can you better serve

them? And so being able to gather up all

that context, learn from your users, be

able to synthesize data in new ways, uh,

Grockbot is actually really phenomenal

for, and we're going to talk about some

of the data science and analytics, uh,

and product use cases, uh, that we turn

to Grockbot for. And then, of course,

shipping. Uh, you cannot be a product

manager in 2026 if you are not focused

on delivering software products to your

customers. And so really thinking about

how Grockbot can not only accelerate you

as a PM but also the entire team.

>> Yeah, there's a stat on the slide here.

Rockbot represents for us internally a

double-digit percentage of merged PRs.

And I think that's a pretty wild stat.

It also within the product organization

empowers all of us as product people to

be able to ship PRs into production as

well. And so I think you just really get

a bunch of superpowers when you can set

up the this in the right way. So

>> very cool. So let us with that meet the

Grockbot team that we will be working

with today. Uh some familiar faces and

names uh that we can all all learn. So

first is Kora uh chief of staff. Uh you

can think of this as sort of the person

that you turn to have access to your

email, has access to your calendar, uh

maybe uh listens on Slack for some of

the messages that you're sending and

really builds up a a model of how you as

a PM actually work.

Next is Emily. Emily is an engineering

manager. uh you know Emily has been

coached not to actually do the coding

but just to manage a team of engineers

that we have given Emily and so Emily

has five different engineering

colleagues uh in Grockbot that she

manages uh it's very helpful to have

Emily as sort of this one uh contact

across the engineering team uh to be

able to uh give larger chunks of work

have Emily then deconstruct that and

delegate that work, actually run the

verification loops for the outputs of

some of the engineering agents. We'll

have Ashley, the go-to for data science,

for analytics, uh, for being able to ask

and answer data questions. I think as a

PM, oftentimes throughout the day, there

is like a random conversation that

sparks an idea that would have

previously required you to go write a

bunch of SQL and figure out where the

trusted data sources are. and very

helpful to have somebody that you can

just quickly message and get an answer,

a chart, a synthesis of uh the

underlying data set uh that will help

inform some of your decisions throughout

the day. We also have PMP Pete. PMP Pete

is a uh trusted sidekick for the product

team. uh being able to draft up some

product requirement docs, synthesize

some of the customer and user insights

and uh be able to run some of the lower

level product work day-to-day. You want

to talk about Pixel?

>> Yeah, Pixel is one of my favorites.

Pixel is a uh designer and so has been

trained on some of the best advice for

how to be a world-class AI designer. It

turns out that there are ways to make AI

design look really good if you instruct

your agents and bots in the right way.

And so Pixel's been loaded with a ton of

context on how to be an S tier designer

from some of the best and latest

thinking on the internet.

>> Amazing. And finally, we have uh Rey,

who is a recruiter. So anybody who's in

uh product leadership or building out

the product function or building out

your company uh be very helpful to have

a uh colleague that you can turn to on

the people and recruiting side of the

house uh to help with some of the

sourcing and uh managing some of the

hiring pipeline. And so these are some

of the very helpful uh Grockbot

colleagues that we have defined. But it

is totally up to you exactly what your

team is going to look like. And so

throughout the course of this demo, use

this as inspiration, use this uh for

ideas, but at the end of the day, you

can construct your team, figure out who

is most helpful, what are the sets of

roles that will be most accelerative for

you and your product team.

>> Yeah, definitely. And I think to that

point, you know, uh what we've seen a

lot of folks do is they create many

agents. And so wanted to spend a minute

just talking about why we think that's

effective. Um, one is that I think, you

know, while agents might have massive

context windows that can store entire

novels, our brains, or at least my brain

can't. And so oftentimes we just want to

know who to reference. And it feels like

a really natural pattern to assign roles

to these agents that correspond to how

you'd interact with colleagues, uh, as

we've talked about. So having a person

who's in charge of data, maybe they do

the job of five data people or assist

with five data types of tasks in your

organization um can be really helpful

for you invoking and working with those

agents to know their role. And so I find

this really helpful just to know you

know which bot I want to talk to for a

given task and then sometimes their

roles merge and that's okay. Um we'll

show you this but bots can also talk to

each other which is really cool and that

can kind of coordinate in channels and

stuff. So we'll show that as an example

too. Um but the other reasons for having

more than just one agent is that um the

bots do perform better because when they

can scope their memory down a little bit

more. Just going back to that idea of

continuous learning and evolution kind

of that learning loop we found functions

a lot better when a bot is sort of typed

or passed into a specific role. And then

the final thing is I think it's a little

more fun and a little easier to

parallelize your work when you can kind

of hand stuff off to a bunch of bots.

And so one pattern that we see a ton

internally is folks who will like fire

off messages to six different bots.

You'll see them all spinning and working

and they kind of all go and do some work

for you and you kind of come back and

synthesize some results. So again, sort

of mirroring how you might work, you

know, with colleagues. Let's say we're

in a meeting together. We assign a bunch

of action items. We go all go off and do

that work and then come back together

and synthesize say a plan. Um the bots

can really mimic that behavior. And I

think it's also easier for us as humans

to kind of know how we're steering them

when they do that.

>> All right. Should we hop into the demo?

>> Let's do it. Okay. Uh I quick show of

hands for those in the room. I know

those in the stream won't see this. How

many of you all have used or have

Crockpot installed?

Okay. 80% of the room. So for the 20%

who have who have not seen it, I'm going

to do like a very very very quick tour

showing you what we just walked through.

Um so this is Grockbot. This is the

interface. It's a bunch of bots on the

left. And you can see we can pin some

bots up top bots up at the top. We can

group our bots into sections. And so we

have a section here for leadership. We

have a couple of pin bots and then we

have our engineering team that we just

talked about down here. Einstein, Eigor,

Nova, Larry, and Eileen. You can also

hide bots or unassign them if you'd

like. And then there's an entire

marketplace uh where you can connect the

tools that you use to these bots to give

them those superpowers that we talked

about earlier. So really the bots we

found are incredibly effective when they

have access to all the tools that

they're working on. So in this case,

we've set up a bunch of tools. We have

notion,ion, slack, um, you know, big my

MCP, Gmail, and a few other things that

are that are installed. And that S tier

design skill that I talked about earlier

is also stored here. So, we have that as

part of our setup, too. Um, these bots

all function and work as a team. And so

earlier I mentioned we had the ways to

group bots together. You can see some

examples of that here. We have our in

our pod here. So, like you could imagine

our engineering team doing a standup.

actually really fun if you get the bots

into a room and have them tell them to

do a standup on a project. We have our

EPD teams or engineering product and

design team for those of you who are in

product organizations. Obviously, this

is how a lot of them function is with

these three roles kind of acting as a as

a triumpvirate. And then, you know,

maybe we have a war room for example

with a bunch of bots to triage an issue

or handle an incident. And you really

the sky's is the limit here. These are

just some some representative examples.

Um so yeah, that's our overall setup.

And just to remind you, we have Cora,

who's our chief of staff up here, PM

Pete who's our product assistant, and

then Ashley who's our data science

assistant. You can see we have some

queries we were running the other day

kind of looking at some of the funnels

uh and you know uh data funnels for our

product and maybe a good chance to

explain what the product is. So

everything you're seeing here is tied to

a demo environment we have set up for a

business called Fly Low Airlines. It's

an airline just like you know any other

airline might be. And so yeah, we'll be

talking about the airline business

today.

>> Very good. So everybody in this room on

the live stream, you are all now PMs at

Fly Low, this amazing airline. And uh

why don't we jump into uh maybe a few

questions that we might have about the

business. Uh, and so we can turn to

Ashley who is our uh, data science

colleague here and we can ask uh, how

many people purchased

tickets yesterday

uh, on mobile verse web.

>> Oh, I like that. Yeah, I feel like

product funnels are such an important

part of development, right? Like where

are sales coming from? Yeah. And so

under the hood, Ashley is connected to

our uh data layer and data warehouse.

This could be data bricks, snowflake,

pick your favorite data warehouse. And

uh what Ashley is going to go off and do

is actually go generate these queries,

run these queries against that external

data store and come back to us with

looks like 1,400 tickets were purchased

yesterday. So it sounds like we are a

small boutique airline here. Uh which is

very good. And looks like uh about 58%

were on web and uh 42% on mobile. Uh and

we can see uh how many families were

flying.

Uh typos are okay. Uh help us visualize

these with charts. And while that's

running, I actually find this as a

product product person to be one of my

favorite uses of Grockbot every day is I

now get data queries and charts on

demand. Um we we didn't we haven't shown

this yet and we can but you can also set

up routines with bots. So if you haven't

uh seen that that's a really really

helpful thing. I wake up every morning

and you know for those of you who like

to monitor your favorite dashboards each

morning uh usually you know you're used

to opening up a web browser navigating

your dashboards maybe you have a bunch

of bookmarks you load um this can all be

pushed to you and so I have many many

daily queries perhaps you're in charge

of this pipeline at your business you

can get these insights pushed to you

every morning or on demand and so one

thing that we've done for really major

product launches is actually ask for

hourly reports on how things are going

live from our data store so you can

truly track the progress of a launch,

truly track where people are getting

stuck, and sort of build these really

great experiences out the gate. So, it

looks like we got some data back.

>> Cool. So, this Ashley has actually

generated the charts for us, helping us

understand uh the uh distribution of

who's going solo, who's a couple, who's

a family, who's flying in groups, and

then uh also helping us understand what

is this family share of ticket

purchases. Looks like 25% of flyers are

family. Uh and so yeah, as Roshan

mentioned, we can make this a routine.

Uh send me this as an update every

morning at 6 a.m. This can be the first

thing in uh Grockbot that I check and I

can get an updated pulse of uh these

purchase behavior and uh how many

families are flying, which is kind of

cool.

>> Yeah, I like that. Now I I wonder if

there's something we could do to make

that experience better. I don't know.

Are there any issues with the product we

could try to find or

>> Yeah,

>> you think we should look into the uh

>> Let's scroll up. Let's look at that

funnel.

>> Yeah, I did this I did this earlier

today kind of just exploring how ticket

purchases might be look look like and so

asked Ashley to pull for us kind of what

happens for folks who are buying tickets

on mobile. So this looks like a pretty

classic product conversion funnel I

think right?

>> Yeah, very good. And looks like there is

quite a bit of fall-off in this funnel.

Yes, but we interestingly it looks like

the fall-off is happening when people

pick their seats. Maybe they don't like

our seat selections. Uh but this might

be an opportunity for us to improve the

product. And so, you know, as you're

working on your own products, one thing

that often happens is you see an insight

in the data and then you say, well, wait

a minute, like what's actually happening

in the product here? What can we do to

fix that experience? And so, maybe we

should write a spec.

>> Let's do it. So, uh you can thread in

chats. Uh here we are going to reply to

this message that we got yesterday. Uh,

and we're going to say, "Looks like a

big fall off when people are choosing

seats on mobile.

Work with PMP to generate a product spec

to optimize our mobile funnel." And as

you notice, Kevin here is tagging PMP.

So, this is where the bots will be able

to chat with each other. Uh, and you'll

see Ashley should fire off a message to

Pete. Pete has a lot of product context

on our business, understands our

customers, understands the previous

product decisions that have been made,

and so might have some insight as to

kind of why this is a spot in the

funnel. And between the two of them,

just like any great product and data

science combo, it'll be a hopefully

they'll be able to come up with some

good ideas here. And it looks like yeah,

we can maybe should we click into that

message and see?

>> Yeah. Yeah. Before we go there, I do

love Ashley corrected us. Uh we were

actually wrong in our interpretation of

the data. Uh, and so it says on mobile

purchase funnel. The big leak is

actually search to fair selection, not

seat selection. So, uh, we had

misinterpreted the chart. Luckily,

Ashley caught our our mistake here. And,

uh, you can see Ashley is sending a

message off to PM Pete with some of the

insights that she has generated through

this investigation and then the specific

asks that they're going to start to

coordinate on.

>> Yeah. And I see Pete spinning over

there. So I think doing something

cool.

Okay, it looks like Pete has a notion

PRD

with some P zeros and P1s. Let's see

what came up with.

Okay,

>> very cool. And uh talk about the skill

that PMP is using to generate this PRD.

Yeah. So, PMP has learned that the best

PRDS, the best specs are really crisp in

their requirements and that increasingly

they focus less on longevity of the

document and more on what helps us get

to code and prototype really quickly.

Right? We all maybe we've we've heard a

lot about how code is getting cheaper

and cheaper each days each day. Uh, and

so Pete has a bunch of skills that are

trained into Pete's context that allow

him to uh, in this case really

understand the business and then when

we're asking Pete for a PRD, uh, specify

a really crisp set of P 0, P1, and P2

requirements. So it looks like we got a

list. What do we think?

>> Amazing. Looks like mobile fair results

needs a redesign here.

>> Faster compare section are some of the

ideas. Uh, honest fair proof on the

card. I think one of the important

takeaways here is that uh you know we

are equipping uh our colleagues with a

bunch of context but they may not know

everything and it is often very helpful

to do a level of human review layer on

your own ideas and insights and iterate

with Rockbot as it builds out product.

And so uh this is awesome. we're going

to oneshot this from here for demo

purposes, but there's often a lot of lot

more iteration that goes into working

with our agents, working with each other

uh to figure out what is the sort of

right product shape that we should ship.

>> And obviously there's a number of

different ways you can do that. So one

thing I like to do with notion is just

leave comments in notion and crocbots

can read notion comments and so it kind

of really does feel like you're

interacting with a colleague. You leave

some notes here. You say actually this

feels wrong. That number feels off like

tag in the person. Um I that works

really well with Google Docs and other

connectors too. And so um yeah, I think

the iteration process has also gotten a

lot more fun. But I guess next

conventionally we'd probably start

prototyping some of those ideas out,

right? So

>> yeah, how do you want to do it?

>> Well, maybe we ask Emily. So Emily is

our engineering manager and has contacts

on our entire engineering team. So maybe

one thing we could do is ask Pete to

hand the PRD to Emily and you know maybe

she can ask our engineering team to

prototype some of these ideas and see

how they do.

>> Cool. Should we also get Pixel in the

mix?

>> Oh yeah, great plan.

>> And do a little design?

>> That's a good idea. Yeah. Yeah. So we

should probably get some design for each

of our each of our P zeros.

>> Cool.

>> All right. So, let's send that off.

And while that cooks, we'll pull up uh

the virtual machine which all of our

which Grockbot has access to. And uh as

we talked about, these are colleagues

with a computer. And so it is very

helpful to uh give these agents, these

colleagues, give Grockbot its own

virtual machine, its own computer in the

cloud where it can actually do work. It

can navigate the web. uh you can log in

and it can use your credentials across

various services to actually get work

done.

And you can see up here top right uh you

can see teach it a task and so you can

actually record your workflows uh

directly on this machine and agent can

watch and learn and be able to replicate

and reproduce the work that you are

doing. And so, uh, we often hear our

sales team, our go-to market team have

these very complex Salesforce workflows,

uh, these complex processes that need to

be replicated again and again. And it's

very helpful to be able to teach an

agent with more than just words or more

than just spoken word to actually be

able to record the work that you are

doing.

>> Yeah. And these the agent actually every

so every time it uses one of those tasks

or or goes through one of those tasks

also has the ability to refine that

skill and again follow that feedback

mechanism that we talked about earlier.

So really if you're working in bespoke

systems or custom systems I think that's

really invaluable.

>> Okay. Very cool. So it looks like we

have uh two separate handoffs. one to uh

engineering manager Emily uh to actually

start going on some prototypes for this

spec and then the other is uh over to

Pixel to actually start working on some

designs and some mocks.

>> Yeah. And I think what's cool about the

design workflow here is Pixel I

mentioned earlier is trained on just how

to be a great AI designer but also it

has context on our business's design

system. And so in this case, we use

Figma. And so the design system lives in

Figma, but Pixels also sort of has

reference files in its context that sort

of teach it how to design for our

airline. And so what this does is it

makes it so that, you know, we're not

starting from scratch every time. The

agent has a ton of embedded context on,

you know, our preferred fonts and

colors, UI patterns. Uh, you know, some,

you know, nos we've taught it over time.

For example, like never make X buttons

on the left corner and things like this.

Uh, and that really kind of gives this

designer the ability to iterate really,

really quickly and then, you know, get

things mostly right on the first try

versus having to start from scratch

every time. And it looks like we got

some designs. What do we think?

Those are some expensive tickets.

[laughter]

It looks like we have two different

options. Option A and option B, which

Pixel has designed. What does the crowd

think? Option A, clap. [laughter]

Option B, clap.

Okay,

>> I'm team A.

>> Sounds like team A.

>> All right, so let's hand the first mock

over to Emily to update the prototype.

>> Cool. And what you're also noticing here

is that these bots can really act um you

know, sort of interchangeably, right?

Like earlier it looked like Pixel had

handed something to Emily and then we

made a decision and then we can say hey

like go and update Emily and you'll

notice that these these bots sort of

like interact more asynchronously or

more out of band than you might expect

if you're just used to working with a

you know more of a chat style interface.

Um and honestly I think these make them

a lot more fun to work with where

basically you can continue to steer and

drive what the agents are working on. uh

you know particularly in some cases

where they're working on something for a

few minutes at a time kind of getting

that input from you as you go uh you

know kind of helps you feel like you're

you're being a part of the process and

also verifying the output too. So

>> cool. So let's check in on the

engineering team. Uh you can see Emily

here as the engineering manager uh

deconstructed the uh different

priorities into uh scoped work for each

one of the uh engineers and actually

then went and had direct conversations

with each one explaining the work that

uh they were to do and uh also included

a bunch of additional context. Uh, one

of the things that I think we have all

learned the hard way is that agents are

really good at prompting uh, oftentimes

better than we are at figuring out what

context uh, to give to an agent. And so

uh, oftentimes just giving the uh,

giving your team in Grockbot the context

of what you are trying to achieve and

letting them work together and sus out

what context would be most helpful, how

to deconstruct work in different ways

uh, can be very accelerative.

One thing we um will hopefully see in

action a second here, uh these uh Grock

bots also have the ability, there we go,

to kick off cloud agents. And so when it

comes to the actual engineering work,

what each of these IC engineers are

doing is they're creating agents in the

cloud that sort of run with a local copy

of your code repository. So when it

comes time to make changes to a to the

codebase or maybe they they need to

install some, you know, setup scripts to

be able to ensure that the repo is

testable and runnable. Um, these agents

come with all of those batteries

included, too. So, in this case, it

looks like you just said yes when the uh

when Nova asked about creating a PR. Is

that right?

>> That's right. Yeah.

>> Yeah.

>> Uh, and so Nova has gone off launched

this cloud agent. We'll continue to

monitor its work. Uh, when that

completes, uh, you can also have an

additional verification loop. uh the

engineer can review the work of the

cloud agent can hand it back to either a

QA team or your engineering manager who

can actually uh run an additional layer

of checks and verification to ensure

that the outputs align with the intended

goals that you gave your your team to

start. Yeah, I think what this is what's

really cool about this too is you can

sort of choose how much human you want

to bring into the loop, right? So maybe

for some of these cases, if it's a

really easy change to say a

documentation website or maybe it's

resizing something uh in our mobile app,

it feels like a pretty low stakes change

and sometimes we can just let our agents

run with it. But perhaps there's a more

meaningful change like we want to make

sure that this design was implemented

the way that we spec it out or the way

that Pixel helped us spec it out. We

might want to jump in and ask for a demo

or prototype. So one thing we found

that's just generally true when working

with agents is that giving them an

environment to verify their own output

in makes a huge difference but also

giving them the tools to help you as the

human verify the output also makes a

huge difference in outcomes and you can

kind of work with those things together

and you know get get better results. So

>> amazing. So I think our engineering team

is going to cook on this in the

background. Uh and so what have we seen

so far? We started with this uh open

question about the business. Uh we

started talking to a data science uh

colleague Ashley uh to help us better

understand some of the funnel dynamics

where the biggest fall-off was. Uh

handed all of that context over to uh a

PMP agent uh who could actually help

write the product requirements doc. Uh

that was the first pass. We then handed

it off to our designer who created a

first version of the mocks to actually

go and implement and then Emily and our

engineering team are off now cooking it

with our cloud agents.

>> Um really cool system and again you can

really adapt this to whatever workflow

makes the most sense to your business.

And so we've seen a lot of folks who you

know want to go really deep on the

requirements phase and maybe work on

really complex systems where you know

there's lots of knock-on implications

for you know every small requirement.

You could imagine having a team of folks

whose job it is to make sure there's a

knowledge base that's kept up to date

and that those requirements are fed into

the product. Uh or maybe you have a

really convoluted codebase with a bunch

of different repos that need to stay in

sync. That's another workflow that you

could build in with Grockbot. And so my

point with that is just saying that, you

know, this is one example of how you

might set up your team. Um but really

the tool is meant to be flexible for you

to kind of adapt to whatever workflow

works for for your own organization.

Cool.

>> Okay. Now, a few of the uh hard learned

lessons working with Grockbot. A few

things to keep in mind as you start to

build out your own teams in Grockbot. Uh

first is this idea of named agents,

having separate memory, being able to

learn on the job, and uh really thinking

about these as colleagues. They're not

going to be great on day zero. there is

an onboarding phase where you can give

them skills, you can give them context,

you can teach them things. Uh and so

over time they actually build up that

context and intuition and can take on

more and more work which is cool to see.

Uh the other is uh really thinking about

sort of reducing noise in the system as

PMs like there is often a lot of pings,

a lot of emails, a lot of slacks. Uh,

one of the pro tips that we've learned

is, uh, when you set up a routine to ask

your agent, if this is essentially a no

operation, if there's nothing important

or urgent for me to see, uh, you can

actually just take the work on yourself

or you don't need to update me. Uh, and

so there is a bit of noise reduction in

the system. Uh, agents are and Grockbot

is currently uh, grooming my inbox and

will only tell me about the most

important emails there uh, and can

escalate things. But generally I'm

trying to reduce the uh noise in the

system so I can keep focused on what is

most important for the team. And then uh

agents all the way down this idea that

you know you can have managers of agents

uh agents are coordinating with cloud

agents uh and Grockbot is a very helpful

agent system for helping you take on

some of the most ambitious work and

accelerate your product teams.

>> Yeah.

>> Very cool. So that was a very fun demo.

Uh that was uh great uh being able to

actually make some impact at Fly Low

Airlines.