So, it looks like the Cursor team

accidentally leaked parts of the Grokbot

build by mistake. And this fellow right

here was able to reconstruct the

majority of it and made it public. This

is over a million impressions, so

naturally I had to take a look as well

to understand how every part of Grokbot

ticks. And after looking under the hood,

I now understand how the agents

communicate, how they assign roles, how

they decide which agent gets to work

first, and lastly, how they even run a

meeting together. And after

understanding all these techniques, I

was able to rebuild my own version of

Grokbot that works with my [music] Codex

subscription, open router, and even

local models. So, whether you're a

Grokbot user and you just want to

understand how it works, or if you want

to build your own version, then this

video is going to break down all the

important parts that matter. Let's get

into it. Now, given that the majority of

people who love Grokbot love all the

interactions between the agents, how

they work, and how everything seems to

be so turn-key, I'm going to focus on

those aspects. And before we even get

started, it's important to know that

repo that I showed you wasn't fully

comprehensive. It wasn't the entire

build. It was just a reconstructed

version of a lot of the parts that were

exposed. But by looking at those parts,

we can really understand how they all

work together. So, I'm going to walk

through each part step-by-step and give

you an example just to solidify the

concept. You might think that all of

these agents share one big brain and one

memory base. But behind the scenes,

that's not actually how it works. Each

agent has its own name, job, chat

history, and even private notes. So, in

this case, a researcher agent can go and

grab a series of information and only

that single agent would be aware of it.

Then how can they share what they know?

Well, they send messages and DMs to each

other. And this is not a brand new

concept. If you remember, way back in

February, Claude Code released agent

teams. And the entire concept was all of

the agents would have their own mailbox,

and they would email each other the

status of who's working on what, who's

blocking what, and which one should take

precedence. And we've also had agent

mail, which is an entire framework that

can be used by any language model and

any agent team or swarms to do the exact

same thing. So, if you task your Grok

bot to go research, build, and QA some

application, it's going to spawn the

researcher to go and pull that

information, then it would communicate

what is the most salient important

points to the builder. Then once the

builder was ready, it would then poke

and ping the reviewer to go and take a

look at what it put together. So, each

one of them does a different job and

starts with different facts. So, behind

the scenes, you have a tool that's

called send to agent, and this is the

very tool that allows each one of them

to DM each other. And the way it works

is, agent A might decide it now needs to

pass on a note to agent B to wake it up.

And if agent B keeps working on

something actively, it won't look at

another note unless it's urgent. If

you're midway through a build and the

researcher decided that it found three

very useful tasks for the builder that

was already in progress, it might

preemptively pass off a note to that

builder to let it know to incorporate

that into its next steps, and it can

keep working at the same time. So, one

doesn't have to stop in order for the

other one to work. They can both work in

parallel, so it will pass off this DM,

the builder will take it into account

for the subsequent phases while the

researcher keeps going. So, you don't

need your different agents to shut down

just to communicate. They can

communicate while they're in progress,

and they can decide that their progress

is not done based on the overall goal

that you've set the entire team. Now,

what if one of your agents is busy and a

brand new message comes in? Now, if it's

a normal message, then the agent will be

able to ignore it until it's completed

its current task. But if it's a priority

or extremely urgent, then it will scan

it and actually cancel the background

job and change directions. The one core

thing it won't interrupt is your

conversation back and forth. So, you as

the user take precedence, but everything

else that happens can be interrupted

depending on the level of urgency. So,

let's say that app you're working on is

already in production, and you find some

animation issue on the pricing page that

you want to tweak. But through doing so,

it finds out that the checkout is

broken. What will happen is, it will

intervene, interrupt the process, and

make the checkout fix number one, so

long as your back and forth chat with

the bot is completed. Now, DMs are solid

for passing work or work that's really

been fleshed out where there's no

judgment calls at play. But, if a call

needs to be made and a discussion needs

to be had, then your agents can have a

ground table, like you would in real

life. Then, to make sure that this group

chat doesn't end up in chaos, you

typically have a manager assigned, and

they go around the table to ask, "Do you

have something to contribute to the

conversation?" So, each one will chime

in, and if that particular agent has

nothing to contribute, they're allowed

to pass. So, you could have a series of

rounds where only one or two agents

chime in at a given time. So, if you

were pushing something to production and

you wanted to ask, "Are we ready to

launch?" then you'd be able to spawn

this conversation where the researcher

would say, "Yes." The builder might say,

"Everything passed." But, then the QA

says, "Something's broken." And then,

looking at the entire situation, the

operator decides that it passes because

has nothing good to offer this specific

conversation. So, then the conclusion of

the meeting, the next steps, if you

will, will be to go and fix this very

thing that was identified, and this

basically makes a conversation a lot

more efficient and reduces the

likelihood that you have endless

conversations about nothing that keep

hallucinating. Another feature that

people love about their Grok bots is the

feeling that they're so independent and

they feel like they have their own lives

and personalities. That's because, like

we said before, they have their own

name, their assigned job, you now know

they have their own inbox and way of

communicating, and they also have their

own computer with their own screen. So,

the AI model is the worker and the

computer is its desk. So, if you were to

say something like go and build this

application, test it, and review it, all

of these different agents would spawn

their own screens, and on those screens

would be different activities. For the

researcher, you'd have a series of tabs

that it's fetching for research. The

builder might use a screen just to open

up a terminal and make some changes in

the application. And then, the QA would

go and render either the local server

spun up by that terminal or do its own

independent work. When it comes to

things like the tools, plugins, and

permissions, Grokbot seems to work very

similar to something like auto mode on

Cloud Code. Where depending on the task

and the severity of the task, it will

decide whether or not it needs your

permission. So, even though you can give

it a credit card to go buy things

autonomously on its own, the first few

times it will want to ask you if it's

okay. Once it understands that it is

okay, then it will add it to its list of

accepted permissions and be able to do

it autonomously moving forward. So, if

we extend our example from before and

now you are republishing your pricing

page after fixing the checkout problem,

when it comes to editing the files, it

will auto allow. When it comes to

testing them, it will auto allow. But,

maybe the second or third time that

you're looking to publish, it will

double and triple-check if it's okay.

Now, you can actually keep going down

the rabbit hole and finding more details

and fine print, but it seems like the

Grokbot interface, the secret sauce,

lies in six elements. The interface, the

orchestration layer where each agent

decides which one will go next in what

order, the messages in the mail room and

DM room, then you have your memory

layers, the fact that each agent can get

its own screen that's a part of a bigger

sandbox, and then the model that runs

all underneath it. Now, with this

understanding, you could literally feed

this transcript and build something like

I've built. Where if we pop into this

Grokky app and I spin up a couple agents

and I click on my explorer agent and my

worker agent, and I ask something like,

"Can you go and do some deep research

telling me what are the latest features

with Grokbot?"

And I send these over. You can replicate

the exact same environment where you

have your own mail room where each one

of these agents are queued until the

task is understood, they have a small

meeting, then they pass off the task one

to task two, and you finally have the

lead that takes a look at every single

thing that's happening underneath the

hood. And once they're done running, you

get the exact same experience where you

can have an answer that is fully

composed by different agents that work

by communicating with each other,

putting together different pieces of

context, and delivering one unified

answer with an incredible amount of

detail. And the best part of this is you

can build your own version that depends

on an existing subscription that you

don't have to pay additional usage for

and most importantly, you don't have to

wait for an external team to decide when

it's okay to extend usage, when it's

okay to add new features because that is

fully within your control. And one

expert tip is I used Codex to not only

build this app, but also use computer

use to take a look at the performance

and the behavior of the Rockbot app so

that you can actually look at it,

emulate it and replicate it. And if you

want to do something like importing your

skills from Codex or Cloud Code, which

you can also use the SDK for, you can

grab that, you can create and build an

entire team of agents and keep adding

onto them and replicating all the

multi-agent orchestration that you see

and love in something like Rockbot. So

hopefully this breaks down all the

mysteries that lie underneath the

Rockbot hood so you can better

understand how to use it better, how to

leverage it or like I showed you, how to

recreate it on your own terms, on your

own device. If you want a full guide

walking through every single feature

that I mentioned in a lot more detail

that you could theoretically feed to

your own language model of choice and

have it either add features to something

you already have like a Hermes agent or

similar or just better understand how

this stuff works, then check out the

second link down below and you can grab

that completely for free. And by the

way, if you always want access to every

single thing that I managed to reverse

engineer along with all the

understanding of how I did that, you're

always going to find a copy of these

exact applications and exclusive lessons

that you'll never see on YouTube in my

early AI adopters community. So if you

always want to be 10 steps ahead of the

game and save tons of money, then check

out the first thing down below. And for

the rest of you, if you found this

helpful, if you want me to make more

videos breaking down and reverse

engineering [music] concepts and builds

that already exist, let me know down

below and I'll see you in the next

video.